Krishna Kumar | 24 May 10:25
Picon

[v4 PATCH 0/1] netfilter: "fail-open" feature support for NFQUEUE

Many users of an IBM security product, which uses netfilter's NFQUEUE
target to process packets in userspace, face a problem of dropped
connections during heavy load. Incoming packets are queued and
processed by the security module, which does deep packet analysis to
decide whether to accept or reject them. However during heavy load,
the queue fills up and connections fail when large number of packets
get dropped.

This patch implements a "failopen" support for NFQUEUE to help keep
connections open during such failures. This is achieved by allowing
acceptance of packets temporarily when the queue is full, which
enables existing connections to be kept open.

Failopen is enabled/disabled using a new call - nfq_set_flags(qh,
mask, flags), which makes use of two new netlink attributes:
	NFQA_CFG_MASK -  Specifies which flags are being modified.
	NFQA_CFG_FLAGS - Set/reset the bits for each of those flags.

		Tests done:
		------------
- netperf TCP_STREAM
- 64 netperf stress testing to ensure there are no memory leaks
- icmp ping
- enabling/disabling failopen in the middle of existing connections
- checksum verification of transferred files using scp
- different flag/mask values to check that code handling NFQA_CFG_MASK
  works as expected

		Test results:
		-------------
(Continue reading)

JieYue Ma | 24 May 06:47
Picon

reason that iptables mac module only has mac-source option

hi guys,

I am working on the mac module, and I added some arp related options
in it. I noticed that this module originally has only --mac-source
options in it. At first I think maybe author didn't want touch any
output packet. But now I doubt that maybe iptables hook point doesn't
support to do so. That is why I came here asking you guys for help. I
think in iptables OUTPUT hook point, it has not yet generate any 2nd
level information in the skb buffer, hasn't it? That is why mac module
can only touch incoming packet because only the incoming packet takes
the mac information in iptables

anybody can answer me? thanks a lot

BRs
jerry ma
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pablo Neira Ayuso | 23 May 13:00
Favicon

[README] patches that did not reach net-next (upcoming 3.5)

Hi!

David has closed net-next merge window.

I know there are several patches still on the table, you can see the
list here:

http://patchwork.ozlabs.org/project/netfilter-devel/list/

Some of them are small enough that I did not feel like pushing hard
for them to David, like the one from Amerigo Wang, Alban Crequy and
Denys Fedoryshchenko. My plan is to include them once merge window
opens again.

Gao Feng's namespace ct timeout requires another spin.

For bugfixes, I'll start collecting them to pass them asap.

Thanks for your work!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Nicolas Maître | 22 May 22:51
Picon
Gravatar

Using RELATED for a level4 protocol (MPTCP)

Hi everyone,

I'm a complete newbie in netfilter hacking and I'm trying to implement
the support of MPTCP [0] (standing for MultiPath TCP) in netfilter in
the context of a master's thesis.

I'll just summarize some points of MPTCP here to get a chance to be
understood with my request.
MPTCP is an extension of TCP which enables it to use multiple paths as
part of a single "MPTCP connection", answering to a multihoming and
performance demand. It acts as a higher-level, using TCP connections
as subflows and it has been designed to be backward-compatible with
regular TCP.
It exposes a similar interface to TCP to the application layer. A
figure might help to get the whole thing:

       +-------------------------------+
       |           Application         |
       +-------------------------------+
       |             MPTCP             |
       + - - - - - - - + - - - - - - - +
       | Subflow (TCP) | Subflow (TCP) |
       +-------------------------------+
       |       IP      |      IP       |
       +-------------------------------+
(If you cannot read it properly, the 2 figures in this mail are taken
from [0] where they are displayed correctly with a monospace font).

It's currently being standardized by the IETF.
Furthermore, a Linux implementation is already available and working fine [1].
(Continue reading)

Krishna Kumar | 22 May 14:10
Picon

[v3 PATCH 0/1] netfilter: "fail-open" feature support for NFQUEUE

Many users of an IBM security product, which uses netfilter's NFQUEUE
target to process packets in userspace, face a problem of dropped
connections during heavy load. Incoming packets are queued and
processed by the security module, which does deep packet analysis to
decide whether to accept or reject them. However during heavy load,
NFQUEUE queue (default 1024 entries) fills up and connections fail
after large number of packets drop during enqueue.

This patch implements a "failopen" support for NFQUEUE to help keep
connections open during such failures. This is achieved by allowing
acceptance of packets temporarily when the queue is full, which enables
existing connections to be kept open.

Failopen is enabled/disabled using a new call - nfq_set_flags(qh, mask,
flags), which makes use of two new netlink attributes:
	1. NFQA_CFG_MASK:  Specifies which flags are being modified.
	2. NFQA_CFG_FLAGS: Set/reset the value for each of those flags.

		Tests done:
		------------
- netperf TCP_STREAM
- 64 netperf stress testing to ensure there are no memory leaks
- icmp (ping)
- enabling/disabling failopen in the middle of existing connections
- checksum verification of transferred files (scp)
- different flag/mask values to check that code handling NFQA_CFG_MASK
  works as expected

		Test results:
		-------------
(Continue reading)

Jagdish Motwani | 22 May 08:00
Favicon

[PATCH] netfilter conntrack helper: nf_ct_h323: fix bug in rtcp natting

The nat_rtp_rtcp hook takes two separate parameters port and rtp_port.

port is expected to be the real h245 address(found inside the packet).
rtp_port is the even number closest to port  (RTP ports are even and 
RTCP ports are odd)

However currently, both port and rtp_port are having same value(both are 
rounded to nearest even numbers).

This works well in case of openlogicalchannel with media (RTP/even) port.

But in case of openlogicalchannel for media control (RTCP/odd) port, 
h245 address in the packet is wrongly modified to have an even port.

I am attaching a pcap demonstrating the problem, for any further analysis.

This behavior was introduced around v2.6.19 while rewriting the helper.

Signed-off-by: Jagdish Motwani <jagdish.motwani <at> elitecore.com>
Signed-off-by: Sanket Shah <sanket.shah <at> elitecore.com>

--
diff --git a/net/netfilter/nf_conntrack_h323_main.c 
b/net/netfilter/nf_conntrack_h323_main.c
index 46d69d7..7f0de36 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -270,9 +270,8 @@ static int expect_rtp_rtcp(struct sk_buff *skb, 
struct nf_conn *ct,
                 return 0;
(Continue reading)

David Miller | 21 May 23:09
Favicon

[README] net-next has been merged


Linus has pulled in all of the net-next changes, and I have
subsequently fast-forwarded both 'net' and 'net-next' to
Linus's tree.

All work at this time should be bug fixes and should be arranged
against 'net'.  'net-next' will be frozen and untouched until
some time after the merge window closes, and no development should
occur against it.

I am rejecting all patches in patchwork which implement new features,
perform cleanups, or otherwise are inappropriate at this time.  You
must resubmit them when the net-next tree opens back up.

There is one exception waiting in the wings, there is one netfilter
pull remaining from Pedro for the merge window and I told him that
this is OK.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jan Engelhardt | 20 May 00:08
Picon

libnetfilter_conntrack updates


The following changes since commit 6fdd30fe6de1311022ae9e17304dd72f4958bbb8:

  build: bump version to 1.0.1 (2012-05-18 01:24:29 +0200)

are available in the git repository at:
  git://git.inai.de/libnetfilter_conntrack master

Jan Engelhardt (4):
      build: remove unused LDFLAGS
      qa: change an if to elseif
      build: remove unused -DLIBNETFILTER_CONNTRACK_DIR
      Update .gitignore

 configure.ac            |    5 -----
 qa/.gitignore           |    2 ++
 qa/Makefile.am          |    4 ----
 qa/ct_events_reliable.c |    2 +-
 utils/.gitignore        |    1 +
 utils/Makefile.am       |   20 --------------------
 6 files changed, 4 insertions(+), 30 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Cong Wang | 19 May 16:39
Picon
Favicon

[Resend PATCH 1/2] netfilter: remove include/linux/netfilter_ipv4/ipt_addrtype.h

From: Cong Wang <xiyou.wangcong <at> gmail.com>

It was scheduled to be removed.

Acked-by: Florian Westphal <fw <at> strlen.de>
Signed-off-by: Cong Wang <xiyou.wangcong <at> gmail.com>
---
 Documentation/feature-removal-schedule.txt  |    8 --------
 include/linux/netfilter_ipv4/Kbuild         |    1 -
 include/linux/netfilter_ipv4/ipt_addrtype.h |   27 ---------------------------
 3 files changed, 0 insertions(+), 36 deletions(-)
 delete mode 100644 include/linux/netfilter_ipv4/ipt_addrtype.h

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index e4b5775..366d158 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -414,14 +414,6 @@ Files:	net/netfilter/xt_connlimit.c

 ----------------------------

-What:	ipt_addrtype match include file
-When:	2012
-Why:	superseded by xt_addrtype
-Who:	Florian Westphal <fw <at> strlen.de>
-Files:	include/linux/netfilter_ipv4/ipt_addrtype.h
-
-----------------------------
-
 What:	i2c_driver.attach_adapter
(Continue reading)

Arif Hossain | 18 May 13:54
Picon

Sending packet bypassing iptables rules


Hi,

In my userspace app, i receive packets from NF_QUEUE. I manage a
userspace queue to do some processing over the packets. So i have to
set nfq_set_verdict(NF_DROP,.....). Now after the processing i need to
send the packets to the destinations. But this time i need to send
them such way so that they won't be caught in iptable rules.

What i have done for now is, i've set the dscp field of the IP packet
. And added a rule $iptables -t mangle -A PREROUTING -m dscp --dscp 10
-j ACCEPT before the rule which queues the packets. Then send the
packet over raw socket.

May be because of my intensive traffic (Traffic is real time media
data, so delays are fatal), the performance of my system is horrible.
So i'm thinking how i can achieve a more efficient processing. One
thing comes to my mind is the process i'm following for forwarding
packet is not very efficient. So i'm thinking about how can i improve
this.

Thanks in advance.

--
-aft

Florian Westphal | 18 May 13:36
Picon

[PATCH][conntrack-tools] conntrack: flush stdout for each expectation event, too

else, piping "conntrack -E expect" output will be buffered/delayed,
which is not what users expect. Normal conntrack events are already
flushed.

Signed-off-by: Florian Westphal <fw <at> strlen.de>
---
 src/conntrack.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/conntrack.c b/src/conntrack.c
index b065211..0920bc5 100644
--- a/src/conntrack.c
+++ b/src/conntrack.c
@@ -1380,6 +1380,7 @@ static int event_exp_cb(enum nf_conntrack_msg_type type,

 	nfexp_snprintf(buf,sizeof(buf), exp, type, op_type, op_flags);
 	printf("%s\n", buf);
+	fflush(stdout);
 	counter++;

 	return NFCT_CB_CONTINUE;
--

-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)


Gmane