From yasuyuki.kozakai at toshiba.co.jp Thu Jun 1 05:01:27 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Jun 1 05:24:28 2006 Subject: nf_conntrack_proto_sctp.c:(.text+0x2e660): undefined reference to `local_bh_disable' In-Reply-To: <200605311253.54503.toralf.foerster@gmx.de> References: <200605311253.54503.toralf.foerster@gmx.de> Message-ID: <200606010301.k5131Tk1012237@toshiba.co.jp> From: Toralf F?rster Date: Wed, 31 May 2006 12:53:51 +0200 > Compiling current kernel linux-2.6.17-rc5-git7 I got this error: > LD init/built-in.o > LD .tmp_vmlinux1 > net/built-in.o: In function `sctp_print_conntrack': > nf_conntrack_proto_sctp.c:(.text+0x2e660): undefined reference to `local_bh_disable' > net/built-in.o: In function `sctp_packet': > nf_conntrack_proto_sctp.c:(.text+0x2e8c1): undefined reference to `local_bh_disable' > net/built-in.o: In function `ctnetlink_dump_table': > nf_conntrack_netlink.c:(.text+0x2f710): undefined reference to `local_bh_disable' > net/built-in.o: In function `ctnetlink_dump_table_w': > nf_conntrack_netlink.c:(.text+0x2f840): undefined reference to `local_bh_disable' > net/built-in.o: In function `ctnetlink_new_conntrack': > nf_conntrack_netlink.c:(.text+0x307c9): undefined reference to `local_bh_disable' > net/built-in.o:nf_conntrack_netlink.c:(.text+0x311cc): more undefined references to `local_bh_disable' follow > make: *** [.tmp_vmlinux1] Error 1 > > .config is attached. Actually nf_conntrack_proto_sctp.c doesn't include spinlock.h. But to compile them, I also needed to add interrupt.h to them. I wonder why that is necessary. they don't call local_bh_{disable,enable} directly but call {read, write}_lock_bh(). Then I think that spinlock.h is enough and spinlock_api_up.h should include interrupt.h. Anyway, I attach a patch make them include spinlock.h and interrupt.h like ip_conntrack_netlink.c. -- Yasuyuki Kozakai From kaber at trash.net Thu Jun 1 05:25:41 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 05:48:34 2006 Subject: ipv4options still broken (posted prev w/ no reply)... In-Reply-To: <1149102130.6167.20.camel@mbox> References: <1149033568.27117@www.broadwayinternet.com> <447CD93F.9070103@trash.net> <20060531045445.GA8333@oknodo.bof.de> <447DA068.1090507@trash.net> <1149097509.6167.9.camel@mbox> <447DE2F3.8090104@trash.net> <1149102130.6167.20.camel@mbox> Message-ID: <447E5E35.1090304@trash.net> Cody Tubbs wrote: > Bottom line is, it would be nice to -j LOG these options passing through > or attempting to be passed through a bridged firewall. It details > malicious activity, thus deterring that fact into a presumption that "I > most likely have more serious problems" was blatantly absurd. As I already said, please just send me your patch to disable or even better fix this behaviour and I'm going to apply it. If you really want to do something useful, please just fix the ipv4options match to be acceptable for kernel inclusion. So far, it does stupid things like using seperate flags for option negation and it depends on IP option metadata provided by the IP layer, which doesn't work for bridging. The last point BTW really is a good example why random crap from POM shouldn't be trusted. From yasuyuki.kozakai at toshiba.co.jp Thu Jun 1 06:30:27 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Jun 1 06:53:25 2006 Subject: nf_conntrack_proto_sctp.c:(.text+0x2e660): undefined reference to `local_bh_disable' In-Reply-To: <200606010301.k5131Tk1012237@toshiba.co.jp> References: <200605311253.54503.toralf.foerster@gmx.de> <200606010301.k5131Tk1012237@toshiba.co.jp> Message-ID: <200606010430.k514US1b000030@toshiba.co.jp> From: Yasuyuki KOZAKAI Date: Thu, 01 Jun 2006 12:01:27 +0900 (JST) > Anyway, I attach a patch make them include spinlock.h and interrupt.h > like ip_conntrack_netlink.c. Sorry, I attach this time. -- Yasuyuki Kozakai -------------- next part -------------- [NETFILTER] nf_conntrack: Fix undefined references to local_bh_* CC net/netfilter/nf_conntrack_proto_sctp.o net/netfilter/nf_conntrack_proto_sctp.c: In function `sctp_print_conntrack': net/netfilter/nf_conntrack_proto_sctp.c:206: warning: implicit declaration of function `local_bh_disable' net/netfilter/nf_conntrack_proto_sctp.c:208: warning: implicit declaration of function `local_bh_enable' CC net/netfilter/nf_conntrack_netlink.o net/netfilter/nf_conntrack_netlink.c: In function `ctnetlink_dump_table': net/netfilter/nf_conntrack_netlink.c:429: warning: implicit declaration of function `local_bh_disable' net/netfilter/nf_conntrack_netlink.c:452: warning: implicit declaration of function `local_bh_enable' Spotted by Toralf F?rster Signed-off-by: Yasuyuki Kozakai --- commit 867779436005b3b16466146ddd226e2faabee488 tree 6e2d3efc5bab4b2eddf5144d4973de8413c2ad23 parent ba8f5baba79da8eb502f8534c3a8ecb64aceb790 author Yasuyuki Kozakai Thu, 01 Jun 2006 11:21:52 +0900 committer Yasuyuki Kozakai Thu, 01 Jun 2006 11:21:52 +0900 net/netfilter/nf_conntrack_netlink.c | 1 + net/netfilter/nf_conntrack_proto_sctp.c | 2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index bd10eb9..bb9f781 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c index 0c6da49..0839b70 100644 --- a/net/netfilter/nf_conntrack_proto_sctp.c +++ b/net/netfilter/nf_conntrack_proto_sctp.c @@ -28,6 +28,8 @@ #include #include #include +#include +#include #include #include From varun at rocsys.com Thu Jun 1 08:02:54 2006 From: varun at rocsys.com (varun) Date: Thu Jun 1 08:17:03 2006 Subject: Prob with hook reg in iptables Message-ID: <447E830E.8000606@rocsys.com> Hi all, I have a setup where iam using iptables. I have squid running on my statem. Now the scenario is that this sytem is my router. I have eth0 connected to LAN, eth1 to Wan 1 and eth2 to Wan2. In the same box i also have a propratery FW which has Load Balancing feature. Now my intention is i start iptables first so that it registers with netfilter hook first. So policy is like this iptables -t nat -D PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 8080 In the port 8080 i have squid running. As far as filtering of iptables is concerned it is allow all. So my basic FW functionality is concerned it is taken care by My Propratery FW. It will do the natting for both wan interfaces in Load balance. Now what i expect is that iptables will get all the packets first and then packet will go to my firewall and might get dropped if ACL matches else it is success. Once success i expect the packet to be redirected to port 8080 where squid can take control. Now my problem is that even though iptables is registered first when i log the packets using iptables for the above rule i find that no packets are comming to iptables there by no packets are going to proxy. I get only some multicast packets. From lan iam able to browse well and all my traffic is going tru my FW rather that first through iptables. Why? As far as my knowledge first registered module get the packet first and if the action is NF_ACCEPT the the next registered module to the hook gets it right? If yes why is it not happening? Another thing is what exactly does redirect do does it mangel the packet? Please help me in this? Varun From jdb at comx.dk Thu Jun 1 11:15:49 2006 From: jdb at comx.dk (Jesper Dangaard Brouer) Date: Thu Jun 1 13:12:38 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes Message-ID: <1149153349.28481.15.camel@localhost.localdomain> Hi I have experienced some concurrency issues with the iptables userspace program. Executing an iptables (write) command while another (write command) is running causes a failure of the command. Well, this is the expected semantics of a non-blocking call, but the issue is how the error situation is reported back. The iptables command detects the situation and reports: "iptables: Resource temporarily unavailable" With shell exitcode "1". What annoys me is that the shell exitcode is "1", which is also used for "normal" errors. This means that my code/scripts needs to parse output from stderr to distinguish it from normal/expected errors. I propose that the exitcode of "Resource temporarily unavailable" error is changed to something unique for this situation. Comments? -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060601/a5416b1e/attachment.pgp From kaber at trash.net Thu Jun 1 16:53:38 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 17:16:47 2006 Subject: [PATCH] fix mem-leak in netfilter In-Reply-To: <200606010943.31554.ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com> References: <44643BFD.3040708@trash.net> <20060515210342.GP7774@kenobi.snowman.net> <446AC1FB.5070406@trash.net> <200606010943.31554.ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com> Message-ID: <447EFF72.1050803@trash.net> [CC-list trimmed] Andrew James Wade wrote: > Hello Mr. McHardy, > > The BUG below appears to be related to your ipt_recent rewrite. I > haven't tracked it down further yet. I've attached the (toy) firewall > script that's triggering the bug. Yes, that was my fault. These two patches should fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: 01.diff Type: text/x-patch Size: 2421 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060601/5684708d/01.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 02.diff Type: text/x-patch Size: 915 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060601/5684708d/02.bin From kaber at trash.net Thu Jun 1 17:01:42 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 17:24:35 2006 Subject: [PATCH] 2.6.16.19 Fix the bug of "return 0 instead of the error code in ipt_register_table" In-Reply-To: <20060601102449.GA8572@gsy2.lepton.home> References: <20060601102449.GA8572@gsy2.lepton.home> Message-ID: <447F0156.8020603@trash.net> lepton wrote: > Hi, > > There is a bug in ipt_register_table() in > net/ipv4/netfilter/ip_tables.c: > > ipt_register_table() will return 0 instead of > the error code when xt_register_table() fails > > Signed-off-by: Lepton Wu > > diff -prU 10 linux-2.6.16.19.oirg/net/ipv4/netfilter/ip_tables.c linux-2.6.16.19/net/ipv4/netfilter/ip_tables.c > --- linux-2.6.16.19.oirg/net/ipv4/netfilter/ip_tables.c 2006-05-31 08:31:44.000000000 +0800 > +++ linux-2.6.16.19/net/ipv4/netfilter/ip_tables.c 2006-06-01 18:11:25.000000000 +0800 Thanks. As usual this bug has been happily copy and pasted around, so I've added this patch instead. -------------- next part -------------- [NETFILTER]: x_tables: fix xt_register_table error propagation When xt_register_table fails the error is not properly propagated back. Based on patch by Lepton Wu . Signed-off-by: Patrick McHardy --- commit b010cc3184ce7cb65a9865ae52ec2ce6f3fe4c9d tree 9744395bcd9c7d976048ebd8afbabfc0a9b542a4 parent 10263005af5814396b8263c1c2a4367d49548e13 author Patrick McHardy Thu, 01 Jun 2006 16:59:12 +0200 committer Patrick McHardy Thu, 01 Jun 2006 16:59:12 +0200 net/ipv4/netfilter/arp_tables.c | 3 ++- net/ipv4/netfilter/ip_tables.c | 3 ++- net/ipv6/netfilter/ip6_tables.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c index d0d1919..ad39bf6 100644 --- a/net/ipv4/netfilter/arp_tables.c +++ b/net/ipv4/netfilter/arp_tables.c @@ -1120,7 +1120,8 @@ int arpt_register_table(struct arpt_tabl return ret; } - if (xt_register_table(table, &bootstrap, newinfo) != 0) { + ret = xt_register_table(table, &bootstrap, newinfo); + if (ret != 0) { xt_free_table_info(newinfo); return ret; } diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c index cee3397..101ad98 100644 --- a/net/ipv4/netfilter/ip_tables.c +++ b/net/ipv4/netfilter/ip_tables.c @@ -2113,7 +2113,8 @@ int ipt_register_table(struct xt_table * return ret; } - if (xt_register_table(table, &bootstrap, newinfo) != 0) { + ret = xt_register_table(table, &bootstrap, newinfo); + if (ret != 0) { xt_free_table_info(newinfo); return ret; } diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c index 2e72f89..0b5bd55 100644 --- a/net/ipv6/netfilter/ip6_tables.c +++ b/net/ipv6/netfilter/ip6_tables.c @@ -1281,7 +1281,8 @@ int ip6t_register_table(struct xt_table return ret; } - if (xt_register_table(table, &bootstrap, newinfo) != 0) { + ret = xt_register_table(table, &bootstrap, newinfo); + if (ret != 0) { xt_free_table_info(newinfo); return ret; } From kaber at trash.net Thu Jun 1 18:13:27 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 18:36:02 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes In-Reply-To: <1149153349.28481.15.camel@localhost.localdomain> References: <1149153349.28481.15.camel@localhost.localdomain> Message-ID: <447F1227.7050900@trash.net> Jesper Dangaard Brouer wrote: > I have experienced some concurrency issues with the iptables > userspace program. Executing an iptables (write) command while > another (write command) is running causes a failure of the command. > Well, this is the expected semantics of a non-blocking call, but the > issue is how the error situation is reported back. > > The iptables command detects the situation and reports: > "iptables: Resource temporarily unavailable" > > With shell exitcode "1". What annoys me is that the shell exitcode > is "1", which is also used for "normal" errors. This means that my > code/scripts needs to parse output from stderr to distinguish it from > normal/expected errors. > > I propose that the exitcode of "Resource temporarily unavailable" > error is changed to something unique for this situation. Wouldn't it make more sense to just make sure you don't have iptables commands running concurrently? From kaber at trash.net Thu Jun 1 20:22:39 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 20:45:25 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255414@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255414@xavier.staff.greatlakes.net> Message-ID: <447F306F.3080708@trash.net> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > However, this still does not work: > > Chain POSTROUTING (policy ACCEPT 812K packets, 441M bytes) > pkts bytes target prot opt in out source > destination > 2071 129K CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 1c7:0 > 2 521 CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 1c8:0 > 0 0 CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 1c9:0 > 2760 4060K CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 1db:0 > 3 500 CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 1dc:0 > 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 1dd:0 > > > wireless-r1 bwlimit # tc -s qdisc show dev wivl4 > qdisc hfsc 5: default 2 > Sent 8554815 bytes 7797 pkt (dropped 6, overlimits 13 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > qdisc sfq 1db: parent 5:1fe limit 128p quantum 1514b > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > qdisc sfq 1dc: parent 5:1ff limit 128p quantum 1514b > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > qdisc sfq 1dd: parent 5:200 limit 128p quantum 1514b > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 I already told you why this doesn't work, you have to classify to the _classes_, not the qdiscs. From kaber at trash.net Thu Jun 1 20:38:47 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 21:01:23 2006 Subject: nf_conntrack_proto_sctp.c:(.text+0x2e660): undefined reference to `local_bh_disable' In-Reply-To: <200606010430.k514USg6006278@toshiba.co.jp> References: <200605311253.54503.toralf.foerster@gmx.de> <200606010301.k5131Tk1012237@toshiba.co.jp> <200606010430.k514USg6006278@toshiba.co.jp> Message-ID: <447F3437.6060703@trash.net> Yasuyuki KOZAKAI wrote: > [NETFILTER] nf_conntrack: Fix undefined references to local_bh_* Applied, thanks Yasuyuki. From support8 at greatlakes.net Thu Jun 1 20:49:51 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Thu Jun 1 21:09:14 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB255415@xavier.staff.greatlakes.net> -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Thursday, June 01, 2006 2:23 PM To: Eliot, Wireless and Server Administrator, Great Lakes Internet Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist Subject: Re: [LARTC] iptables CLASSIFY and MARK not working? > Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > > However, this still does not work: > > > > Chain POSTROUTING (policy ACCEPT 812K packets, 441M bytes) > > pkts bytes target prot opt in out source > > destination > > 2071 129K CLASSIFY all -- * br1 0.0.0.0/0 > > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 1c7:0 > > 2 521 CLASSIFY all -- * br1 0.0.0.0/0 > > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 1c8:0 > > 0 0 CLASSIFY all -- * br1 0.0.0.0/0 > > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 1c9:0 > > 2760 4060K CLASSIFY all -- * wivl4 0.0.0.0/0 > > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 1db:0 > > 3 500 CLASSIFY all -- * wivl4 0.0.0.0/0 > > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 1dc:0 > > 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 > > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 1dd:0 > > > > > > wireless-r1 bwlimit # tc -s qdisc show dev wivl4 > > qdisc hfsc 5: default 2 > > Sent 8554815 bytes 7797 pkt (dropped 6, overlimits 13 requeues 0) > > rate 0bit 0pps backlog 0b 0p requeues 0 > > qdisc sfq 1db: parent 5:1fe limit 128p quantum 1514b > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > > rate 0bit 0pps backlog 0b 0p requeues 0 > > qdisc sfq 1dc: parent 5:1ff limit 128p quantum 1514b > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > > rate 0bit 0pps backlog 0b 0p requeues 0 > > qdisc sfq 1dd: parent 5:200 limit 128p quantum 1514b > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > > rate 0bit 0pps backlog 0b 0p requeues 0 > > > I already told you why this doesn't work, you have to classify to > the _classes_, not the qdiscs. These rules make it go to the classes instead of the qdisc: - Adding rules to classify traffic on br1 ... - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FE -j CLASSIFY --set-class 0x5:0x1FE - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FF -j CLASSIFY --set-class 0x5:0x1FF - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x200 -j CLASSIFY --set-class 0x5:0x200 - Adding rules to classify traffic on wivl4 ... - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FE -j CLASSIFY --set-class 0x5:0x1FE - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FF -j CLASSIFY --set-class 0x5:0x1FF - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x200 -j CLASSIFY --set-class 0x5:0x200 Chain POSTROUTING (policy ACCEPT 887K packets, 495M bytes) pkts bytes target prot opt in out source destination 8662 508K CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 5:1fe 14 8253 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 5:1ff 0 0 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x200 CLASSIFY set 5:200 845 222K CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 5:1fe 22 5286 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 5:1ff 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x200 CLASSIFY set 5:200 And yet, still nothing hits the classes: wireless-r1 ~ # tc -s class show dev wivl4 class hfsc 5: root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 1 class hfsc 5:1fe parent 5: leaf 1db: sc m1 400000bit d 30.0ms m2 128000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 5:1 parent 5: sc m1 0bit d 2.6ms m2 30000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 5:1ff parent 5: leaf 1dc: sc m1 2560Kbit d 2.0s m2 512000bit ul m1 2560Kbit d 2.0s m2 2048Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 5:2 parent 5: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1 60000Kbit d 2.0s m2 60000Kbit Sent 19906674 bytes 13396 pkt (dropped 9, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 13396 work 19906674 bytes level 0 class hfsc 5:200 parent 5: leaf 1dd: ls m1 1024Kbit d 2.0s m2 1024Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 5:3 parent 5: ls m1 10000Kbit d 2.0s m2 10000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 5:1fa parent 5: leaf 1d7: ls m1 64000bit d 2.0s m2 64000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 5:1f8 parent 5: leaf 1d5: sc m1 400000bit d 30.0ms m2 128000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 5:1f9 parent 5: leaf 1d6: sc m1 160000bit d 2.0s m2 32000bit ul m1 160000bit d 2.0s m2 128000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 wireless-r1 ~ # tc -s class show dev br1 class hfsc 1: root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 1 class hfsc 1:1fe parent 1: leaf 1c7: sc m1 400000bit d 30.0ms m2 128000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1 parent 1: sc m1 0bit d 2.6ms m2 30000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1ff parent 1: leaf 1c8: sc m1 640000bit d 2.0s m2 128000bit ul m1 640000bit d 2.0s m2 512000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:2 parent 1: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1 60000Kbit d 2.0s m2 60000Kbit Sent 856222 bytes 10041 pkt (dropped 13, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 10041 work 856222 bytes level 0 class hfsc 1:200 parent 1: leaf 1c9: ls m1 256000bit d 2.0s m2 256000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:3 parent 1: ls m1 10000Kbit d 2.0s m2 10000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1fa parent 1: leaf 1c3: ls m1 32000bit d 2.0s m2 32000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1f8 parent 1: leaf 1c1: sc m1 400000bit d 30.0ms m2 128000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1f9 parent 1: leaf 1c2: sc m1 80000bit d 2.0s m2 16000bit ul m1 80000bit d 2.0s m2 64000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 No matter how I write these rules, it always still goes to the default class (5:2 or 1:2). If this is still wrong, please give me an example of what I should be writing. Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 From kaber at trash.net Thu Jun 1 21:09:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 21:31:49 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255415@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255415@xavier.staff.greatlakes.net> Message-ID: <447F3B56.7010200@trash.net> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > These rules make it go to the classes instead of the qdisc: > > Chain POSTROUTING (policy ACCEPT 887K packets, 495M bytes) > pkts bytes target prot opt in out source > destination > 8662 508K CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 5:1fe > 14 8253 CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 5:1ff > 0 0 CLASSIFY all -- * br1 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 5:200 > 845 222K CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 5:1fe > 22 5286 CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 5:1ff > 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 > 0.0.0.0/0 MARK match 0x200 CLASSIFY set 5:200 > > > > And yet, still nothing hits the classes: > > > > wireless-r1 ~ # tc -s class show dev wivl4 > class hfsc 5: root > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 1 > > class hfsc 5:1fe parent 5: leaf 1db: sc m1 400000bit d 30.0ms m2 > 128000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 5:1 parent 5: sc m1 0bit d 2.6ms m2 30000Kbit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 5:1ff parent 5: leaf 1dc: sc m1 2560Kbit d 2.0s m2 512000bit > ul m1 2560Kbit d 2.0s m2 2048Kbit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 5:2 parent 5: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1 > 60000Kbit d 2.0s m2 60000Kbit > Sent 19906674 bytes 13396 pkt (dropped 9, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 13396 work 19906674 bytes level 0 > > class hfsc 5:200 parent 5: leaf 1dd: ls m1 1024Kbit d 2.0s m2 1024Kbit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 5:3 parent 5: ls m1 10000Kbit d 2.0s m2 10000Kbit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 5:1fa parent 5: leaf 1d7: ls m1 64000bit d 2.0s m2 64000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 5:1f8 parent 5: leaf 1d5: sc m1 400000bit d 30.0ms m2 > 128000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 5:1f9 parent 5: leaf 1d6: sc m1 160000bit d 2.0s m2 32000bit > ul m1 160000bit d 2.0s m2 128000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > > wireless-r1 ~ # tc -s class show dev br1 > class hfsc 1: root > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 1 > > class hfsc 1:1fe parent 1: leaf 1c7: sc m1 400000bit d 30.0ms m2 > 128000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 1:1 parent 1: sc m1 0bit d 2.6ms m2 30000Kbit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 1:1ff parent 1: leaf 1c8: sc m1 640000bit d 2.0s m2 128000bit > ul m1 640000bit d 2.0s m2 512000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 1:2 parent 1: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1 > 60000Kbit d 2.0s m2 60000Kbit > Sent 856222 bytes 10041 pkt (dropped 13, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 10041 work 856222 bytes level 0 > > class hfsc 1:200 parent 1: leaf 1c9: ls m1 256000bit d 2.0s m2 256000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 1:3 parent 1: ls m1 10000Kbit d 2.0s m2 10000Kbit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 1:1fa parent 1: leaf 1c3: ls m1 32000bit d 2.0s m2 32000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 1:1f8 parent 1: leaf 1c1: sc m1 400000bit d 30.0ms m2 > 128000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > class hfsc 1:1f9 parent 1: leaf 1c2: sc m1 80000bit d 2.0s m2 16000bit > ul m1 80000bit d 2.0s m2 64000bit > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > period 0 level 0 > > > > No matter how I write these rules, it always still goes to the default > class (5:2 or 1:2). If this is still wrong, please give me an example of > what I should be writing. The bridge case doesn't work because you're using the wrong major number (5 instead of 1), the wivl4 rules look correct. I just tested HFSC+CLASSIFY and it works fine for me. What kind of device is wivl4? From support8 at greatlakes.net Thu Jun 1 21:38:38 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Thu Jun 1 21:58:02 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB255419@xavier.staff.greatlakes.net> -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Thursday, June 01, 2006 3:09 PM To: Eliot, Wireless and Server Administrator, Great Lakes Internet Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist Subject: Re: [LARTC] iptables CLASSIFY and MARK not working? > The bridge case doesn't work because you're using the wrong major > number (5 instead of 1), the wivl4 rules look correct. I just tested > HFSC+CLASSIFY and it works fine for me. What kind of device is wivl4? I knew I was going to typo something when I did all that hex conversion this morning. Here is the corrected ruleset: - Adding rules to classify traffic on br1 ... - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FE -j CLASSIFY --set-class 0x1:0x1FE - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1FF -j CLASSIFY --set-class 0x1:0x1FF - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x200 -j CLASSIFY --set-class 0x1:0x200 - Adding rules to classify traffic on wivl4 ... - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FE -j CLASSIFY --set-class 0x5:0x1FE - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1FF -j CLASSIFY --set-class 0x5:0x1FF - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x200 -j CLASSIFY --set-class 0x5:0x200 Here are the new test results: Chain POSTROUTING (policy ACCEPT 900K packets, 496M bytes) pkts bytes target prot opt in out source destination 865 67524 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 1:1fe 16 1216 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 1:1ff 0 0 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x200 CLASSIFY set 1:200 840 91456 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x1fe CLASSIFY set 5:1fe 16 1216 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x1ff CLASSIFY set 5:1ff 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x200 CLASSIFY set 5:200 wireless-r1 bwlimit # tc -s class show dev br1 class hfsc 1: root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 1 class hfsc 1:1fe parent 1: leaf 1c7: sc m1 400000bit d 30.0ms m2 128000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1 parent 1: sc m1 0bit d 2.6ms m2 30000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1ff parent 1: leaf 1c8: sc m1 640000bit d 2.0s m2 128000bit ul m1 640000bit d 2.0s m2 512000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:2 parent 1: ls m1 60000Kbit d 2.0s m2 60000Kbit ul m1 60000Kbit d 2.0s m2 60000Kbit Sent 187981 bytes 1698 pkt (dropped 3, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 1698 work 187981 bytes level 0 class hfsc 1:200 parent 1: leaf 1c9: ls m1 256000bit d 2.0s m2 256000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:3 parent 1: ls m1 10000Kbit d 2.0s m2 10000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1fa parent 1: leaf 1c3: ls m1 32000bit d 2.0s m2 32000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1f8 parent 1: leaf 1c1: sc m1 400000bit d 30.0ms m2 128000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 class hfsc 1:1f9 parent 1: leaf 1c2: sc m1 80000bit d 2.0s m2 16000bit ul m1 80000bit d 2.0s m2 64000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 period 0 level 0 Both devices (br1 and wivl4) are bridged interfaces with spanning tree turned on. They also do VLANs. Specifically, vconfig was used to create a VLAN (in this case, VLAN 4) on two interfaces: eth2 and eth3. These two VLAN interfaces were called e2v4 and e3v4. Then, brctl was used to bridge the two VLAN interfaces (e2v4 and e3v4) into a new interface called wivl4. Spanning tree was then enabled on wivl4. The MTU size was then adjusted -4 bytes to accommodate the VLAN tagging. Also, did you happen to try my specific rules (under different devices) to see if they work? If possible, could you try creating a VLAN interface and test on that interface? Then try a bridged interface. And finally, a bridged VLAN interface. I will try to set this all up on a different machine without the bridged VLANs and see if it works there. Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. From kaber at trash.net Thu Jun 1 21:44:12 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 22:06:49 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255419@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255419@xavier.staff.greatlakes.net> Message-ID: <447F438C.4080606@trash.net> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > Both devices (br1 and wivl4) are bridged interfaces with spanning tree > turned on. They also do VLANs. Specifically, vconfig was used to create > a VLAN (in this case, VLAN 4) on two interfaces: eth2 and eth3. These > two VLAN interfaces were called e2v4 and e3v4. Then, brctl was used to > bridge the two VLAN interfaces (e2v4 and e3v4) into a new interface > called wivl4. Spanning tree was then enabled on wivl4. The MTU size was > then adjusted -4 bytes to accommodate the VLAN tagging. Any chance you got bridge netfilter enabled? If so please disable it and try again (or set the bridge-nf-call-iptables sysctl to 0). > Also, did you happen to try my specific rules (under different devices) > to see if they work? No, just tried CLASSIFY with my own HFSC setup, which is pretty similar. > If possible, could you try creating a VLAN interface and test on that > interface? Then try a bridged interface. And finally, a bridged VLAN > interface. > > I will try to set this all up on a different machine without the bridged > VLANs and see if it works there. I checked the code, neither VLAN nor bridge should matter. From support8 at greatlakes.net Thu Jun 1 21:58:44 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Thu Jun 1 22:18:05 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB25541A@xavier.staff.greatlakes.net> -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Thursday, June 01, 2006 3:44 PM To: Eliot, Wireless and Server Administrator, Great Lakes Internet Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist Subject: Re: [LARTC] iptables CLASSIFY and MARK not working? > Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > > Both devices (br1 and wivl4) are bridged interfaces with spanning tree > > turned on. They also do VLANs. Specifically, vconfig was used to create > > a VLAN (in this case, VLAN 4) on two interfaces: eth2 and eth3. These > > two VLAN interfaces were called e2v4 and e3v4. Then, brctl was used to > > bridge the two VLAN interfaces (e2v4 and e3v4) into a new interface > > called wivl4. Spanning tree was then enabled on wivl4. The MTU size was > > then adjusted -4 bytes to accommodate the VLAN tagging. > > Any chance you got bridge netfilter enabled? If so please disable > it and try again (or set the bridge-nf-call-iptables sysctl to 0). > > Also, did you happen to try my specific rules (under different devices) > to see if they work? > > No, just tried CLASSIFY with my own HFSC setup, which is pretty > similar. > > > If possible, could you try creating a VLAN interface and test on that > > interface? Then try a bridged interface. And finally, a bridged VLAN > > interface. > > > > I will try to set this all up on a different machine without the bridged > > VLANs and see if it works there. > > I checked the code, neither VLAN nor bridge should matter. Bridged iptables (ebtables) is not enabled in the kernel and I cannot seem to find a variable "bridge-nf-call-iptables" to set with sysctl: wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0 error: "bridge-nf-call-iptables" is an unknown key There is also no /proc/sys/net/*/bridge anything. I assume that means this is not something I need to worry about? Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. From kaber at trash.net Thu Jun 1 22:01:36 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 22:24:13 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB25541A@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB25541A@xavier.staff.greatlakes.net> Message-ID: <447F47A0.7000104@trash.net> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > Bridged iptables (ebtables) is not enabled in the kernel and I cannot > seem to find a variable "bridge-nf-call-iptables" to set with sysctl: > > wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0 > error: "bridge-nf-call-iptables" is an unknown key > > There is also no /proc/sys/net/*/bridge anything. I assume that means > this is not something I need to worry about? Not sure yet, the problem would be created by CONFIG_BRIDGE_NETFILTER, not ebtables itself. Check for "/proc/sys/net/bridge/bridge-nf-call-iptables". I'm actually pretty sure that this is indeed what's causing the problem, bridge netfilter defers calling the IP POST_ROUTING hook until the packet was already transmitted over the device (and before it goes out the underlying device), which means when it hits the CLASSIFY target it already passed through the qdisc. From support8 at greatlakes.net Thu Jun 1 22:09:41 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Thu Jun 1 22:29:01 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB25541B@xavier.staff.greatlakes.net> THANK YOU! That solved the problem. I found the file you specified and it was indeed enabled. After disabling it, it is now working! Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Thursday, June 01, 2006 4:02 PM To: Eliot, Wireless and Server Administrator, Great Lakes Internet Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist Subject: Re: [LARTC] iptables CLASSIFY and MARK not working? Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > Bridged iptables (ebtables) is not enabled in the kernel and I cannot > seem to find a variable "bridge-nf-call-iptables" to set with sysctl: > > wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0 > error: "bridge-nf-call-iptables" is an unknown key > > There is also no /proc/sys/net/*/bridge anything. I assume that means > this is not something I need to worry about? Not sure yet, the problem would be created by CONFIG_BRIDGE_NETFILTER, not ebtables itself. Check for "/proc/sys/net/bridge/bridge-nf-call-iptables". I'm actually pretty sure that this is indeed what's causing the problem, bridge netfilter defers calling the IP POST_ROUTING hook until the packet was already transmitted over the device (and before it goes out the underlying device), which means when it hits the CLASSIFY target it already passed through the qdisc. From kaber at trash.net Thu Jun 1 22:10:24 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 22:33:00 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB25541B@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB25541B@xavier.staff.greatlakes.net> Message-ID: <447F49B0.90804@trash.net> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > THANK YOU! > > That solved the problem. I found the file you specified and it was > indeed enabled. After disabling it, it is now working! Good to hear. This crap is causing one weird problem after another, we really need to get rid of it. From hawk at diku.dk Thu Jun 1 22:16:15 2006 From: hawk at diku.dk (Jesper Dangaard Brouer) Date: Thu Jun 1 22:38:52 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes In-Reply-To: <447F1227.7050900@trash.net> References: <1149153349.28481.15.camel@localhost.localdomain> <447F1227.7050900@trash.net> Message-ID: On Thu, 1 Jun 2006, Patrick McHardy wrote: > Jesper Dangaard Brouer wrote: >> I have experienced some concurrency issues with the iptables >> userspace program. Executing an iptables (write) command while >> another (write command) is running causes a failure of the command. >> Well, this is the expected semantics of a non-blocking call, but the >> issue is how the error situation is reported back. >> >> The iptables command detects the situation and reports: >> "iptables: Resource temporarily unavailable" >> >> With shell exitcode "1". What annoys me is that the shell exitcode >> is "1", which is also used for "normal" errors. This means that my >> code/scripts needs to parse output from stderr to distinguish it from >> normal/expected errors. >> >> I propose that the exitcode of "Resource temporarily unavailable" >> error is changed to something unique for this situation. > > > Wouldn't it make more sense to just make sure you don't have iptables > commands running concurrently? I already have implemented (f)locks in my code around the iptables invocations. But the problem can still arise when root executes the iptables command from the shell. Thus, I still need to handle the situation in my code, and a proper exitcode would be nice. In iptables-standalone.c it would be very easy to simply return the errno instead of !res (which always will return 0 or 1). Would that be a feasable solution? Hilsen Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- Someting like: Index: iptables-standalone.c =================================================================== --- iptables-standalone.c (revision 6624) +++ iptables-standalone.c (working copy) @@ -64,9 +64,11 @@ if (ret) ret = iptc_commit(&handle); - if (!ret) + if (!ret) { fprintf(stderr, "iptables: %s\n", iptc_strerror(errno)); + exit(errno); + } exit(!ret); } From kaber at trash.net Thu Jun 1 22:45:56 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 1 23:08:37 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes In-Reply-To: References: <1149153349.28481.15.camel@localhost.localdomain> <447F1227.7050900@trash.net> Message-ID: <447F5204.4080505@trash.net> Jesper Dangaard Brouer wrote: > > On Thu, 1 Jun 2006, Patrick McHardy wrote: > >> Wouldn't it make more sense to just make sure you don't have iptables >> commands running concurrently? > > > I already have implemented (f)locks in my code around the iptables > invocations. But the problem can still arise when root executes the > iptables command from the shell. Thus, I still need to handle the > situation in my code, and a proper exitcode would be nice. > > In iptables-standalone.c it would be very easy to simply return the > errno instead of !res (which always will return 0 or 1). Would that be > a feasable solution? It would probably break other scripts that check for the current (documented) exit codes. I guess adding a new one for this case is fine, other code can't really expect that no new values are ever added. From andrew.j.wade at gmail.com Thu Jun 1 15:43:29 2006 From: andrew.j.wade at gmail.com (Andrew James Wade) Date: Fri Jun 2 13:48:11 2006 Subject: [PATCH] fix mem-leak in netfilter In-Reply-To: <446AC1FB.5070406@trash.net> References: <44643BFD.3040708@trash.net> <20060515210342.GP7774@kenobi.snowman.net> <446AC1FB.5070406@trash.net> Message-ID: <200606010943.31554.ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com> Hello Mr. McHardy, The BUG below appears to be related to your ipt_recent rewrite. I haven't tracked it down further yet. I've attached the (toy) firewall script that's triggering the bug. Regards, Andrew Wade [from 2.6.17-rc5-mm2] BUG: sleeping function called from invalid context at mm/slab.c:2863 in_atomic():1, irqs_disabled():0 [] __kmalloc+0x5c/0xb8 [] proc_create+0x99/0x108 [] create_proc_entry+0x5e/0x9e [] ipt_recent_checkentry+0xfb/0x157 [] translate_table+0x333/0x5c1 [] do_ipt_set_ctl+0xea/0x44f [] ide_execute_command+0x9c/0xcd [] dma_timer_expiry+0x0/0x5d [] ide_execute_command+0xab/0xcd [] nf_sockopt+0xa6/0xd6 [] nf_setsockopt+0x1d/0x22 [] ip_setsockopt+0xa48/0xa64 [] reiserfs_dirty_inode+0x6d/0x76 [] __mark_inode_dirty+0x15a/0x17a [] do_generic_mapping_read+0x5c7/0x5d1 [] prio_tree_insert+0x150/0x207 [] rb_insert_color+0x8f/0xb2 [] prio_tree_remove+0x96/0xa5 [] __cache_free+0x1a6/0x2fc [] kmem_cache_free+0x4d/0x52 [] prio_tree_insert+0x150/0x207 [] kernel_fpu_begin+0x12/0x44 [] mmx_clear_page+0x69/0x81 [] get_page_from_freelist+0x2a2/0x328 [] find_get_page+0x3f/0x56 [] __alloc_pages+0x63/0x28e [] __page_set_anon_rmap+0x2b/0x2f [] __handle_mm_fault+0x14f/0x741 [] __handle_mm_fault+0x1ad/0x741 [] sys_setsockopt+0x5b/0x7b [] sys_socketcall+0x148/0x188 [] do_page_fault+0x0/0x520 [] sysenter_past_esp+0x56/0x79 BUG: unable to handle kernel NULL pointer dereference at virtual address 000000d4 printing eip: c03754c1 *pde = 00000000 Oops: 0000 [#1] PREEMPT last sysfs file: /block/hda/hda1/size CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.17-rc5-mm2 #1) EIP is at ipt_recent_destroy+0x1e/0x8e eax: 00000000 ebx: 00000000 ecx: cea9088a edx: 00000000 esi: c0411680 edi: cea907f0 ebp: d3085660 esp: cf308ca4 ds: 007b es: 007b ss: 0068 Process iptables (pid: 3669, threadinfo=cf308000 task=d33b7050) Stack: cea90860 c0374bde c0411740 cea90880 000000d4 cf2c6000 08056a18 d30859f0 000000b0 e1ddc000 cea90000 000007f0 00000070 dfffb080 00000000 c01485f3 dfff6ac8 746c6966 00007265 00000000 00000000 00000000 00000000 00000000 Call Trace: [] do_ipt_set_ctl+0x1fb/0x44f [] __cache_free+0x1a6/0x2fc [] nf_sockopt+0xa6/0xd6 [] nf_setsockopt+0x1d/0x22 [] ip_setsockopt+0xa48/0xa64 [] __d_lookup+0xa7/0x13c [] __d_lookup+0x11f/0x13c [] current_fs_time+0x3e/0x58 [] touch_atime+0x67/0x9f [] do_generic_mapping_read+0x5c7/0x5d1 [] prio_tree_insert+0x150/0x207 [] rb_insert_color+0x8f/0xb2 [] prio_tree_remove+0x96/0xa5 [] __cache_free+0x1a6/0x2fc [] kmem_cache_free+0x4d/0x52 [] prio_tree_insert+0x150/0x207 [] kernel_fpu_begin+0x12/0x44 [] mmx_clear_page+0x69/0x81 [] get_page_from_freelist+0x2a2/0x328 [] find_get_page+0x3f/0x56 [] __alloc_pages+0x63/0x28e [] __page_set_anon_rmap+0x2b/0x2f [] __handle_mm_fault+0x14f/0x741 [] __handle_mm_fault+0x1ad/0x741 [] sys_setsockopt+0x5b/0x7b [] sys_socketcall+0x148/0x188 [] do_page_fault+0x0/0x520 [] sysenter_past_esp+0x56/0x79 Code: 3b 3d 78 6a 4e c0 72 df 5b 5e 5f 5d c3 53 8b 5c 24 0c e8 cd 34 da ff b8 01 00 00 00 e8 1f b1 d9 ff 8d 43 0a e8 2f fb ff ff 89 c3 <8b> 80 d4 00 00 00 48 85 c0 89 83 d4 00 00 00 75 4f 8b 53 04 39 EIP: [] ipt_recent_destroy+0x1e/0x8e SS:ESP 0068:cf308ca4 <0>Kernel panic - not syncing: Fatal exception in interrupt -------------- next part -------------- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17-rc5-mm2 # Thu Jun 1 08:02:06 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set CONFIG_SYSCTL=y # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_KLIBC_ERRLIST=y CONFIG_KLIBC_ZLIB=y CONFIG_UID16=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_RT_MUTEXES=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # # CONFIG_MODULES is not set # # Block layer # # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_ALIGNED_ZONE_BOUNDARIES=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_UNALIGNED_ZONE_BOUNDARIES is not set CONFIG_ADAPTIVE_READAHEAD=y CONFIG_DEBUG_READAHEAD=y CONFIG_READAHEAD_SMOOTH_AGING=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_KEXEC is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RESOURCES_32BIT is not set CONFIG_COMPAT_VDSO=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y # CONFIG_ACPI_SLEEP is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y # CONFIG_ACPI_HOTKEY is not set # CONFIG_ACPI_FAN is not set CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_ATLAS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_SONY=y CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_DEBUG is not set CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Networking # CONFIG_NET=y # # Networking options # # CONFIG_NETDEBUG is not set CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_BIC=y # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=y # CONFIG_NETFILTER_NETLINK_LOG is not set # CONFIG_NF_CONNTRACK is not set CONFIG_NETFILTER_XTABLES=y # CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set # CONFIG_NETFILTER_XT_TARGET_MARK is not set # CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set # CONFIG_NETFILTER_XT_MATCH_COMMENT is not set # CONFIG_NETFILTER_XT_MATCH_DCCP is not set # CONFIG_NETFILTER_XT_MATCH_ESP is not set # CONFIG_NETFILTER_XT_MATCH_LENGTH is not set # CONFIG_NETFILTER_XT_MATCH_LIMIT is not set # CONFIG_NETFILTER_XT_MATCH_MAC is not set # CONFIG_NETFILTER_XT_MATCH_MARK is not set # CONFIG_NETFILTER_XT_MATCH_POLICY is not set # CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set # CONFIG_NETFILTER_XT_MATCH_QUOTA is not set # CONFIG_NETFILTER_XT_MATCH_REALM is not set # CONFIG_NETFILTER_XT_MATCH_SCTP is not set # CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set # CONFIG_NETFILTER_XT_MATCH_STRING is not set # CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y # CONFIG_IP_NF_MATCH_IPRANGE is not set # CONFIG_IP_NF_MATCH_TOS is not set CONFIG_IP_NF_MATCH_RECENT=y # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_DSCP is not set # CONFIG_IP_NF_MATCH_AH is not set # CONFIG_IP_NF_MATCH_TTL is not set # CONFIG_IP_NF_MATCH_OWNER is not set # CONFIG_IP_NF_MATCH_ADDRTYPE is not set # CONFIG_IP_NF_MATCH_HASHLIMIT is not set CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y # CONFIG_IP_NF_TARGET_LOG is not set # CONFIG_IP_NF_TARGET_ULOG is not set CONFIG_IP_NF_TARGET_TCPMSS=y # CONFIG_IP_NF_MANGLE is not set # CONFIG_IP_NF_RAW is not set # CONFIG_IP_NF_ARPTABLES is not set # # DCCP Configuration (EXPERIMENTAL) # # CONFIG_IP_DCCP is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # # TIPC Configuration (EXPERIMENTAL) # # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_IEEE80211 is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # CONFIG_SYS_HYPERVISOR is not set # # Connector - unified userspace <-> kernelspace linker # # CONFIG_CONNECTOR is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_CS5535 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_DOMAIN_ATTRS is not set # # SCSI low-level drivers # # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_SRP is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Network device support # CONFIG_NETDEVICES=y # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # PHY device support # # CONFIG_PHYLIB is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set CONFIG_8139TOO=y # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # # Ethernet (10000 Mbit) # # CONFIG_CHELSIO_T1 is not set # CONFIG_IXGB is not set # CONFIG_S2IO is not set # CONFIG_MYRI10GE is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_EFFECTS is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=y CONFIG_HW_RANDOM_AMD=y CONFIG_HW_RANDOM_GEODE=y CONFIG_HW_RANDOM_VIA=y # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=y # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_MWAVE is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y # CONFIG_HANGCHECK_TIMER is not set # # TPM devices # # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set # # I2C support # CONFIG_I2C=y CONFIG_I2C_CHARDEV=y # # I2C Algorithms # CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set CONFIG_I2C_VIAPRO=y # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # CONFIG_I2C_OCORES is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_DS1374 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # # Dallas's 1-wire bus # # # Hardware Monitoring support # CONFIG_HWMON=y CONFIG_HWMON_VID=y # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set CONFIG_SENSORS_ASB100=y # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set CONFIG_VIDEO_V4L2=y # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # CONFIG_USB_DABUSB is not set # # Graphics support # CONFIG_FIRMWARE_EDID=y CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_VESA is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=y CONFIG_FB_RADEON_I2C=y # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set # CONFIG_VIDEO_SELECT is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set CONFIG_FONTS=y # CONFIG_FONT_8x8 is not set CONFIG_FONT_8x16=y # CONFIG_FONT_6x11 is not set # CONFIG_FONT_7x14 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # CONFIG_FONT_MINI_4x6 is not set # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_10x18 is not set # # Logo configuration # # CONFIG_LOGO is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_HWDEP=y CONFIG_SND_RAWMIDI=y CONFIG_SND_SEQUENCER=y # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=y CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y # CONFIG_SND_DYNAMIC_MINORS is not set # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=y CONFIG_SND_OPL3_LIB=y # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # PCI devices # # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set CONFIG_SND_CMIPCI=y # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_HDA_INTEL is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_ACECAD is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_TOUCHSCREEN is not set # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_MON is not set # # USB port drivers # # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_GOTEMP is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TEST is not set # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # LED devices # # CONFIG_NEW_LEDS is not set # # LED drivers # # # LED Triggers # # # InfiniBand support # # CONFIG_INFINIBAND is not set # # EDAC - error detection and reporting (RAS) (EXPERIMENTAL) # # CONFIG_EDAC is not set # # Real Time Clock # # CONFIG_RTC_CLASS is not set # # DMA Engine support # # CONFIG_DMA_ENGINE is not set # # DMA Clients # # # DMA Devices # # # File systems # # CONFIG_EXT2_FS is not set # CONFIG_EXT3_FS is not set CONFIG_REISER4_FS=y # CONFIG_REISER4_DEBUG is not set CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_REISERFS_FS_XATTR is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_PROC_KCORE is not set CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_SMB_FS is not set CONFIG_CIFS=y # CONFIG_CIFS_STATS is not set # CONFIG_CIFS_WEAK_PW_HASH is not set # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Distributed Lock Manager # # # Instrumentation Support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_MAGIC_SYSRQ=y CONFIG_UNUSED_SYMBOLS=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_MUTEX_ALLOC=y CONFIG_DEBUG_MUTEX_DEADLOCKS=y CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_PROVE_SPIN_LOCKING is not set # CONFIG_PROVE_RW_LOCKING is not set # CONFIG_PROVE_MUTEX_LOCKING is not set # CONFIG_PROVE_RWSEM_LOCKING is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_PAGE_OWNER is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set # CONFIG_FRAME_POINTER is not set # CONFIG_UNWIND_INFO is not set CONFIG_FORCED_INLINING=y # CONFIG_DEBUG_SYNCHRO_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_PROFILE_LIKELY is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_KGDB is not set CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set CONFIG_STACK_BACKTRACE_COLS=1 # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_DEBUG_RODATA=y CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Hardware crypto devices # # # Library routines # # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y -------------- next part -------------- A non-text attachment was scrubbed... Name: tarpit Type: application/x-shellscript Size: 1889 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060601/b1d036d0/tarpit-0001.bin From azez at ufomechanic.net Fri Jun 2 14:46:27 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 2 15:09:17 2006 Subject: [RFC][0/2] New netfilter match module In-Reply-To: <20060531011443.95001.qmail@web50208.mail.yahoo.com> References: <20060531011443.95001.qmail@web50208.mail.yahoo.com> Message-ID: <44803323.5000706@ufomechanic.net> Alex Davis wrote: > The scenario: > > A box is functioning as a NATting firewall with a public and a private network interface, > hereafter referred to as pub0 and priv0. Connected to priv0 are several boxes, one of > which is a web server. The public IP address is dynamic. Running an internal DNS server > is not an option. A dynamic DNS provider is used to keep the public host name of the firewall > sync'ed with its public IP address, which is assigned to pub0. > > > > The problem: > > There is no reliable way to direct network traffic from the private network hosts for the public > IP address of the firewall to the web server, and still have traffic not destined for the public > address go to the correct destination. For example, one could create the following rule: > > iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination > > but this directs _all_ port 80 traffic to the web server. The rule > > iptables -t nat -A PREROUTING -p tcp -d --dport 80 \ > -j DNAT --to-destination > > works fine, until the public address changes. I think a general solution like this is good. Specially, however, could you not solve it using ! with a rule like: iptables -t nat -A PREROUTING -p tcp -s ! 10.18.0.0/24 --dport 80 \ -j DNAT --to-destination i.e. for non locally originating traffic to port 80, use the webserver Of course if you had multiple local subnets you might need iptables -t nat -A PREROUTING -j try_80 iptables -t nat -A try_80 -p tcp -s 10.18.0.0/24 -j RETURN iptables -t nat -A try_80 -p tcp -s 10.18.20.0/24 -j RETURN iptables -t nat -A try_80 -p tcp --dport 80 -j DNAT --to-destination Sam From kaber at trash.net Fri Jun 2 16:57:55 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Jun 2 17:20:36 2006 Subject: Bridge netfilter defered hooks Message-ID: <448051F3.1070509@trash.net> Bart, I would like to get another discussion going about what to do about the physdev match and the hook deferal done by bridge netfilter. The lastest addition to the list of things it breaks is qdisc classification on the bridge device using MARK or CLASSIFY. The main question is if the feature that causes all this trouble (output port matching within iptables) really is useful at all. It is not needed for filtering based on the output port of a bridge, this can be done using ebtables and iptables+mark if necessary. The only thing I can see that can't be done using ebtables is NAT based on the output port. I somehow doubt that this is really worth all the trouble, google show about 20 hits for "-t nat" "-m physdev" "--physdev-out", half of which appear to be examples in some magazines. So my prefered solution would be to deprecate it and remove it in a couple of month. For a short-term solution we should also think about whether the hook deferal really needs to be done by default or if the few users that appear to be using this can't just enable it manually. From paul at astro.gla.ac.uk Fri Jun 2 18:37:15 2006 From: paul at astro.gla.ac.uk (Paul Millar) Date: Fri Jun 2 19:00:05 2006 Subject: Patch for graphing a rule-set Message-ID: <200606021737.20890.paul@astro.gla.ac.uk> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060602/4a173ff4/attachment.pgp From bdschuym at pandora.be Fri Jun 2 19:00:10 2006 From: bdschuym at pandora.be (Bart De Schuymer) Date: Fri Jun 2 19:22:51 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <448051F3.1070509@trash.net> References: <448051F3.1070509@trash.net> Message-ID: <1149267610.3021.11.camel@localhost.localdomain> Op vr, 02-06-2006 te 16:57 +0200, schreef Patrick McHardy: > Bart, I would like to get another discussion going about what > to do about the physdev match and the hook deferal done by > bridge netfilter. The lastest addition to the list of things > it breaks is qdisc classification on the bridge device using > MARK or CLASSIFY. > > The main question is if the feature that causes all this trouble > (output port matching within iptables) really is useful at all. > It is not needed for filtering based on the output port of a > bridge, this can be done using ebtables and iptables+mark if > necessary. The only thing I can see that can't be done using > ebtables is NAT based on the output port. I somehow doubt that > this is really worth all the trouble, google show about 20 hits > for "-t nat" "-m physdev" "--physdev-out", half of which appear > to be examples in some magazines. So my prefered solution would > be to deprecate it and remove it in a couple of month. Sounds reasonable. You of course missed the combination of any of the iptables specific matches/targets with the physdev match. I'm against removing --physdev-out completely, since it's perfectly usable without causing problems (AFAIK) for filtering purely bridged packets. I don't object to disabling the functionality for packets that get routed to a bridge device. Most of those situations can probably be fixed by routing the packets to the bridge ports instead. > For a short-term solution we should also think about whether > the hook deferal really needs to be done by default or if the > few users that appear to be using this can't just enable it > manually. I have no objections to this either. The physdev module can be modified so that it sends a warning to the syslog if --physdev-out is used in non-bridging mode (meaning the rule is probably erroneous). cheers, Bart From support8 at greatlakes.net Fri Jun 2 19:06:23 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Fri Jun 2 19:25:52 2006 Subject: Bi-directional packet classification with ACK prioritization Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB255421@xavier.staff.greatlakes.net> Sorry for making this a cross-post, but the pressure is on for getting this bandwidth shaper working. I have an interesting dilemma with bi-directional packet classification while doing ACK prioritization. This is an overly simplified summary of my setup: Internet | Eth0 | Router | Eth1 | Intranet A client on the Intranet establishes a flow to a server on the Internet. Packets get classified into 3 different priority bands. Priority 1 is for VoIP, DNS, SSH, Telnet, and ACK packets with no data payload. Priority 2 is for general traffic that does not fall into band 1 or band 3. Priority 3 band is for P2P. When the flow (download) is established, it starts out with the packets coming in on Priority Band 2. The client then sends an ACK packet to the server with no data payload. The router then classifies that ACK packet into Priority Band 1 and saves the mark that was set to put it in that classification. A response then comes back from the server and the router restores the mark it previously saved. Now it is flagged for Priority Band 1. The packet now traverses the iptables ruleset and remains classified as Priority Band 1 because the rules that classify it in a different manner don't trigger. The reason these rules don't trigger is that the original marking in the outbound direction is done on SOURCE MAC address. Since I can't classify on SOURCE MAC address for packets coming back from the Internet, I am left with using the CONNMARK --restore-mark option. The response packet thus gets classified back into Priority Band 1 for going back out to the client on the Intranet. This problem will be true for generally classified traffic and P2P traffic. I would use tc filters in one direction if I could possibly distinguish P2P traffic from other types of traffic with them. Essentially, what I need to be able to do is match on _destination_ MAC address in the iptables POSTROUTING chain in the mangle table, but do this _before_ it goes through the tc packet classification. Ideally, what should happen is: ACK packets with no data payload always get classified in Priority Band 1 and the rest of their flow's data gets classified in either Priority Band 2 or 3 depending on the type of their traffic (or Priority Band 1 if it happens to be VoIP, Telnet, SSH, or DNS). This should happen for all traffic going in both directions. These are my iptables rules for a single client: - Adding rules to classify traffic for 00:13:D3:67:D7:05 - iptables -A macfilter -m mac --mac-source 00:13:D3:67:D7:05 - iptables -I macfilter_nat -t nat -m mac --mac-source 00:13:D3:67:D7:05 -j ACCEPT - Adding rules to flag General traffic - iptables -A PREROUTING -t mangle -m mac --mac-source 00:13:D3:67:D7:05 -j MARK --set-mark 0x1A5 - iptables -A PREROUTING -t mangle -m mark --mark 0x1A5 -j CONNMARK --save-mark - Adding rules to flag VoIP / Interactive traffic - iptables -A PREROUTING -t mangle -p udp -m mac --mac-source 00:13:D3:67:D7:05 -m multiport --ports 53,4569,5060,10000:20000 -j MARK --set-mark 420 - iptables -A PREROUTING -t mangle -p tcp -m mac --mac-source 00:13:D3:67:D7:05 -m multiport --ports 22,23,53 -j MARK --set-mark 0x1A4 - iptables -A PREROUTING -t mangle -p icmp -m mac --mac-source 00:13:D3:67:D7:05 -j MARK --set-mark 0x1A4 - iptables -A PREROUTING -t mangle -p tcp --tcp-flags SYN,RST,ACK ACK -m length --length :128 -m mac --mac-source 00:13:D3:67:D7:05 -j MARK --set-mark 0x1A4 - iptables -A PREROUTING -t mangle -m mark --mark 0x1A4 -j CONNMARK --save-mark - Adding rules to flag P2P traffic - iptables -A PREROUTING -t mangle -m mac --mac-source 00:13:D3:67:D7:05 -m ipp2p --ipp2p -j MARK --set-mark 0x1A6 - iptables -A PREROUTING -t mangle -m mark --mark 0x1A6 -j CONNMARK --save-mark - iptables -I FORWARD -t mangle -m mark --mark 0x1A4 -j ACCEPT - iptables -I FORWARD -t mangle -m mark --mark 0x1A5 -j ACCEPT - iptables -I FORWARD -t mangle -m mark --mark 0x1A6 -j ACCEPT - Adding rules to classify traffic on br1 - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1A4 -j CLASSIFY --set-class 0x1:0x1A4 - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1A5 -j CLASSIFY --set-class 0x1:0x1A5 - iptables -A POSTROUTING -t mangle -o br1 -m mark --mark 0x1A6 -j CLASSIFY --set-class 0x1:0x1A6 - Adding rules to classify traffic on wivl4 - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1A4 -j CLASSIFY --set-class 0x5:0x1A4 - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1A5 -j CLASSIFY --set-class 0x5:0x1A5 - iptables -A POSTROUTING -t mangle -o wivl4 -m mark --mark 0x1A6 -j CLASSIFY --set-class 0x5:0x1A6 In these rules, wivl4 is equivalent to eth1 up in the diagram and br1 is equivalent to eth0. Also, the unshown CONNMARK --restore-mark rule is the first rule in the PREROUTING mangle chain. If anyone could be of assistance in solving this little dilemma, it would be greatly appreciated. Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. From kaber at trash.net Fri Jun 2 19:18:52 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Jun 2 19:41:54 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <1149267610.3021.11.camel@localhost.localdomain> References: <448051F3.1070509@trash.net> <1149267610.3021.11.camel@localhost.localdomain> Message-ID: <448072FC.3060902@trash.net> Bart De Schuymer wrote: > Op vr, 02-06-2006 te 16:57 +0200, schreef Patrick McHardy: > >>Bart, I would like to get another discussion going about what >>to do about the physdev match and the hook deferal done by >>bridge netfilter. The lastest addition to the list of things >>it breaks is qdisc classification on the bridge device using >>MARK or CLASSIFY. >> >>The main question is if the feature that causes all this trouble >>(output port matching within iptables) really is useful at all. >>It is not needed for filtering based on the output port of a >>bridge, this can be done using ebtables and iptables+mark if >>necessary. The only thing I can see that can't be done using >>ebtables is NAT based on the output port. I somehow doubt that >>this is really worth all the trouble, google show about 20 hits >>for "-t nat" "-m physdev" "--physdev-out", half of which appear >>to be examples in some magazines. So my prefered solution would >>be to deprecate it and remove it in a couple of month. > > > Sounds reasonable. You of course missed the combination of any of the > iptables specific matches/targets with the physdev match. Thats what I meant by "iptables+mark". You can combine iptables specific matches by marking matching packets, then match on the mark with ebtables (or the other way around for incoming packets). > I'm against removing --physdev-out completely, since it's perfectly > usable without causing problems (AFAIK) for filtering purely bridged > packets. I'm fine with that as long as it doesn't stand in the way of getting rid of the defered hooks, but I think you're right and it won't. > I don't object to disabling the functionality for packets that get > routed to a bridge device. Most of those situations can probably be > fixed by routing the packets to the bridge ports instead. > >>For a short-term solution we should also think about whether >>the hook deferal really needs to be done by default or if the >>few users that appear to be using this can't just enable it >>manually. > > > I have no objections to this either. The physdev module can be modified > so that it sends a warning to the syslog if --physdev-out is used in > non-bridging mode (meaning the rule is probably erroneous). Great, I'll look into this. Thanks. From shemminger at osdl.org Fri Jun 2 20:15:11 2006 From: shemminger at osdl.org (Stephen Hemminger) Date: Fri Jun 2 20:37:55 2006 Subject: Bridge netfilter MTU discovery Message-ID: <20060602111511.7d08f33c@localhost.localdomain> Is there an easy way to force bridge packets to cause an ICMP frag needed if the MTU of the destination is too small. Normal bridging will just drop the packet, but a rule to send ICMP would allow PMTU to work. Maybe even having a module to fragment would be good. From alex14641 at yahoo.com Fri Jun 2 21:02:38 2006 From: alex14641 at yahoo.com (Alex Davis) Date: Fri Jun 2 21:25:22 2006 Subject: [RFC][1/2] New netfilter match module : kernel patch Message-ID: <20060602190238.92524.qmail@web50208.mail.yahoo.com> This is an update the kernel netfilter patch that allows matching the source or destination address of an IP packet to a network interface. Instead of hard-coding the dimension of the ifname struct member, use the IFNAMSIZ macro. diff -u -Pr linux-2.6.16.16/include/linux/netfilter/xt_ipisforif.h linux-2.6.16.16-ipisforif/include/linux/netfilter/xt_ipisforif.h --- linux-2.6.16.16/include/linux/netfilter/xt_ipisforif.h 1969-12-31 19:00:00.000000000 -0500 +++ linux-2.6.16.16-ipisforif/include/linux/netfilter/xt_ipisforif.h 2006-06-02 10:18:22.000000000 -0400 @@ -0,0 +1,15 @@ +#ifndef _XT_IPISFORIF_H +#define _XT_IPISFORIF_H + +#include + +#define TYPE_SRC 1 +#define TYPE_DST 2 + +struct xt_ipisforif_info { + int type; + int invert; + char ifname[IFNAMSIZ]; +}; + +#endif /*_XT_IPISFORIF_H*/ diff -u -Pr linux-2.6.16.16/include/linux/netfilter_ipv4/ipt_ipisforif.h linux-2.6.16.16-ipisforif/include/linux/netfilter_ipv4/ipt_ipisforif.h --- linux-2.6.16.16/include/linux/netfilter_ipv4/ipt_ipisforif.h 1969-12-31 19:00:00.000000000 -0500 +++ linux-2.6.16.16-ipisforif/include/linux/netfilter_ipv4/ipt_ipisforif.h 2006-05-30 02:20:06.000000000 -0400 @@ -0,0 +1,9 @@ +#ifndef _IPT_IPISFORIF_H +#define _IPT_IPISFORIF_H +#include + +/* Backwards compatibility for old userspace */ + +#define ipt_ipisforif_info xt_ipisforif_info + +#endif /*_IPT_IPISFORIF_H*/ diff -u -Pr linux-2.6.16.16/net/netfilter/Kconfig linux-2.6.16.16-ipisforif/net/netfilter/Kconfig --- linux-2.6.16.16/net/netfilter/Kconfig 2006-05-29 18:02:43.000000000 -0400 +++ linux-2.6.16.16-ipisforif/net/netfilter/Kconfig 2006-05-29 18:10:06.000000000 -0400 @@ -336,6 +336,15 @@ To compile it as a module, choose M here. If unsure, say N. +config NETFILTER_XT_MATCH_IPISFORIF + tristate '"interface ip" match support' + depends on NETFILTER_XTABLES + help + This matches the source or destination IP address of a packet + against the local address of a network interface. + + To compile it as a module, choose M here. If unsure, say N. + config NETFILTER_XT_MATCH_STRING tristate '"string" match support' depends on NETFILTER_XTABLES diff -u -Pr linux-2.6.16.16/net/netfilter/Makefile linux-2.6.16.16-ipisforif/net/netfilter/Makefile --- linux-2.6.16.16/net/netfilter/Makefile 2006-05-29 18:02:43.000000000 -0400 +++ linux-2.6.16.16-ipisforif/net/netfilter/Makefile 2006-05-29 16:33:48.000000000 -0400 @@ -47,3 +47,4 @@ obj-$(CONFIG_NETFILTER_XT_MATCH_STRING) += xt_string.o obj-$(CONFIG_NETFILTER_XT_MATCH_TCPMSS) += xt_tcpmss.o obj-$(CONFIG_NETFILTER_XT_MATCH_PHYSDEV) += xt_physdev.o +obj-$(CONFIG_NETFILTER_XT_MATCH_IPISFORIF) += xt_ipisforif.o diff -u -Pr linux-2.6.16.16/net/netfilter/xt_ipisforif.c linux-2.6.16.16-ipisforif/net/netfilter/xt_ipisforif.c --- linux-2.6.16.16/net/netfilter/xt_ipisforif.c 1969-12-31 19:00:00.000000000 -0500 +++ linux-2.6.16.16-ipisforif/net/netfilter/xt_ipisforif.c 2006-05-30 09:43:31.000000000 -0400 @@ -0,0 +1,106 @@ +/* Kernel module to match the source or destination address of a + * packet to the IP address of a network interface. + * + * (C) 2006 Alex Davis + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_AUTHOR("Alex Davis"); +MODULE_DESCRIPTION("Match source or destination address of a packet " + "to a network interface"); +MODULE_ALIAS("ipt_ipisforif"); +MODULE_LICENSE("GPL"); + +static int match(const struct sk_buff *skb, + const struct net_device *in, + const struct net_device *out, + const void *matchinfo, + int offset, + unsigned int protoff, + int *hotdrop) +{ + const struct xt_ipisforif_info *info = matchinfo; + struct in_ifaddr *ifa = NULL; + struct in_device *in_dev; + struct net_device *dev; + int ismatch = 0; + + rtnl_lock(); + if ( (dev = __dev_get_by_name(info->ifname)) ) { + if ((in_dev = __in_dev_get_rtnl(dev)) != NULL) { + for (ifa = in_dev->ifa_list; ifa; ifa = ifa->ifa_next) { + if ( ! strcmp(info->ifname, ifa->ifa_label) ) { + break; + } + } + } + } + + if ( ifa ) { + struct iphdr *hdr = skb->nh.iph; + switch (info->type ) { + case TYPE_SRC: + ismatch = ( (hdr->saddr == ifa->ifa_local) && + ( ! info->invert ) ); + break; + + case TYPE_DST: + ismatch = ( (hdr->daddr == ifa->ifa_local) && + ( ! info->invert ) ); + break; + + default: + printk(KERN_INFO "ipisforif: invalid type: %d\n", + info->type); + } + } + rtnl_unlock(); + + return ismatch; +} + +static int check(const char *tablename, + const void *pinf, + void *matchinfo, + unsigned int matchsize, + unsigned int hook_mask) +{ + const struct ipt_ip *inf = pinf; + + return ((inf->proto == IPPROTO_TCP || inf->proto == IPPROTO_UDP) && + ! (inf->invflags & IPT_INV_PROTO)); +} + +static void destroy(void *matchinfo, unsigned int matchsize) { +} + +static struct xt_match ipisforif_match = { + .name = "ipisforif", + .match = &match, + .checkentry = &check, + .destroy = destroy, + .me = THIS_MODULE, +}; + +static int __init init(void) { + return ipt_register_match(&ipisforif_match); +} + +static void __exit exit(void) { + ipt_unregister_match(&ipisforif_match); +} + +module_init(init); +module_exit(exit); I code, therefore I am __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From c-d.hailfinger.devel.2006 at gmx.net Fri Jun 2 22:10:04 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri Jun 2 22:42:34 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <448072FC.3060902@trash.net> References: <448051F3.1070509@trash.net> <1149267610.3021.11.camel@localhost.localdomain> <448072FC.3060902@trash.net> Message-ID: <44809B1C.2010907@gmx.net> Patrick McHardy wrote: > Bart De Schuymer wrote: >> Op vr, 02-06-2006 te 16:57 +0200, schreef Patrick McHardy: >> >>> The main question is if the feature that causes all this trouble >>> (output port matching within iptables) really is useful at all. >>> It is not needed for filtering based on the output port of a >>> bridge, this can be done using ebtables and iptables+mark if >>> necessary.[...] >> >> Sounds reasonable. You of course missed the combination of any of the >> iptables specific matches/targets with the physdev match. > > Thats what I meant by "iptables+mark". You can combine iptables > specific matches by marking matching packets, then match on the > mark with ebtables (or the other way around for incoming packets). IIRC the mark has only 32 bits. Not so long ago, I was using 30 bits of that in my firewalling rules on a bridge-router. I might have squeezed the physdev match in the remaining 2 bits, but I'm not sure. I do admit the setup was fairly uncommon (bridging and double nat with only one machine). Regards, Carl-Daniel -- http://www.hailfinger.org/ From alex14641 at yahoo.com Sat Jun 3 08:55:25 2006 From: alex14641 at yahoo.com (Alex Davis) Date: Sat Jun 3 09:18:13 2006 Subject: [RFC][0/2] New netfilter match module Message-ID: <20060603065525.9380.qmail@web50212.mail.yahoo.com> At some point in the not-too-distant past, Amin Azez wrote: >Specially, however, could you not solve it using ! with a rule like: > >iptables -t nat -A PREROUTING -p tcp -s ! 10.18.0.0/24 --dport 80 \ > -j DNAT --to-destination No traffic from the private network will get routed with this rule, which is not what I want. >iptables -t nat -A PREROUTING -j try_80 >iptables -t nat -A try_80 -p tcp -s 10.18.0.0/24 -j RETURN >iptables -t nat -A try_80 -p tcp -s 10.18.20.0/24 -j RETURN >iptables -t nat -A try_80 -p tcp --dport 80 -j DNAT --to-destination Same as above. -Alex I code, therefore I am __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From lists at andyfurniss.entadsl.com Sat Jun 3 16:40:00 2006 From: lists at andyfurniss.entadsl.com (Andy Furniss) Date: Sat Jun 3 17:01:49 2006 Subject: Bi-directional packet classification with ACK prioritization In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255421@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255421@xavier.staff.greatlakes.net> Message-ID: <44819F40.8050004@andyfurniss.entadsl.com> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > This problem will be true for generally classified traffic and P2P > traffic. I would use tc filters in one direction if I could possibly > distinguish P2P traffic from other types of traffic with them. You can match mark with u32 rather than fw - you then get to use masks and can and it with other matches - like MAC. You can also and/or marks with netfilter. Andy. From support8 at greatlakes.net Sat Jun 3 18:43:08 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Sat Jun 3 19:45:44 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB255436@xavier.staff.greatlakes.net> > -----Original Message----- > From: Patrick McHardy [mailto:kaber@trash.net] > Sent: Thursday, June 01, 2006 4:02 PM > To: Eliot, Wireless and Server Administrator, Great Lakes Internet > Cc: lartc@mailman.ds9a.nl; Netfilter Development Mailinglist > Subject: Re: [LARTC] iptables CLASSIFY and MARK not working? > > Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > > Bridged iptables (ebtables) is not enabled in the kernel and I cannot > > seem to find a variable "bridge-nf-call-iptables" to set with sysctl: > > > > wireless-r1 linux # sysctl -w bridge-nf-call-iptables=0 > > error: "bridge-nf-call-iptables" is an unknown key > > > > There is also no /proc/sys/net/*/bridge anything. I assume that means > > this is not something I need to worry about? > > Not sure yet, the problem would be created by CONFIG_BRIDGE_NETFILTER, > not ebtables itself. Check for > "/proc/sys/net/bridge/bridge-nf-call-iptables". > > I'm actually pretty sure that this is indeed what's causing the problem, > bridge netfilter defers calling the IP POST_ROUTING hook until the > packet was already transmitted over the device (and before it goes > out the underlying device), which means when it hits the CLASSIFY > target it already passed through the qdisc. Eh. What a pain. If I disable this, then ebtables will not call iptables after the ebtables are finished running. I figured out that I could use ebtables to match the destination MAC address like I needed for the other problem I posted (See "Bi-directional packet classification with ACK prioritization" thread for details). However, in order for that to work, I have to have bridge-nf-call-iptables enabled. Essentially, I can use the ebtables to flag the packets going to a destination MAC address and then inside the iptables POSTROUTING mangle chain, I can pick up that flag and reflag packets based on their Layer 3 and 4 information. But, then I run right back into the problem of this thread in that the packets are going through the TC qdiscs and classes before they hit the POSTROUTING mangle chain. Now, what confuses me is that I have this nice big printout of the order that the packets traverse ebtables, iptables, and tc which was made by Josh over at ImageStream (see http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the image) which clearly shows that it should go through ebtables POSTROUTING nat, then iptables POSTROUTING mangle, then iptables POSTROUTING nat, then TC qdisc classification, then TC qdisc deque. Also, after reading http://benix.tamu.edu/unix/linux-bridge-ebtables.htm, it seems pretty clear that the image depiction should be correct. But, since this is not happening, either the code has changed or both those sources are just wrong. Do you happen to have any idea how I can get this straightened out? Do we need to rewrite part of the code to make this work correctly? If that is what it takes, I would be more than happy to look into doing that. Maybe we can write a --destination-mac option for the iptables MAC matching module? Is that information available to iptables in the POSTROUTING mangle or nat chains? If not, would it be at all possible to make it available? That would solve this problem very nicely. Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. From simonl at parknet.dk Sun Jun 4 21:35:49 2006 From: simonl at parknet.dk (Simon Lodal) Date: Sun Jun 4 21:58:49 2006 Subject: [PATCH] Named realm - updated Message-ID: <200606042135.49361.simonl@parknet.dk> Make the realm match accept named realms, defined in /etc/iproute2/rt_realms. First sent 2006-05-21, improved since then: - Only load rt_realms once, keep in memory. - Output realm by name if it was originally specified that way, except if iptables -n. Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: realm_named_linux.diff Type: text/x-diff Size: 374 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060604/b3e70c90/realm_named_linux-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: realm_named_iptables.diff Type: text/x-diff Size: 5577 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060604/b3e70c90/realm_named_iptables-0001.bin From max at nucleus.it Mon Jun 5 00:29:08 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Mon Jun 5 00:52:15 2006 Subject: [PATCH] entry_data Message-ID: <200606050029.08602.max@nucleus.it> Hi, here is my proposed patch for an API change that supports entry specific data. As explained in my previous posts the purpose of this patch is to give matches the opportunity to store entry specific data. Several matches already achieve this reserving some space in the data fields, but these come from userspace and I don't think it is the Right Way(TM) to do it. How it works: - xt_entry_match.u.kernel now includes void *entry_data; - (*checkentry)() now receives void **entry_data that points to the above mentioned field and has the ability to write to it; - (*match)() and (*destroy)() are fed back the value set by (*checkentry)(). I did it just for matches. If anyone feels that it could be useful for targets, plese let me know. I split it into 2 patches. One lays the infrastructure (this is the real patch and is really short), while the other changes every match in the mainline kernel according to the new API. Feel free to criticize and suggest improvements. -- Bye, Massimiliano Hofer -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.6.17-rc5-entry_data_core.patch Type: text/x-diff Size: 4843 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060605/94b0d808/2.6.17-rc5-entry_data_core-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.6.17-rc5-entry_data_matches.patch Type: text/x-diff Size: 36294 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060605/94b0d808/2.6.17-rc5-entry_data_matches-0001.bin From eric at inl.fr Mon Jun 5 15:01:47 2006 From: eric at inl.fr (Eric Leblond) Date: Mon Jun 5 15:30:12 2006 Subject: [PATCH] fix conntrack compilation Message-ID: <1149512507.20946.5.camel@localhost.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : /pipermail/netfilter-devel/attachments/20060605/b0aaff7f/attachment.pgp From support8 at greatlakes.net Mon Jun 5 16:21:47 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Mon Jun 5 16:41:30 2006 Subject: POSTROUTING hooks Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB25544B@xavier.staff.greatlakes.net> Where in the kernel's packet delivery process does the POSTROUTING chain hook in? I'm trying to figure out how to write a module to allow matching on the destination MAC address. From what I have been able to figure out so far, it looks like the destination MAC is not actually set until right before the packet goes out of the interface. Now, I have not been able to find the code that would confirm this, so if anyone can point me to the exact position where the destination MAC address is set, that would be helpful. However, from what I have been able to observe with logging and some quick and dirty modifications to a couple of modules to print out some extra debugging info, this appears to be the case. What would it take to modify the Netfilter code to make the POSTROUTING chain hook in AFTER the destination MAC is set, but BEFORE it gets sent out the interface? If this change is made, what types of things might it break? Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. From bof at bof.de Mon Jun 5 18:01:05 2006 From: bof at bof.de (Patrick Schaaf) Date: Mon Jun 5 18:24:14 2006 Subject: POSTROUTING hooks In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB25544B@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB25544B@xavier.staff.greatlakes.net> Message-ID: <20060605160105.GE8333@oknodo.bof.de> > Where in the kernel's packet delivery process does the POSTROUTING chain > hook in? You can get a pretty accurate answer, for any kernel version, by doing grep NF_HOOK /usr/src/linux-whatever/net/ipv?/*.c For the 2.4.18 kernel I'm looking at, there are three calls to NF_IP_POST_ROUTING in net/ipv4/ip_output.c. Two of them are obviously concerned with multicast, leaving one call in ip_finish_output. So, POST_ROUTING is called when the packet leaves the IP stack. As you can see there, only after POST_ROUTING is the packet queued to some network device. And only after that is ARP done, and only then is a destination MAC known (temporarily, until ARP changes something under your feet). > I'm trying to figure out how to write a module to allow matching on the > destination MAC address. Impossible with the current setup, it seems. Which is probably the reason why none of the 50 people who wanted to do that before, succeeded. > What would it take to modify the Netfilter code to make the POSTROUTING > chain hook in AFTER the destination MAC is set, but BEFORE it gets sent > out the interface? It would take a very brave person, with a masochistic streak, and a burning desire to maintain his own Linux networking stack, device drivers, and iptables derivate. best regards Patrick From support8 at greatlakes.net Mon Jun 5 18:46:52 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Mon Jun 5 19:06:23 2006 Subject: POSTROUTING hooks Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB255453@xavier.staff.greatlakes.net> > -----Original Message----- > From: Patrick Schaaf [mailto:bof@bof.de] > Sent: Monday, June 05, 2006 12:01 PM > To: Eliot, Wireless and Server Administrator, Great Lakes Internet > Cc: Netfilter Development Mailinglist > Subject: Re: POSTROUTING hooks > > > Where in the kernel's packet delivery process does the POSTROUTING chain > > hook in? > > You can get a pretty accurate answer, for any kernel version, by doing > grep NF_HOOK /usr/src/linux-whatever/net/ipv?/*.c > > For the 2.4.18 kernel I'm looking at, there are three calls to > NF_IP_POST_ROUTING in net/ipv4/ip_output.c. Two of them are > obviously concerned with multicast, leaving one call in > ip_finish_output. > > So, POST_ROUTING is called when the packet leaves the IP stack. > > As you can see there, only after POST_ROUTING is the packet queued > to some network device. And only after that is ARP done, and only > then is a destination MAC known (temporarily, until ARP changes > something under your feet). > Well, then how about we use a different approach. In my case, I don't need to be guaranteed that the MAC address returned is the correct one at all times. All I need to know is that it is very likely to be the correct one. So, given that the kernel keeps a mapping of the IP->MAC and the packet contains the destination IP, why can't we just look up the destination MAC for that IP in the kernel table, if it exists. Once the connection is established this type of matching would work because ARP has already happened for some packets on the network to this destination. Therefore, there should be an entry in the table (assuming it has not already timed out). Obviously, this only works when the router is on the destination network that the destination IP is on. Also, this will obviously not match the first packet sent to the destination IP (since ARP has not occurred). But, if the router is on the same network the destination IP is on, and if ARP has already occurred, then this will give as good of an estimation of what the destination MAC address is as is possible given the circumstances. If we cannot look up the MAC, the module will not return a match. If we cannot look up the MAC associated with the destination IP, we don't match. We also don't do any active stuff to try to figure it out. This would be a completely passive process. Only in certain circumstances would this yield a result, but in those circumstances, it would be extremely useful. In my case, it would give me what I needed. Is there anything flawed in this logic? Any other things about the Linux kernel IP stack that might throw a kink in my plans? Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. From bof at bof.de Mon Jun 5 19:25:17 2006 From: bof at bof.de (Patrick Schaaf) Date: Mon Jun 5 19:48:19 2006 Subject: POSTROUTING hooks In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255453@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255453@xavier.staff.greatlakes.net> Message-ID: <20060605172517.GF8333@oknodo.bof.de> > So, given that the kernel keeps a mapping of the IP->MAC and the packet > contains the destination IP, why can't we just look up the destination > MAC for that IP in the kernel table, if it exists. I think that's what destination MAC matching did, before it was removed. If I remember correctly, ARP stuff happens in a sufficiently different locking context from iptables processing, so nobody wanted to (could sanely) maintain an external access to the ARP structures just for the sake of a destination MAC iptables match. Maybe I misremember. Corrections welcome. best regards Patrick From support8 at greatlakes.net Mon Jun 5 19:32:51 2006 From: support8 at greatlakes.net (Eliot, Wireless and Server Administrator, Great Lakes Internet) Date: Mon Jun 5 19:52:17 2006 Subject: POSTROUTING hooks Message-ID: <0633E0EDB4F25F43A2D7179CA11FAFAB255456@xavier.staff.greatlakes.net> > -----Original Message----- > From: Patrick Schaaf [mailto:bof@bof.de] > Sent: Monday, June 05, 2006 1:25 PM > To: Eliot, Wireless and Server Administrator, Great Lakes Internet > Cc: Patrick Schaaf; Netfilter Development Mailinglist > Subject: Re: POSTROUTING hooks > > > So, given that the kernel keeps a mapping of the IP->MAC and the packet > > contains the destination IP, why can't we just look up the destination > > MAC for that IP in the kernel table, if it exists. > > I think that's what destination MAC matching did, before it was removed. > > If I remember correctly, ARP stuff happens in a sufficiently different > locking context from iptables processing, so nobody wanted to (could > sanely) > maintain an external access to the ARP structures just for the sake of a > destination MAC iptables match. > > Maybe I misremember. Corrections welcome. > I don't ever recall seeing destination MAC matching support. Do you know what version of the code this was in? Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and System Engineer Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, Worth Township, and Sandusky. Call for details. From anders at anduras.de Mon Jun 5 21:54:09 2006 From: anders at anduras.de (Sven Anders) Date: Mon Jun 5 22:16:15 2006 Subject: Negating limit Message-ID: <44848BE1.1070503@anduras.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Here is a patch to allow a negated "limit", so we can match above and below the limit. It adds a new "flags" variable after the burst. I'm not sure, if I can add it after the "*master" variable, so I added it here. Does this preserve compatibility, because anything after is only used by the kernel? struct xt_rateinfo { u_int32_t avg; /* Average secs between packets * scale */ u_int32_t burst; /* Period multiplier for upper limit. */ u_int8_t flags; /* Match if, below or above limit? */ /* Used internally by the kernel */ unsigned long prev; u_int32_t credit; u_int32_t credit_cap, cost; /* Ugly, ugly fucker. */ struct xt_rateinfo *master; }; The patch is against 2.6.16.19. Any comments? (I will post the patch for the iptables program, if I'm sure about the position of the 'flags' variable...). Regards Sven Anders - -- Sven Anders () Ascii Ribbon Campaign /\ Support plain text e-mail ANDURAS service solutions AG Innstra?e 71 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhIvg5lKZ7Feg4EcRAvC9AJ4oZbEYNYPzvwO49W6q/Zsuc8kuXQCfYVLH npQt1K4pX0O6LAG786GZixE= =sehO -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: limit.patch Type: text/x-diff Size: 3016 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060605/c7b2547d/limit.bin From breathair at gmail.com Tue Jun 6 05:39:37 2006 From: breathair at gmail.com (=?EUC-KR?B?waS9wsH4?=) Date: Tue Jun 6 06:02:46 2006 Subject: help me please ! I can't patch patch-o-matic-ng Message-ID: <9790665b0606052039m4e18530ft20a5da2fc7300230@mail.gmail.com> My kernel is /usr/src/kernels/2.6.16-1.2111_FC4-i686. I have been downloaded kernels2.6 on /usr/src/linux. I create folder /usr/src/iptables.and extract iptables 1.3.4 source. and download p-o-m-ng file. then extract it on /usr/src/iptables folder. go on /usr/src/iptables/patch...ng folder #./runme Hey! KERNEL_DIR is not set. Where is your kernel? [/usr/src/linux] Where is your iptables source code? [/usr/src/iptables] Loading patchlet definitions... done Welcome to Patch-o-matic (1.14)! Kernel: /usr/src/linux Iptables: /usr/src/iptables Each patch is a new feature: many have minimal impact, some do not. Almost every one has bugs, so don't apply what you don't need! ------------------------------ ------------------------- Already applied: Testing expect-optimize... not applied The expect-optimize patch: Author: Pablo Neira Status: Pending for kernel inclusion ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] t cannot apply (7 missing files) ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y cannot apply (7 missing files) ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y cannot apply (7 missing files) ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] q Excellent! Source trees are ready for compilation. here it is my process. hm.. I have a lot of tried it solve problem. but I couldn't. do you know solve this problem? please reply my mail. thanks! From bof at bof.de Tue Jun 6 08:37:23 2006 From: bof at bof.de (Patrick Schaaf) Date: Tue Jun 6 09:00:28 2006 Subject: POSTROUTING hooks In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255456@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255456@xavier.staff.greatlakes.net> Message-ID: <20060606063723.GH8333@oknodo.bof.de> > I don't ever recall seeing destination MAC matching support. Do you know > what version of the code this was in? Hmm. Google fails me. Maybe my memory completely failed me... Help, anybody? :) best regards Patrick From philipc at snapgear.com Tue Jun 6 09:21:37 2006 From: philipc at snapgear.com (Philip Craig) Date: Tue Jun 6 09:44:49 2006 Subject: POSTROUTING hooks In-Reply-To: <20060606063723.GH8333@oknodo.bof.de> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255456@xavier.staff.greatlakes.net> <20060606063723.GH8333@oknodo.bof.de> Message-ID: <44852D01.3010206@snapgear.com> On 06/06/2006 04:37 PM, Patrick Schaaf wrote: >> I don't ever recall seeing destination MAC matching support. Do you know >> what version of the code this was in? > > Hmm. Google fails me. Maybe my memory completely failed me... Help, anybody? :) I found lots of talk about iptables dst mac matches, but no code. ebtables can match on destination MAC. This means you have to create a dummy bridge though, which slows things down. Another option is to create static arp entries, and then just filter by IP address. From pablo at netfilter.org Tue Jun 6 13:35:17 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Jun 6 13:51:45 2006 Subject: [PATCH] Unconditionaly push mark to conntrack structure In-Reply-To: <447CEAF3.5030903@trash.net> References: <447CD8AA.2040502@trash.net> <447CDB83.1090606@trash.net> <447CE2B0.8000504@trash.net> <447CE4ED.9010706@netfilter.org> <447CEAF3.5030903@trash.net> Message-ID: <44856875.2020108@netfilter.org> Patrick McHardy wrote: > Pablo Neira Ayuso wrote: > >>Patrick McHardy wrote: >> >> >>>>Actually this isn't true, I just noticed we never send timeout update >>>>notifications except for the first packet (which means we have tons >>>>of unnecessary notifier chain calls). I think this isn't really >>>>intended and was done to work around the high timeout event generation >>>>rate. Pablo, do you more about this? >> >> >>Indeed, the timer refresh event through netlink just burden the system >>and overrun the socket queue, so netlink starts dropping messages. > > > This is easy to fix by only sending an timer update for each connection > once every n seconds. If done in ip_ct_refresh_acct it will also reduce > the notifier load. > > >>>More bad news .. the timeout is sent in HZ instead of USER_HZ. This >>>unfortunately seems to call for an ABI break, I'd really hate to add >>>a CTA_TIMEOUT2 attribute. I guess we can live with it since its >>>usually not even included in the messages. >> >> >>To be frank, I can't see how the timer can be useful from userspace. I >>think that we should remove it. > > > Don't you need it for synchronization? One example where it could be > useful is to implement different timeout strategies (for example > something like pf's adaptive timeouts) in userspace. But these adaptive timeouts could be implemented in kernelspace. Although I don't know too much about the in-deep details of adaptive timeouts. >>About Eric's patch, I think that he can keep a cache of conntracks in >>userspace, as conntrackd does, instead of increasing the message size >>for something that is not always required. > > > Well, I do agree that any serious use of ctnetlink needs to take > care of the unreliability of netlink and therefore maintain its > own database that is resynchronized after losses etc. (I hope > conntrackd does that :)) But I think at least the networking > netlink subsystems should behave similar (it is for example > a requirement for maintaining automatic libnl caches, should > it be possible to use it with nfnetlink's different byteorder), > and I don't think the few bytes saved are worth beeing incompatible > with assumptions that hold for every other networking netlink > protocol. Unfortunately, ctnetlink is not doing any sequence tracking of the events at the moment :( and we have to. Here my old PIII 866MHz with a 100Mbits network card starts dropping events when it reaches ~300 simultaneos short TCP connections (2 seconds) with netperf. I'm going to cook a patch for this. From pablo at netfilter.org Tue Jun 6 13:40:50 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Jun 6 13:57:13 2006 Subject: [RFC,ANNOUNCE] conntrack daemon (stateful replication) In-Reply-To: <55064.192.168.33.2.1148887569.squirrel@mail.inl.fr> References: <447A1FB7.5080709@netfilter.org> <55064.192.168.33.2.1148887569.squirrel@mail.inl.fr> Message-ID: <448569C2.1070900@netfilter.org> Eric Leblond wrote: >>The project is called `conntrackd' that is the conntrack userspace daemon. >>- Stateful replication: the daemon keeps a cache of internal events via >>libnetfilter_conntrack and a cache of external event received from the >>other node. > > > That sounds good ! > > >>- Support for classical Primary/Backup settings > > ... > >>- install libnfnetlink and libnetfilter_conntrack from SVN (and apply >>the patch available in doc/) > > > A quick look at the patch seems to show that API has changed again :-( > > Userspace handling of conntrack is a GREAT thing and conntrackd is one of > the elements that put it on the top of the great Netfilter things. But, it > definitively needs a fixed API because all related projects are at the > same point : "use svn and patch it!" I missed this email. Eric, this is still a work in progress, and I didn't ever apply that patch. The new patch included in conntrackd (yet unapplied) doesn't change the API. I understand your concerns about the API. From pablo at netfilter.org Tue Jun 6 19:02:36 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Jun 6 19:19:00 2006 Subject: [RFC,PATCH] sequence numbering for ctnetlink events Message-ID: <4485B52C.7020207@netfilter.org> Hi, This patch adds sequence numbering for event messages generated by ctnetlink, it is still imcomplete (nf_conntrack_netlink). I'm having tons of problems these days, and this makes everything really hard: my laptop died, so my home pc did, my mail at eurodev was down... so I'm reading netfilter mail from the archives and I have to spend some time to set up again a git tree to test my patches, and... recent debian kernels are broken with UML... :( BTW: people.netfilter.org seems to be down :( -------------- next part -------------- [RFC,PATCH] sequence numbering for ctnetlink events This patch adds sequence numbering to ctnetlink event messages send to userspace. Signed-off-by: Pablo Neira Ayuso Index: net-2.6.18.git/net/ipv4/netfilter/ip_conntrack_netlink.c =================================================================== --- net-2.6.18.git.orig/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-06-06 16:08:59.000000000 +0200 +++ net-2.6.18.git/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-06-06 16:55:44.000000000 +0200 @@ -304,6 +304,8 @@ } #ifdef CONFIG_IP_NF_CONNTRACK_EVENTS +static atomic_t ip_conntrack_seq = ATOMIC_INIT(0); + static int ctnetlink_conntrack_event(struct notifier_block *this, unsigned long events, void *ptr) { @@ -349,7 +351,8 @@ b = skb->tail; type |= NFNL_SUBSYS_CTNETLINK << 8; - nlh = NLMSG_PUT(skb, 0, 0, type, sizeof(struct nfgenmsg)); + nlh = NLMSG_PUT(skb, 0, atomic_add_return(1, &ip_conntrack_seq), + type, sizeof(struct nfgenmsg)); nfmsg = NLMSG_DATA(nlh); nlh->nlmsg_flags = flags; @@ -1239,6 +1242,8 @@ } #ifdef CONFIG_IP_NF_CONNTRACK_EVENTS +static atomic_t ip_conntrack_exp_seq = ATOMIC_INIT(0); + static int ctnetlink_expect_event(struct notifier_block *this, unsigned long events, void *ptr) { @@ -1263,7 +1268,8 @@ b = skb->tail; type |= NFNL_SUBSYS_CTNETLINK_EXP << 8; - nlh = NLMSG_PUT(skb, 0, 0, type, sizeof(struct nfgenmsg)); + nlh = NLMSG_PUT(skb, 0, atomic_add_return(1, &ip_conntrack_exp_seq), + type, sizeof(struct nfgenmsg)); nfmsg = NLMSG_DATA(nlh); nlh->nlmsg_flags = flags; From pablo at netfilter.org Tue Jun 6 19:27:36 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Jun 6 19:44:01 2006 Subject: [PATCH] Unconditionaly push mark to conntrack structure In-Reply-To: <447CEAF3.5030903@trash.net> References: <447CD8AA.2040502@trash.net> <447CDB83.1090606@trash.net> <447CE2B0.8000504@trash.net> <447CE4ED.9010706@netfilter.org> <447CEAF3.5030903@trash.net> Message-ID: <4485BB08.7060807@netfilter.org> Patrick McHardy wrote: > Pablo Neira Ayuso wrote: > >>Patrick McHardy wrote: >> >> >>>>Actually this isn't true, I just noticed we never send timeout update >>>>notifications except for the first packet (which means we have tons >>>>of unnecessary notifier chain calls). I think this isn't really >>>>intended and was done to work around the high timeout event generation >>>>rate. Pablo, do you more about this? >> >> >>Indeed, the timer refresh event through netlink just burden the system >>and overrun the socket queue, so netlink starts dropping messages. > > > This is easy to fix by only sending an timer update for each connection > once every n seconds. If done in ip_ct_refresh_acct it will also reduce > the notifier load. > > >>>More bad news .. the timeout is sent in HZ instead of USER_HZ. This >>>unfortunately seems to call for an ABI break, I'd really hate to add >>>a CTA_TIMEOUT2 attribute. I guess we can live with it since its >>>usually not even included in the messages. >> >> >>To be frank, I can't see how the timer can be useful from userspace. I >>think that we should remove it. > > Don't you need it for synchronization? One example where it could be > useful is to implement different timeout strategies (for example > something like pf's adaptive timeouts) in userspace. Thinking well, you are right, this feature could be easily added to conntrackd. From anders at anduras.de Wed Jun 7 11:28:06 2006 From: anders at anduras.de (Sven Anders) Date: Wed Jun 7 12:05:43 2006 Subject: Negating limit In-Reply-To: <44848BE1.1070503@anduras.de> References: <44848BE1.1070503@anduras.de> Message-ID: <44869C26.7070806@anduras.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! I found an old thread (Dec 2005) about the limit inversion problem. Is the only problem that hinders the inclusion into the kernel the iptables compatibility? If so, what possibilities do exist to solve this problem? (See my previous posting too please...) Regards Sven Anders - -- Sven Anders () Ascii Ribbon Campaign /\ Support plain text e-mail ANDURAS service solutions AG Innstra?e 71 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhpwm5lKZ7Feg4EcRAhc9AKCB5vB86BNc5NZWbHtQmXkEHWxEOgCeOJyH msyyo54VZwihURPEz78vdaE= =AtyV -----END PGP SIGNATURE----- From geli at enseirb.fr Wed Jun 7 18:05:31 2006 From: geli at enseirb.fr (Mathieu Geli) Date: Wed Jun 7 18:31:51 2006 Subject: [nfqueue] libnetfilter_queue python wrapper Message-ID: <20060607180531.09652ae1@ganymede> Hi, If anyone is interested I adapted Neale Pickett's ipqueue code for the libnfnetlink/libnetfilter_queue API. That's called nfqueue. I know the code is far from perfect and will be glad to receive comments. You can download it here [1]. I recommend using scapy [2] and uncommenting the specific lines in the test file. Cheers [1] http://mathieu.geli.free.fr/code/nfqueue.tar.gz [2] http://www.secdev.org/projects/scapy/ -- Mathieu GELI -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060607/9d0e347f/attachment.pgp From kaber at trash.net Thu Jun 8 09:12:01 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 09:35:23 2006 Subject: [NETFILTER 2.6.18 3/3]: hashlimit match: fix random initialization Message-ID: <4487CDC1.5060806@trash.net> [NETFILTER]: hashlimit match: fix random initialization hashlimit does: if (!ht->rnd) get_random_bytes(&ht->rnd, 4); ignoring that 0 is also a valid random number. Signed-off-by: Patrick McHardy --- commit f42a39846047e78d30c913270125bed2e0c5a0da tree a875d2fb478ecaa405810a020ee4af61fa5c42f1 parent b010cc3184ce7cb65a9865ae52ec2ce6f3fe4c9d author Patrick McHardy Thu, 01 Jun 2006 20:43:40 +0200 committer Patrick McHardy Thu, 01 Jun 2006 20:43:40 +0200 net/ipv4/netfilter/ipt_hashlimit.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/net/ipv4/netfilter/ipt_hashlimit.c b/net/ipv4/netfilter/ipt_hashlimit.c index 85edfb7..92980ab 100644 --- a/net/ipv4/netfilter/ipt_hashlimit.c +++ b/net/ipv4/netfilter/ipt_hashlimit.c @@ -80,6 +80,7 @@ struct ipt_hashlimit_htable { /* used internally */ spinlock_t lock; /* lock for list_head */ u_int32_t rnd; /* random seed for hash */ + int rnd_initialized; struct timer_list timer; /* timer for gc */ atomic_t count; /* number entries in table */ @@ -134,8 +135,10 @@ __dsthash_alloc_init(struct ipt_hashlimi /* initialize hash with random val at the time we allocate * the first hashtable entry */ - if (!ht->rnd) + if (!ht->rnd_initialized) { get_random_bytes(&ht->rnd, 4); + ht->rnd_initialized = 1; + } if (ht->cfg.max && atomic_read(&ht->count) >= ht->cfg.max) { @@ -214,7 +217,7 @@ static int htable_create(struct ipt_hash atomic_set(&hinfo->count, 0); atomic_set(&hinfo->use, 1); - hinfo->rnd = 0; + hinfo->rnd_initialized = 0; spin_lock_init(&hinfo->lock); hinfo->pde = create_proc_entry(minfo->name, 0, hashlimit_procdir); if (!hinfo->pde) { From kaber at trash.net Thu Jun 8 09:11:59 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 09:35:25 2006 Subject: [NETFILTER 2.6.18 2/3]: recent match: missing refcnt initialization Message-ID: <4487CDBF.6050101@trash.net> [NETFILTER]: recent match: missing refcnt initialization Signed-off-by: Patrick McHardy --- commit 10263005af5814396b8263c1c2a4367d49548e13 tree a73003fe82e7b4546359d86f684b90b78a6aa504 parent 6812aa38ac35d6e819058d2273a6a7de091a2604 author Patrick McHardy Thu, 01 Jun 2006 16:49:58 +0200 committer Patrick McHardy Thu, 01 Jun 2006 16:49:58 +0200 net/ipv4/netfilter/ipt_recent.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/ipv4/netfilter/ipt_recent.c b/net/ipv4/netfilter/ipt_recent.c index 9b09e48..61a2139 100644 --- a/net/ipv4/netfilter/ipt_recent.c +++ b/net/ipv4/netfilter/ipt_recent.c @@ -262,6 +262,7 @@ ipt_recent_checkentry(const char *tablen GFP_KERNEL); if (t == NULL) goto out; + t->refcnt = 1; strcpy(t->name, info->name); INIT_LIST_HEAD(&t->lru_list); for (i = 0; i < ip_list_hash_size; i++) From kaber at trash.net Thu Jun 8 09:11:57 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 09:35:25 2006 Subject: [NETFILTER 2.6.18 1/3]: recent match: fix "sleeping function called from invalid context" Message-ID: <4487CDBD.2070400@trash.net> These three patches against net-2.6.18 fix two bugs in my recent match rewrite and a minor thinko in the hashlimit match. Please apply. -------------- next part -------------- [NETFILTER]: recent match: fix "sleeping function called from invalid context" create_proc_entry must not be called with locks held. Use a mutex instead to protect data only changed in user context. Signed-off-by: Patrick McHardy --- commit 6812aa38ac35d6e819058d2273a6a7de091a2604 tree 140fea396f29415d7981fcfbc5980f5c0b2d91a7 parent a0447a3000b5d4e926928493def9d62aae3b87ed author Patrick McHardy Thu, 01 Jun 2006 16:40:39 +0200 committer Patrick McHardy Thu, 01 Jun 2006 16:40:39 +0200 net/ipv4/netfilter/ipt_recent.c | 15 ++++++++++----- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/net/ipv4/netfilter/ipt_recent.c b/net/ipv4/netfilter/ipt_recent.c index 9686c4d..9b09e48 100644 --- a/net/ipv4/netfilter/ipt_recent.c +++ b/net/ipv4/netfilter/ipt_recent.c @@ -69,6 +69,7 @@ #endif static LIST_HEAD(tables); static DEFINE_SPINLOCK(recent_lock); +static DEFINE_MUTEX(recent_mutex); #ifdef CONFIG_PROC_FS static struct proc_dir_entry *proc_dir; @@ -249,7 +250,7 @@ ipt_recent_checkentry(const char *tablen strnlen(info->name, IPT_RECENT_NAME_LEN) == IPT_RECENT_NAME_LEN) return 0; - spin_lock_bh(&recent_lock); + mutex_lock(&recent_mutex); t = recent_table_lookup(info->name); if (t != NULL) { t->refcnt++; @@ -258,7 +259,7 @@ ipt_recent_checkentry(const char *tablen } t = kzalloc(sizeof(*t) + sizeof(t->iphash[0]) * ip_list_hash_size, - GFP_ATOMIC); + GFP_KERNEL); if (t == NULL) goto out; strcpy(t->name, info->name); @@ -274,10 +275,12 @@ #ifdef CONFIG_PROC_FS t->proc->proc_fops = &recent_fops; t->proc->data = t; #endif + spin_lock_bh(&recent_lock); list_add_tail(&t->list, &tables); + spin_unlock_bh(&recent_lock); ret = 1; out: - spin_unlock_bh(&recent_lock); + mutex_unlock(&recent_mutex); return ret; } @@ -288,17 +291,19 @@ ipt_recent_destroy(const struct xt_match const struct ipt_recent_info *info = matchinfo; struct recent_table *t; - spin_lock_bh(&recent_lock); + mutex_lock(&recent_mutex); t = recent_table_lookup(info->name); if (--t->refcnt == 0) { + spin_lock_bh(&recent_lock); list_del(&t->list); + spin_unlock_bh(&recent_lock); recent_table_flush(t); #ifdef CONFIG_PROC_FS remove_proc_entry(t->name, proc_dir); #endif kfree(t); } - spin_unlock_bh(&recent_lock); + mutex_unlock(&recent_mutex); } #ifdef CONFIG_PROC_FS From kaber at trash.net Thu Jun 8 09:15:52 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 09:39:11 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <44809B1C.2010907@gmx.net> References: <448051F3.1070509@trash.net> <1149267610.3021.11.camel@localhost.localdomain> <448072FC.3060902@trash.net> <44809B1C.2010907@gmx.net> Message-ID: <4487CEA8.8060701@trash.net> Carl-Daniel Hailfinger wrote: > Patrick McHardy wrote: > >>Thats what I meant by "iptables+mark". You can combine iptables >>specific matches by marking matching packets, then match on the >>mark with ebtables (or the other way around for incoming packets). > > > IIRC the mark has only 32 bits. Not so long ago, I was using 30 bits > of that in my firewalling rules on a bridge-router. I might have > squeezed the physdev match in the remaining 2 bits, but I'm not > sure. I do admit the setup was fairly uncommon (bridging and > double nat with only one machine). Yes, its getting a bit tight in there, but so far in all setups I've seen it was possible to get along with the 32 bits using masks or reusing bits after they are no longer needed. I guess we'll have to wait and see .. From kaber at trash.net Thu Jun 8 09:17:57 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 09:41:15 2006 Subject: Bridge netfilter MTU discovery In-Reply-To: <20060602111511.7d08f33c@localhost.localdomain> References: <20060602111511.7d08f33c@localhost.localdomain> Message-ID: <4487CF25.5020407@trash.net> Stephen Hemminger wrote: > Is there an easy way to force bridge packets to cause an ICMP frag needed > if the MTU of the destination is too small. Normal bridging will just drop > the packet, but a rule to send ICMP would allow PMTU to work. Maybe even > having a module to fragment would be good. Conntrack breaks PMTU discovery by always defragmenting/refragmenting packets, regardless of IP_DF. But there is no way to generate ICMP frag required messages using iptables. From kaber at trash.net Thu Jun 8 09:25:22 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 09:48:40 2006 Subject: [PATCH] Unconditionaly push mark to conntrack structure In-Reply-To: <44856875.2020108@netfilter.org> References: <447CD8AA.2040502@trash.net> <447CDB83.1090606@trash.net> <447CE2B0.8000504@trash.net> <447CE4ED.9010706@netfilter.org> <447CEAF3.5030903@trash.net> <44856875.2020108@netfilter.org> Message-ID: <4487D0E2.4030705@trash.net> Pablo Neira Ayuso wrote: > Patrick McHardy wrote: > >> Pablo Neira Ayuso wrote: >> >>> To be frank, I can't see how the timer can be useful from userspace. I >>> think that we should remove it. >> >> >> >> Don't you need it for synchronization? One example where it could be >> useful is to implement different timeout strategies (for example >> something like pf's adaptive timeouts) in userspace. > > > But these adaptive timeouts could be implemented in kernelspace. Thats not a good argument .. by that logic we wouldn't need ctnetlink at all :) > Unfortunately, ctnetlink is not doing any sequence tracking of the > events at the moment :( and we have to. Here my old PIII 866MHz with a > 100Mbits network card starts dropping events when it reaches ~300 > simultaneos short TCP connections (2 seconds) with netperf. I'm going to > cook a patch for this. That seems to be pretty poor performance - by sequence tracking you mean TCP state updates? Is that poor performance with or without them? From kaber at trash.net Thu Jun 8 09:36:12 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 09:59:36 2006 Subject: Negating limit In-Reply-To: <44848BE1.1070503@anduras.de> References: <44848BE1.1070503@anduras.de> Message-ID: <4487D36C.5060708@trash.net> Sven Anders wrote: > Here is a patch to allow a negated "limit", so we can match above and below the > limit. > > It adds a new "flags" variable after the burst. I'm not sure, if I can add it > after the "*master" variable, so I added it here. > Does this preserve compatibility, because anything after is only used by the kernel? No, unfortunately there is no way to add a new variable to that struct without breaking compatibility. You could add a new revision, but I would like to think about Massimiliano Hofer's patch before that, if we do something like that we can get rid of the "master" pointer with the new revision. From kaber at trash.net Thu Jun 8 09:38:08 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 10:01:27 2006 Subject: help me please ! I can't patch patch-o-matic-ng In-Reply-To: <9790665b0606052039m4e18530ft20a5da2fc7300230@mail.gmail.com> References: <9790665b0606052039m4e18530ft20a5da2fc7300230@mail.gmail.com> Message-ID: <4487D3E0.9060600@trash.net> ?????? wrote: > Testing expect-optimize... not applied > The expect-optimize patch: > Author: Pablo Neira > Status: Pending for kernel inclusion > > ----------------------------------------------------------------- > Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] t > cannot apply (7 missing files) Not sure what its trying to say, but that patch is in the kernel for ages, so you don't need to apply it yourself. From kaber at trash.net Thu Jun 8 09:41:59 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 10:05:18 2006 Subject: [LARTC] iptables CLASSIFY and MARK not working? In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB255436@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB255436@xavier.staff.greatlakes.net> Message-ID: <4487D4C7.9060604@trash.net> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > Eh. What a pain. If I disable this, then ebtables will not call iptables > after the ebtables are finished running. I figured out that I could use > ebtables to match the destination MAC address like I needed for the > other problem I posted (See "Bi-directional packet classification with > ACK prioritization" thread for details). However, in order for that to > work, I have to have bridge-nf-call-iptables enabled. Essentially, I can > use the ebtables to flag the packets going to a destination MAC address > and then inside the iptables POSTROUTING mangle chain, I can pick up > that flag and reflag packets based on their Layer 3 and 4 information. > But, then I run right back into the problem of this thread in that the > packets are going through the TC qdiscs and classes before they hit the > POSTROUTING mangle chain. > > Now, what confuses me is that I have this nice big printout of the order > that the packets traverse ebtables, iptables, and tc which was made by > Josh over at ImageStream (see > http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the image) > which clearly shows that it should go through ebtables POSTROUTING nat, > then iptables POSTROUTING mangle, then iptables POSTROUTING nat, then TC > qdisc classification, then TC qdisc deque. Also, after reading > http://benix.tamu.edu/unix/linux-bridge-ebtables.htm, it seems pretty > clear that the image depiction should be correct. But, since this is not > happening, either the code has changed or both those sources are just > wrong. I guess both are wrong. > Do you happen to have any idea how I can get this straightened out? Do > we need to rewrite part of the code to make this work correctly? If that > is what it takes, I would be more than happy to look into doing that. Fixing this is one of my short-term TODO items, most likely before 2.6.18. > Maybe we can write a --destination-mac option for the iptables MAC > matching module? Is that information available to iptables in the > POSTROUTING mangle or nat chains? If not, would it be at all possible to > make it available? That would solve this problem very nicely. No, iptables can't reliably get at this information (it might need to be resolved first). From kaber at trash.net Thu Jun 8 09:43:50 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 8 10:07:08 2006 Subject: POSTROUTING hooks In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB25544B@xavier.staff.greatlakes.net> References: <0633E0EDB4F25F43A2D7179CA11FAFAB25544B@xavier.staff.greatlakes.net> Message-ID: <4487D536.1050702@trash.net> Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: > Where in the kernel's packet delivery process does the POSTROUTING chain > hook in? > > I'm trying to figure out how to write a module to allow matching on the > destination MAC address. From what I have been able to figure out so > far, it looks like the destination MAC is not actually set until right > before the packet goes out of the interface. Now, I have not been able > to find the code that would confirm this, so if anyone can point me to > the exact position where the destination MAC address is set, that would > be helpful. However, from what I have been able to observe with logging > and some quick and dirty modifications to a couple of modules to print > out some extra debugging info, this appears to be the case. > > What would it take to modify the Netfilter code to make the POSTROUTING > chain hook in AFTER the destination MAC is set, but BEFORE it gets sent > out the interface? Still doesn't help, ARP resolution happens after that. From anders at anduras.de Thu Jun 8 11:12:50 2006 From: anders at anduras.de (Sven Anders) Date: Thu Jun 8 11:34:37 2006 Subject: Negating limit In-Reply-To: <4487D36C.5060708@trash.net> References: <44848BE1.1070503@anduras.de> <4487D36C.5060708@trash.net> Message-ID: <4487EA12.6020609@anduras.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick wrote: >> Here is a patch to allow a negated "limit", so we can match above and below the >> limit. >> >> It adds a new "flags" variable after the burst. I'm not sure, if I can add it >> after the "*master" variable, so I added it here. >> Does this preserve compatibility, because anything after is only used by the kernel? > > No, unfortunately there is no way to add a new variable to that struct > without breaking compatibility. You could add a new revision, but I > would like to think about Massimiliano Hofer's patch before that, > if we do something like that we can get rid of the "master" pointer > with the new revision. What do you mean with "new revision"? A new match named "limit2"? Which of Massimiliano's patches do you mean? The "support for entry data" patch? To understand correctly: Is it not possible under any circumstances to add new variables to a match info struct or is the problem the "master" variable? If so what is the "master" variable for? As far as I understand the size of the "match info struct" passed from the userspace must exactly match the size of the kernels "match info struct". Right? Regards Sven Anders - -- Sven Anders () Ascii Ribbon Campaign /\ Support plain text e-mail ANDURAS service solutions AG Innstra?e 71 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEh+oQ5lKZ7Feg4EcRAvHeAJ9JD1tBGvLhZwETVaEpgj/KPZe3KACfcUhG 2/TN39WZ3JjJjwye4xW84i8= =GIIo -----END PGP SIGNATURE----- From vasanthakumar at iitb.ac.in Thu Jun 8 19:37:01 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Thu Jun 8 20:00:45 2006 Subject: Packet Lost Message-ID: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> Hi, I am working on a small application using iptables/libipq. In this, the application would capture a specific packets based on the destination IP address. Then I encapsulate this IP packet inside another new IP packet. My problem is that the encapsulation part works fine in kernel-2.6.11-6(mandriva 2005) and IPtables V 1.2.9. (I can capture encapsulated packets using tcpdump at the sender side i.e, packets are being put on to the network) But this doesn't work in kernel-2.6.12-12 and IPtables-1.3.5 (even though there are no erros after callig ipq_set_verdict, the packets are not being put on to the channel. The packets are getting lost after the call to ipq_set_verdict) please let me know if you need more information Please help me out here Thanx From m at rtij.nl Thu Jun 8 22:47:19 2006 From: m at rtij.nl (Martijn Lievaart) Date: Thu Jun 8 23:10:42 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <4487CEA8.8060701@trash.net> References: <448051F3.1070509@trash.net> <1149267610.3021.11.camel@localhost.localdomain> <448072FC.3060902@trash.net> <44809B1C.2010907@gmx.net> <4487CEA8.8060701@trash.net> Message-ID: <44888CD7.8090601@rtij.nl> Patrick McHardy wrote: >Carl-Daniel Hailfinger wrote: > > >>IIRC the mark has only 32 bits. Not so long ago, I was using 30 bits >>of that in my firewalling rules on a bridge-router. I might have >>squeezed the physdev match in the remaining 2 bits, but I'm not >>sure. I do admit the setup was fairly uncommon (bridging and >>double nat with only one machine). >> >> > >Yes, its getting a bit tight in there, but so far in all setups I've >seen it was possible to get along with the 32 bits using masks or >reusing bits after they are no longer needed. I guess we'll have to >wait and see .. > > Something I've been thinking about. Currently it is impossible to write any kind of generic tool that uses the mark and plays nice with other generic tools. Maybe we need some kind of API that allocates bits in the mark. Something like "give me two bits", that returns some handle to the bits. That handle could then be used for identifying the bits in the mark. As an added benefit, this encapsulates the operations on the mark, making it trivial to switch to say 64 bits for the mark. What do others think? M4 From simonl at parknet.dk Thu Jun 8 23:40:41 2006 From: simonl at parknet.dk (Simon Lodal) Date: Fri Jun 9 00:04:08 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <44888CD7.8090601@rtij.nl> References: <448051F3.1070509@trash.net> <4487CEA8.8060701@trash.net> <44888CD7.8090601@rtij.nl> Message-ID: <200606082340.41755.simonl@parknet.dk> On Thursday 08 June 2006 22:47, Martijn Lievaart wrote: > Patrick McHardy wrote: > >Carl-Daniel Hailfinger wrote: > >>IIRC the mark has only 32 bits. Not so long ago, I was using 30 bits > >>of that in my firewalling rules on a bridge-router. I might have > >>squeezed the physdev match in the remaining 2 bits, but I'm not > >>sure. I do admit the setup was fairly uncommon (bridging and > >>double nat with only one machine). > > > >Yes, its getting a bit tight in there, but so far in all setups I've > >seen it was possible to get along with the 32 bits using masks or > >reusing bits after they are no longer needed. I guess we'll have to > >wait and see .. > > Something I've been thinking about. Currently it is impossible to write > any kind of generic tool that uses the mark and plays nice with other > generic tools. Maybe we need some kind of API that allocates bits in the > mark. Something like "give me two bits", that returns some handle to the > bits. That handle could then be used for identifying the bits in the mark. > > As an added benefit, this encapsulates the operations on the mark, > making it trivial to switch to say 64 bits for the mark. > > What do others think? > > M4 Sounds nice. If the handles are names it becomes a sort of runtime-defined bit struct. Would be nice to have across the tools, instead of doing the black bit magic directly (and in parallel) in each place. Why not define the mark size at compile time, in case you need more bits? Greetings Simon From m at rtij.nl Fri Jun 9 00:17:57 2006 From: m at rtij.nl (Martijn Lievaart) Date: Fri Jun 9 00:41:21 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <200606082340.41755.simonl@parknet.dk> References: <448051F3.1070509@trash.net> <4487CEA8.8060701@trash.net> <44888CD7.8090601@rtij.nl> <200606082340.41755.simonl@parknet.dk> Message-ID: <4488A215.5030305@rtij.nl> Simon Lodal wrote: >Why not define the mark size at compile time, in case you need more bits? > > Because that probably would cause the skb to grow beyond a cache line, though I'm nowhere an expert on these things. Opinions? M4 From philipc at snapgear.com Fri Jun 9 01:43:37 2006 From: philipc at snapgear.com (Philip Craig) Date: Fri Jun 9 02:07:08 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <4488A215.5030305@rtij.nl> References: <448051F3.1070509@trash.net> <4487CEA8.8060701@trash.net> <44888CD7.8090601@rtij.nl> <200606082340.41755.simonl@parknet.dk> <4488A215.5030305@rtij.nl> Message-ID: <4488B629.1070608@snapgear.com> On 06/09/2006 08:17 AM, Martijn Lievaart wrote: > Simon Lodal wrote: > >> Why not define the mark size at compile time, in case you need more bits? >> >> > > Because that probably would cause the skb to grow beyond a cache line, > though I'm nowhere an expert on these things. Opinions? It may be enough to extend the conntrack mark, but not the packet mark, so that we aren't growing the skb. Would need fancier operations for transferring only parts of the conntrack mark to the packet mark. From zhaojingmin at hotmail.com Fri Jun 9 06:14:02 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 06:37:38 2006 Subject: [H.323 Helper 1/5]: Check sequence range first Message-ID: I'm sorry for sending patches as attachments again, but my SMTP account on imap.netfilter.org doesn't work. Check sequence range first, no need to check it again later. So we saved a few instructions and nanoseconds :) Signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch1-check-range Type: application/octet-stream Size: 1181 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060609/82f56866/patch1-check-range.obj From zhaojingmin at hotmail.com Fri Jun 9 06:17:48 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 06:41:20 2006 Subject: [H.323 Helper 1/5]: Change helper definitions Message-ID: Change helpers' structure definitions to meet some old compilers. Signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch2-helper-definition Type: application/octet-stream Size: 1596 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060609/9d99d275/patch2-helper-definition.obj From zhaojingmin at hotmail.com Fri Jun 9 06:19:55 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 06:43:26 2006 Subject: [H.323 Helper 2/5]: Change helper definitions Message-ID: Change helpers' structure definitions to meet some old compilers. Signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch2-helper-definition Type: application/octet-stream Size: 1596 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060609/118b7d40/patch2-helper-definition.obj From zhaojingmin at hotmail.com Fri Jun 9 06:22:11 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 06:45:40 2006 Subject: [H.323 Helper 3/5]:Add missing T.120 support in OLCA Message-ID: Added missing T.120 support in OLCA. signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch3-olca-t120 Type: application/octet-stream Size: 2877 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060609/d0aad905/patch3-olca-t120-0001.obj From zhaojingmin at hotmail.com Fri Jun 9 06:24:12 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 06:47:42 2006 Subject: [H.323 Helper 4/5]: Put expect after use Message-ID: Bugfix: Put expect after use. Signed-off-by: Jing Min Zhao From zhaojingmin at hotmail.com Fri Jun 9 06:26:49 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 06:50:21 2006 Subject: [H.323 Helper 4/5]: Put expect after use Message-ID: Bugfix: Put expect after use. Signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch4-put-expect Type: application/octet-stream Size: 983 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060609/2df1a2af/patch4-put-expect.obj From zhaojingmin at hotmail.com Fri Jun 9 06:28:14 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 06:51:46 2006 Subject: [H.323 Helper 5/5]: Add support for Call Forwarding Message-ID: Add support for Call Forwarding. Signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch5-call-forwarding Type: application/octet-stream Size: 16427 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060609/38e8823f/patch5-call-forwarding.obj From hawk at comx.dk Thu Jun 8 14:52:23 2006 From: hawk at comx.dk (Jesper Dangaard Brouer) Date: Fri Jun 9 14:09:53 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes In-Reply-To: <447F5204.4080505@trash.net> References: <1149153349.28481.15.camel@localhost.localdomain> <447F1227.7050900@trash.net> <447F5204.4080505@trash.net> Message-ID: <1149771143.28481.87.camel@localhost.localdomain> On Thu, 2006-06-01 at 22:45 +0200, Patrick McHardy wrote: > Jesper Dangaard Brouer wrote: > > > > On Thu, 1 Jun 2006, Patrick McHardy wrote: > > > >> Wouldn't it make more sense to just make sure you don't have iptables > >> commands running concurrently? > > > > > > I already have implemented (f)locks in my code around the iptables > > invocations. But the problem can still arise when root executes the > > iptables command from the shell. Thus, I still need to handle the > > situation in my code, and a proper exitcode would be nice. > > > > In iptables-standalone.c it would be very easy to simply return the > > errno instead of !res (which always will return 0 or 1). Would that be > > a feasable solution? > > It would probably break other scripts that check for the current > (documented) exit codes. I guess adding a new one for this case > is fine, other code can't really expect that no new values are > ever added. That would be fine. For example something like the following patch? I have tracked down where the "Resource temporarily unavailable" occurs in libiptc.c, and marked it with a comment... if you can use it for any thing. -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk diff --exclude '*.d' --exclude-from /var/kernel/exclude_these -urpN iptables-1.3.4-pom-l7/include/iptables_common.h iptables-1.3.4-pom-l7-blocking/include/iptables_common.h --- iptables-1.3.4-pom-l7/include/iptables_common.h 2005-10-31 20:03:49.000000000 +0100 +++ iptables-1.3.4-pom-l7-blocking/include/iptables_common.h 2006-06-08 14:19:53.000000000 +0200 @@ -5,7 +5,8 @@ enum exittype { OTHER_PROBLEM = 1, PARAMETER_PROBLEM, - VERSION_PROBLEM + VERSION_PROBLEM, + RESOURCE_PROBLEM }; /* this is a special 64bit data type that is 8-byte aligned */ diff --exclude '*.d' --exclude-from /var/kernel/exclude_these -urpN iptables-1.3.4-pom-l7/iptables-standalone.c iptables-1.3.4-pom-l7-blocking/iptables-standalone.c --- iptables-1.3.4-pom-l7/iptables-standalone.c 2005-01-04 11:38:39.000000000 +0100 +++ iptables-1.3.4-pom-l7-blocking/iptables-standalone.c 2006-06-08 14:23:48.000000000 +0200 @@ -64,9 +64,13 @@ main(int argc, char *argv[]) if (ret) ret = iptc_commit(&handle); - if (!ret) + if (!ret) { fprintf(stderr, "iptables: %s\n", iptc_strerror(errno)); + if (errno == EAGAIN) { + exit(RESOURCE_PROBLEM); + } + } exit(!ret); } diff --exclude '*.d' --exclude-from /var/kernel/exclude_these -urpN iptables-1.3.4-pom-l7/libiptc/libiptc.c iptables-1.3.4-pom-l7-blocking/libiptc/libiptc.c --- iptables-1.3.4-pom-l7/libiptc/libiptc.c 2005-10-31 20:03:49.000000000 +0100 +++ iptables-1.3.4-pom-l7-blocking/libiptc/libiptc.c 2006-06-07 10:25:02.000000000 +0200 @@ -2104,6 +2104,7 @@ TC_COMMIT(TC_HANDLE_T *handle) free(repl->counters); free(repl); free(newcounters); + // The "EAGAIN: Resource temporarily unavailable" occurs here. return 0; } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060608/23d23baa/attachment-0001.pgp From jorge.matias at motorola.com Thu Jun 8 17:54:08 2006 From: jorge.matias at motorola.com (Jorge Matias Martin) Date: Fri Jun 9 14:09:56 2006 Subject: [PATCH] xt_sctp - add SCTP header size to IP header offset Message-ID: <200606081754.09073.jorge.matias@motorola.com> Hi, all. xt_sctp module is not working on 2.6.16 when --chunk-types option is used. I have test this running sctp_darn and the following iptables options: -A INPUT -p sctp --chunk-types any INIT -j DROP And this is the kernel log output: spt: 32822 dpt: 10105 Chunk num: 1 offset: 20 type: 128 length: 10105 flags: 36 skb->len: 92 offset: 10128 spt: 10105 dpt: 32822 Chunk num: 1 offset: 20 type: 39 length: 32822 flags: 79 skb->len: 284 offset: 32844 spt: 32822 dpt: 10105 Chunk num: 1 offset: 20 type: 128 length: 10105 flags: 36 ... Note that length is actually the local port, and offset must be 32 (20 IPv4 header + 12 SCTP header). FYI, it works properly when --chunk-types is not used. Regards. Jorge. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-diff Size: 580 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060608/c51b61b8/patch.bin From varun at rocsys.com Fri Jun 9 14:35:05 2006 From: varun at rocsys.com (varun) Date: Fri Jun 9 14:50:09 2006 Subject: Netfilter reg problem Message-ID: <44896AF9.1020606@rocsys.com> Hi all, I have a module which basically registers to the netfilter like shown below. static struct nf_hook_ops my_preroute_ops = { { NULL, NULL }, my_Input, PF_INET, NF_IP_PRE_ROUTING, NF_IP_PRI_NAT_DST-1 }; Now in this when i get a packet based on certain condition i use NF_STOLEN. Now the scenario is that i want to register iptables with REDIRECT facility also. The reason is that if i get a packet which has destination port 80 i will redirect to 5555 where i run squid proxy. so i use a policy like iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 5555 So for this to happen iptables should get the packet first before my module otherwise i will steal the packet and iptables will not get the packet. So i registered my module first and then try to insmod iptables modules. ip_conntrack.o refuses to insmod saying that resource busy. so without conntrck i cannot use REDIRECT. Why is this happening? Next if first register iptables and then my module then every thing works fine. But packets are not coming to iptables . Only my modules get it. So how can i overcome this situation? How to change my module reg functionality to suit the scenario? The important thing is that once iptables hits on the above policy then my module should get the packet after iptables. Please help me. Iam working on 2.4 kernel Varun From zhaojingmin at hotmail.com Fri Jun 9 15:22:11 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Fri Jun 9 15:46:13 2006 Subject: [H.323 Helper 5/5]: Add support for Call Forwarding References: Message-ID: The new function "have_direct_route" is based on Patrick's patch, but there are some changes. This function is used to guess whether two endpoints have direct route between them, if they do, firewall won't track future connection between them. But when a system is using Policy Routing and/or Multipath Routing, this function may guess wrong. This is why we still need the parameter "internal_net". In case we guess wrong but user still need a correct result, this is the last resort, although its limitation is supporting only one internal subnet. The reason there is no parameter to turn on/off the guessing is it make things worse. When we don't guess, this module doesn't work at all in some scenarios. So we always guess unless user specify "internal_net". Thanks, Jing Min Zhao ----- Original Message ----- From: "Jing Min Zhao" To: "Netfilter Development Mailinglist" Cc: "Patrick McHardy" Sent: Friday, June 09, 2006 12:28 AM Subject: [H.323 Helper 5/5]: Add support for Call Forwarding > Add support for Call Forwarding. > > Signed-off-by: Jing Min Zhao > From gregor at net.in.tum.de Fri Jun 9 18:01:08 2006 From: gregor at net.in.tum.de (Gregor Maier) Date: Fri Jun 9 18:24:36 2006 Subject: [RFC] libnfnetlink, libnetfilter_log, libnetfilter_queue error handling Message-ID: <44899B44.2030605@net.in.tum.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I noticed that libnfnetlink, libnetfilter_* are currently missing decent error handling and reporting mechanisms. libnetfilter_log and libnetfilter_queue define a nflog_errno resp. nfq_errno but those aren't really used. libnfnetlink uses fprintf for error handling/reporting. What do you think about the following suggestions: * add a nfnl_errno variable * add #defines for nfnl_errno values also add a nfnl_strerror and a nfnl_perror function * add #defines for nflog_errno and nfq_errno and nf{log|q}_strerror and nf{log|q}_perror functions. * make nflog_errno and nfq_errno a superset of the nfnl_errnos. E.g. by defining that error values from 1...N are for nfnl and values above N are for nfq_errno and nflog_errno. * nflog_strerror (and nfq_strerror) check if nflog_errno (resp. nfq_errno) is <= N. If so, they call nfnl_strerror otherwise they handle the error themselves. A user of the libnetfilter_{queue|log} only has to use the nfq_strerror or nflog_strerror (resp. perror) functions without getting in touch with the libnfnetlink errors. And by making nf{q|log}_errnos a superset of nfnl_errnos, reporting netlink errors is straightforward. How this could look like in code: /**** libnfnetlink ****/ #define ENFNL_NOERR 0 #define ENFNL_FOO 1 #define ENFNL_FOOBAR 2 .... #define ENFNL_MAXERR 1024 static const char *const nfnl_errlist[] = { "No error", /* 0 */ "Error foo occured", /* 1 = ENFNL_FOO */ ..... }; const char *nfnl_strerror(int errnum) { static char buf[1024]; if (errnum >= nfnl_nerr) { snprintf(buf, sizeof(buf), "No such nfnetlink error number %d", errnum); } else { strncpy(buf, nfnl_errlist[errnum], sizeof(buf)-1); buf[sizeof(buf)-1] = '\0'; /* terminate if the error was too long */ } return buf; } void nfnl_perror(const char *s); static const int nfnl_nerr = sizeof (nfnl_errlist) / sizeof (nfnl_errlist[0]); /*******************************/ /***** libnetfilter_queue *****/ #define ENFQ_DUMMY (ENFQ_MAXERR+1) #define ENFQ_BLUB (ENFQ_MAXERR+2) ... const char *nfq_strerror(int errnum) { static char buf[1024]; if (errnum <= ENFNL_MAXERR) { snprintf(buf, sizeof(buf), "%s", nfnl_strerror(errnum)); } else if (errnum >= ENFNL_MAXERR+1+nfq_nerr) { snprintf(buf, sizeof(buf), "No such netfilter_queue error number %d", errnum); } else { strncpy(buf, nfq_errlist[errnum-ENFNL_MAXERR-1], sizeof(buf)-1); buf[sizeof(buf)-1] = '\0'; /* terminate if the error was too long */ } return buf; } /*******************************/ /***** libnetfilter_log *****/ #define ENFLOG_FOO (ENFNL_MAXERR+1) #define ENFLOG_BARFOO (ENFNL_MAXERR+2) ... const char *nflog_strerror(int errnum) { static char buf[1024]; if (errnum <= ENFNL_MAXERR) { snprintf(buf, sizeof(buf), "%s", nfnl_strerror(errnum)); } else if (errnum >= ENFNL_MAXERR+1+nflog_nerr) { snprintf(buf, sizeof(buf), "No such netfilter_log error number %d", errnum); } else { strncpy(buf, nflog_errlist[errnum-ENFNL_MAXERR-1], sizeof(buf)-1); buf[sizeof(buf)-1] = '\0'; /* terminate if the error was too long */ } return buf; } Comments? cu Gregor - -- Gregor Maier Lehrstuhl Informatik 8 gregor@net.in.tum.de Tel: +49 89 289-18010 http://www.net.in.tum.de TU Muenchen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEiZtEdGiwgbikMYMRAmiWAJ9vKqp5xdOLeI3dZzh8xsMEw+bxWgCgmC0t lYaGuEyxlMa7Rvma4qhRdbA= =ZmGE -----END PGP SIGNATURE----- From davem at davemloft.net Fri Jun 9 21:19:09 2006 From: davem at davemloft.net (David Miller) Date: Fri Jun 9 21:42:36 2006 Subject: [NETFILTER 2.6.18 1/3]: recent match: fix "sleeping function called from invalid context" In-Reply-To: <4487CDBD.2070400@trash.net> References: <4487CDBD.2070400@trash.net> Message-ID: <20060609.121909.55725285.davem@davemloft.net> From: Patrick McHardy Date: Thu, 08 Jun 2006 09:11:57 +0200 > These three patches against net-2.6.18 fix two bugs in my recent > match rewrite and a minor thinko in the hashlimit match. > > Please apply. All 3 patches applied, thanks a lot. From vasanthakumar at iitb.ac.in Sat Jun 10 18:02:11 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Sat Jun 10 18:26:15 2006 Subject: LIBIPQ: problem with Injecting encapsulated packet (plz somebody reply) Message-ID: <1277.10.12.25.5.1149955331.squirrel@gpo.iitb.ac.in> Hi, I am posting this query again. plz somebody reply. Also I am new to IPtables and LIBIPQ I am working on a application that involves encapsulatting the packets . Suppose there are 3 machines A B C. Assume that machine A is sending some some information to machine B. All I do is to capture packets(using libipq) destined for machine B on machine A and send it to machine C . I encapuslate this captured packet in a new packet with(adding both IP/UDP header, although UDP header is not really required, with destinatin address as machine C IP). The issue is that after the call to set_verdict function, instead of the encapsulated packet, original packet is getting transmitted. I tried my best to find the solution with no success. I am updating the checksum correctly after adding new header. Below is snippet of my code ************** unsigned char *new_packet = NULL; struct iphdr *new_iphdr; struct iphdr *original_iphdr = (struct iphdr *)(m->payload); int status; new_packet = (unsigned char *) calloc(1,sizeof(struct iphdr) + (m->data_len) + sizeof(struct udphdr)); new_iphdr = (struct iphdr *) calloc(1,sizeof(struct iphdr)); /* extra Udp header */ struct udphdr *new_udp; new_udp = (struct udphdr *) calloc(1,sizeof(struct udphdr)); new_udp->source = htons(50000); new_udp->dest = htons(50000); new_udp->len = original_iphdr->tot_len; new_udp->check = 0; /* udp*/ /** New IP header **/ new_iphdr->version = original_iphdr->version; new_iphdr->ihl = original_iphdr->ihl; new_iphdr->tos = original_iphdr->tos; new_iphdr->id = original_iphdr->id;; new_iphdr->frag_off = original_iphdr->frag_off; new_iphdr->ttl = original_iphdr->ttl; new_iphdr->protocol = original_iphdr->protocol; new_iphdr->saddr= inet_addr("10.107.26.27");//original_iphdr->saddr; new_iphdr->daddr=inet_addr("10.12.25.7");//daddr.s_addr; new_iphdr->tot_len=htons(ntohs(original_iphdr->tot_len)+ (sizeof(struct iphdr))+ sizeof(struct udphdr)); new_iphdr->check=0; new_iphdr->check=(((ip_sum_calc((unsigned short *)new_iphdr,sizeof(struct iphdr))))); // Place the IP packet inside another IP packet memcpy(new_packet,new_iphdr,(unsigned int)sizeof(struct iphdr)); memcpy(new_packet+sizeof(struct iphdr),new_udp,(unsigned int)sizeof(struct udphdr)); memcpy(new_packet+sizeof(struct iphdr)+sizeof(struct udphdr),m->payload,m->data_len); size_t length = ntohs(new_iphdr->tot_len);; status = ipq_set_verdict(handle,m->packet_id,NF_ACCEPT,length,(unsigned char *) new_packet); if(status < 0) { printf("\n Packet Modification failed \n"); die(); } printf("\n Packet Transmitted Successfull \n"); *********checksum function********** unsigned short ip_sum_calc(unsigned short *addr,int len) { int nleft = len; int sum = 0; unsigned short *w = addr; unsigned short answer = 0; printf(" \nsize %d", sizeof(sum)); while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(unsigned char *)(&answer) = *(unsigned char *) w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return answer; } From pablo at netfilter.org Mon Jun 12 00:00:53 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Jun 12 00:21:01 2006 Subject: [PATCH] Unconditionaly push mark to conntrack structure In-Reply-To: <4487D0E2.4030705@trash.net> References: <447CD8AA.2040502@trash.net> <447CDB83.1090606@trash.net> <447CE2B0.8000504@trash.net> <447CE4ED.9010706@netfilter.org> <447CEAF3.5030903@trash.net> <44856875.2020108@netfilter.org> <4487D0E2.4030705@trash.net> Message-ID: <448C9295.9080102@netfilter.org> Patrick McHardy wrote: > Pablo Neira Ayuso wrote: > >>Patrick McHardy wrote: >> >> >>>Pablo Neira Ayuso wrote: >>> >>> >>>>To be frank, I can't see how the timer can be useful from userspace. I >>>>think that we should remove it. >>> >>> >>> >>>Don't you need it for synchronization? One example where it could be >>>useful is to implement different timeout strategies (for example >>>something like pf's adaptive timeouts) in userspace. >> >> >>But these adaptive timeouts could be implemented in kernelspace. > > Thats not a good argument .. by that logic we wouldn't need ctnetlink > at all :) Indeed, weak argument. I've been working today on conntrackd to generalize it more, now it's fairly extensible I think, so this feature can be easily added >>Unfortunately, ctnetlink is not doing any sequence tracking of the >>events at the moment :( and we have to. Here my old PIII 866MHz with a >>100Mbits network card starts dropping events when it reaches ~300 >>simultaneos short TCP connections (2 seconds) with netperf. I'm going to >>cook a patch for this. > > That seems to be pretty poor performance - by sequence tracking you > mean TCP state updates? Is that poor performance with or without > them? I meant that nlmsg_seq is not set in the events sent by ctnetlink. I sent you a RFC patch some days ago, please let me know what you think. About the performance test, I'll do some testing to get some results tomorrow again, then I'll post them so we could comment them. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Mon Jun 12 00:04:08 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Jun 12 00:24:05 2006 Subject: [RFC] libnfnetlink, libnetfilter_log, libnetfilter_queue error handling In-Reply-To: <44899B44.2030605@net.in.tum.de> References: <44899B44.2030605@net.in.tum.de> Message-ID: <448C9358.6070904@netfilter.org> Gregor Maier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > > I noticed that libnfnetlink, libnetfilter_* are currently missing decent > error handling and reporting mechanisms. > > libnetfilter_log and libnetfilter_queue define a nflog_errno resp. > nfq_errno but those aren't really used. libnfnetlink uses fprintf for > error handling/reporting. > > What do you think about the following suggestions: > * add a nfnl_errno variable > * add #defines for nfnl_errno values also add a nfnl_strerror and a > nfnl_perror function > * add #defines for nflog_errno and nfq_errno and nf{log|q}_strerror and > nf{log|q}_perror functions. > > * make nflog_errno and nfq_errno a superset of the nfnl_errnos. E.g. by > defining that error values from 1...N are for nfnl and values above N > are for nfq_errno and nflog_errno. > * nflog_strerror (and nfq_strerror) check if nflog_errno (resp. > nfq_errno) is <= N. If so, they call nfnl_strerror otherwise they handle > the error themselves. All those seem a good idea, I have currently enqueued a set of patches for libnfnetlink and friends that I'll post in some days, still want to give them some spins. I think that we could integrate this changes that you propose. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From max at nucleus.it Mon Jun 12 01:19:15 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Mon Jun 12 01:43:12 2006 Subject: [PATCH] entry_data In-Reply-To: <200606050029.08602.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> Message-ID: <200606120119.16503.max@nucleus.it> Hi, an API isn't worth much if nobody uses it. :) Here is an example of a module that takes advantage of the patch in my previous post. It is a new version of xt_condition ported to 2.6.17-rc6 with entry_data. Just install the regular patchlet and substitute net/netfilter/xt_condition.c with the attacched source. The advantages gained thanks to entry_data are that now match() and destroy() are O(1). The overall code is shorter and, IMHO, clearer. WARNING: this version of condition is still experimental. It worked in my preliminary tests, but I will release a more reliable version as soon as 2.6.17 becomes stable. -- Saluti, Massimiliano Hofer -------------- next part -------------- /*-------------------------------------------*\ | Netfilter Condition Module | | | | Description: This module allows firewall | | rules to match using condition variables | | stored in /proc files. | | | | Author: Stephane Ouellette 2002-10-22 | | | | Massimiliano Hofer 2006-05-15 | | | | | | History: | | 2003-02-10 Second version with improved | | locking and simplified code. | | 2006-05-15 2.6.16 adaptations. | | Locking overhaul. | | Various bug fixes. | | | | This software is distributed under the | | terms of the GNU GPL. | \*-------------------------------------------*/ #include #include #include #include #include #include #include #include #include #include #include #ifndef CONFIG_PROC_FS #error "Proc file system support is required for this module" #endif /* Defaults, these can be overridden on the module command-line. */ static unsigned int condition_list_perms = 0644; static unsigned int compat_dir_name = 0; static unsigned int condition_uid_perms = 0; static unsigned int condition_gid_perms = 0; MODULE_AUTHOR("Stephane Ouellette and Massimiliano Hofer "); MODULE_DESCRIPTION("Allows rules to match against condition variables"); MODULE_LICENSE("GPL"); module_param(condition_list_perms, uint, 0600); MODULE_PARM_DESC(condition_list_perms,"permissions on /proc/net/nf_condition/* files"); module_param(condition_uid_perms, uint, 0600); MODULE_PARM_DESC(condition_uid_perms,"user owner of /proc/net/nf_condition/* files"); module_param(condition_gid_perms, uint, 0600); MODULE_PARM_DESC(condition_gid_perms,"group owner of /proc/net/nf_condition/* files"); module_param(compat_dir_name, bool, 0400); MODULE_PARM_DESC(compat_dir_name,"use old style /proc/net/ipt_condition/* files"); MODULE_ALIAS("ipt_condition"); MODULE_ALIAS("ip6t_condition"); struct condition_variable { struct list_head list; struct proc_dir_entry *status_proc; unsigned int refcount; int enabled; /* TRUE == 1, FALSE == 0 */ }; /* proc_lock is a user context only semaphore used for write access */ /* to the conditions' list. */ static DECLARE_MUTEX(proc_lock); static LIST_HEAD(conditions_list); static struct proc_dir_entry *proc_net_condition = NULL; static const char *dir_name; static int xt_condition_read_info(char __user *buffer, char **start, off_t offset, int length, int *eof, void *data) { struct condition_variable *var = (struct condition_variable *) data; buffer[0] = (var->enabled) ? '1' : '0'; buffer[1] = '\n'; if (length>=2) *eof = 1; return 2; } static int xt_condition_write_info(struct file *file, const char __user *buffer, unsigned long length, void *data) { struct condition_variable *var = (struct condition_variable *) data; char newval; if (length>0) { if (get_user(newval, buffer)) return -EFAULT; /* Match only on the first character */ switch (newval) { case '0': var->enabled = 0; break; case '1': var->enabled = 1; break; } } return (int) length; } static int match(const struct sk_buff *skb, const struct net_device *in, const struct net_device *out, const struct xt_match *match, const void *matchinfo, int offset, unsigned int protoff, int *hotdrop, void *entry_data) { const struct condition_info *info = (const struct condition_info *) matchinfo; struct condition_variable *var= (struct condition_variable *)entry_data; return var->enabled ^ info->invert; } static int checkentry(const char *tablename, const void *ip, const struct xt_match *match, void *matchinfo, unsigned int matchsize, unsigned int hook_mask, void **entry_data) { static const char * const forbidden_names[]={ "", ".", ".." }; struct condition_info *info = (struct condition_info *) matchinfo; struct list_head *pos; struct condition_variable *var, *newvar; int i; /* We don't want a '/' in a proc file name. */ for (i=0; i < CONDITION_NAME_LEN && info->name[i] != '\0'; i++) if (info->name[i] == '/') return 0; /* We can't handle file names longer than CONDITION_NAME_LEN and */ /* we want a NULL terminated string. */ if (i == CONDITION_NAME_LEN) return 0; /* We don't want certain reserved names. */ for (i=0; i < sizeof(forbidden_names)/sizeof(char *); i++) if(strcmp(info->name, forbidden_names[i])==0) return 0; /* Let's acquire the lock, check for the condition and add it */ /* or increase the reference counter. */ if (down_interruptible(&proc_lock)) return -EINTR; list_for_each(pos, &conditions_list) { var = list_entry(pos, struct condition_variable, list); if (strcmp(info->name, var->status_proc->name) == 0) { var->refcount++; *entry_data=(void *)var; up(&proc_lock); return 1; } } /* At this point, we need to allocate a new condition variable. */ newvar = kmalloc(sizeof(struct condition_variable), GFP_KERNEL); if (!newvar) { up(&proc_lock); return -ENOMEM; } /* Create the condition variable's proc file entry. */ newvar->status_proc = create_proc_entry(info->name, condition_list_perms, proc_net_condition); if (!newvar->status_proc) { kfree(newvar); up(&proc_lock); return -ENOMEM; } newvar->refcount = 1; newvar->enabled = 0; newvar->status_proc->owner = THIS_MODULE; newvar->status_proc->data = newvar; wmb(); newvar->status_proc->read_proc = xt_condition_read_info; newvar->status_proc->write_proc = xt_condition_write_info; list_add_rcu(&newvar->list, &conditions_list); newvar->status_proc->uid = condition_uid_perms; newvar->status_proc->gid = condition_gid_perms; up(&proc_lock); *entry_data=(void *)newvar; return 1; } static void destroy(const struct xt_match *match, void *matchinfo, unsigned int matchsize, void *entry_data) { struct condition_info *info = (struct condition_info *) matchinfo; struct condition_variable *var= (struct condition_variable *)entry_data; BUG_ON(entry_data==NULL); down(&proc_lock); if (--var->refcount == 0) { list_del_rcu(&var->list); remove_proc_entry(var->status_proc->name, proc_net_condition); up(&proc_lock); /* synchronize_rcu() would be goog enough, but synchronize_net() */ /* guarantees that no packet will go out with the old rule after */ /* succesful removal. */ synchronize_net(); kfree(var); return; } up(&proc_lock); } static struct xt_match condition_match = { .name = "condition", .family = AF_INET, .matchsize = sizeof(struct condition_info), .match = &match, .checkentry = &checkentry, .destroy = &destroy, .me = THIS_MODULE }; static struct xt_match condition6_match = { .name = "condition", .family = AF_INET, .matchsize = sizeof(struct condition_info), .match = &match, .checkentry = &checkentry, .destroy = &destroy, .me = THIS_MODULE }; static int __init init(void) { int errorcode; dir_name = compat_dir_name? "ipt_condition": "nf_condition"; proc_net_condition = proc_mkdir(dir_name, proc_net); if (!proc_net_condition) { remove_proc_entry(dir_name, proc_net); return -EACCES; } errorcode = xt_register_match(&condition_match); if (errorcode) { xt_unregister_match(&condition_match); remove_proc_entry(dir_name, proc_net); return errorcode; } errorcode = xt_register_match(&condition6_match); if (errorcode) { xt_unregister_match(&condition6_match); xt_unregister_match(&condition_match); remove_proc_entry(dir_name, proc_net); return errorcode; } return 0; } static void __exit fini(void) { xt_unregister_match(&condition6_match); xt_unregister_match(&condition_match); remove_proc_entry(dir_name, proc_net); } module_init(init); module_exit(fini); From pneira at us.es Mon Jun 12 11:50:18 2006 From: pneira at us.es (Pablo Neira Ayuso) Date: Mon Jun 12 12:06:47 2006 Subject: [PATCH] entry_data In-Reply-To: <200606120119.16503.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606120119.16503.max@nucleus.it> Message-ID: <448D38DA.8000404@us.es> Massimiliano Hofer wrote: > an API isn't worth much if nobody uses it. :) > Here is an example of a module that takes advantage of the patch in my > previous post. > > It is a new version of xt_condition ported to 2.6.17-rc6 with entry_data. Just > install the regular patchlet and substitute net/netfilter/xt_condition.c with > the attacched source. > > The advantages gained thanks to entry_data are that now match() and destroy() > are O(1). The overall code is shorter and, IMHO, clearer. > > WARNING: this version of condition is still experimental. It worked in my > preliminary tests, but I will release a more reliable version as soon as > 2.6.17 becomes stable. Fine, please next time send an incremental diff so we all can notice the changes by having a look at the attachment. Thanks. From holger at my-eitzenberger.de Mon Jun 12 14:34:47 2006 From: holger at my-eitzenberger.de (Holger Eitzenberger) Date: Mon Jun 12 14:59:09 2006 Subject: [RFC] libnfnetlink, libnetfilter_log, libnetfilter_queue error handling In-Reply-To: <44899B44.2030605@net.in.tum.de> References: <44899B44.2030605@net.in.tum.de> Message-ID: <20060612123447.GA18551@kruemel.my-eitzenberger.de> On Fri, Jun 09, 2006 at 06:01:08PM +0200, Gregor Maier wrote: > I noticed that libnfnetlink, libnetfilter_* are currently missing decent > error handling and reporting mechanisms. Yes, go ahead and implement proper error handling in the library. For ctsyncd I basically commented out all those printf's. Another point: at least libnetfilter_conntrack is far from "const clean". That is: no even a single function in libnetfilter-conntrack uses 'const' for one of its paramters, though it could. This is quite annoying if you use const in your programs. I have a patch at hand which does this for functions such as nfct_conntrack_compare and some others. I have attached my current version of the patch, status: works-for-me. May someone please comment on it, I will update if need be. Thanks. /holger -------------- next part -------------- [NETFILTER] libnetfilter_conntrack: make partly const clean Not using 'const' in libnetfilter_conntrack does is make hard to use 'const' in programs using it. This patch fixes it partly for the compare and extension libs. Signed-off-by: Holger Eitzenberger --- commit 49ead977ec32613b05082a7b583c8abd407e723a tree 8518d270c18ccb1d1529d956ee6683b4f0b33921 parent 07f71e55c5d9413114661a8d878cf68c698eb7fb author Holger Eitzenberger Sat, 03 Jun 2006 22:10:58 +0200 committer Holger Eitzenberger Sat, 03 Jun 2006 22:10:58 +0200 extensions/libnetfilter_conntrack_icmp.c | 7 +++---- extensions/libnetfilter_conntrack_sctp.c | 9 ++++----- extensions/libnetfilter_conntrack_tcp.c | 9 ++++----- extensions/libnetfilter_conntrack_udp.c | 7 +++---- .../libnetfilter_conntrack.h | 6 +++--- .../libnetfilter_conntrack_extensions.h | 8 ++++---- .../libnetfilter_conntrack_l3extensions.h | 7 ++++--- l3extensions/libnetfilter_conntrack_ipv4.c | 7 +++---- l3extensions/libnetfilter_conntrack_ipv6.c | 7 +++---- src/libnetfilter_conntrack.c | 6 +++--- 10 files changed, 34 insertions(+), 39 deletions(-) diff --git a/extensions/libnetfilter_conntrack_icmp.c b/extensions/libnetfilter_conntrack_icmp.c index 72a7eb0..a6efb7b 100644 --- a/extensions/libnetfilter_conntrack_icmp.c +++ b/extensions/libnetfilter_conntrack_icmp.c @@ -43,7 +43,7 @@ static void build_tuple_proto(struct nfn &t->l4src.icmp.id, sizeof(u_int16_t)); } -static int print_proto(char *buf, struct nfct_tuple *t) +static int print_proto(char *buf, const struct nfct_tuple *t) { /* The ID only makes sense some ICMP messages but we want to * display the same output that /proc/net/ip_conntrack does */ @@ -52,9 +52,8 @@ static int print_proto(char *buf, struct ntohs(t->l4src.icmp.id))); } -static int compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - unsigned int flags) +static int compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, unsigned int flags) { if (flags & ICMP_TYPE) if (ct1->tuple[NFCT_DIR_ORIGINAL].l4dst.icmp.type != diff --git a/extensions/libnetfilter_conntrack_sctp.c b/extensions/libnetfilter_conntrack_sctp.c index 3785c2e..1aea39a 100644 --- a/extensions/libnetfilter_conntrack_sctp.c +++ b/extensions/libnetfilter_conntrack_sctp.c @@ -44,21 +44,20 @@ static void build_tuple_proto(struct nfn &t->l4dst.sctp.port, sizeof(u_int16_t)); } -static int print_protoinfo(char *buf, union nfct_protoinfo *protoinfo) +static int print_protoinfo(char *buf, const union nfct_protoinfo *protoinfo) { /* fprintf(stdout, "%s ", states[protoinfo->sctp.state]); */ return 0; } -static int print_proto(char *buf, struct nfct_tuple *tuple) +static int print_proto(char *buf, const struct nfct_tuple *tuple) { return(sprintf(buf, "sport=%u dport=%u ", htons(tuple->l4src.sctp.port), htons(tuple->l4dst.sctp.port))); } -static int compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - unsigned int flags) +static int compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, unsigned int flags) { if (flags & SCTP_ORIG_SPORT) if (ct1->tuple[NFCT_DIR_ORIGINAL].l4src.sctp.port != diff --git a/extensions/libnetfilter_conntrack_tcp.c b/extensions/libnetfilter_conntrack_tcp.c index 9efdbb7..9c6aa04 100644 --- a/extensions/libnetfilter_conntrack_tcp.c +++ b/extensions/libnetfilter_conntrack_tcp.c @@ -83,20 +83,19 @@ static void build_protoinfo(struct nfnlh nfnl_nest_end(&req->nlh, nest_proto); } -static int print_protoinfo(char *buf, union nfct_protoinfo *protoinfo) +static int print_protoinfo(char *buf, const union nfct_protoinfo *protoinfo) { return(sprintf(buf, "%s ", states[protoinfo->tcp.state])); } -static int print_proto(char *buf, struct nfct_tuple *tuple) +static int print_proto(char *buf, const struct nfct_tuple *tuple) { return(sprintf(buf, "sport=%u dport=%u ", htons(tuple->l4src.tcp.port), htons(tuple->l4dst.tcp.port))); } -static int compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - unsigned int flags) +static int compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, unsigned int flags) { if (flags & TCP_ORIG_SPORT) if (ct1->tuple[NFCT_DIR_ORIGINAL].l4src.tcp.port != diff --git a/extensions/libnetfilter_conntrack_udp.c b/extensions/libnetfilter_conntrack_udp.c index c1d20c3..a329c4a 100644 --- a/extensions/libnetfilter_conntrack_udp.c +++ b/extensions/libnetfilter_conntrack_udp.c @@ -27,7 +27,7 @@ static void parse_proto(struct nfattr *c *(u_int16_t *)NFA_DATA(cda[CTA_PROTO_DST_PORT-1]); } -static int print_proto(char *buf, struct nfct_tuple *tuple) +static int print_proto(char *buf, const struct nfct_tuple *tuple) { return (sprintf(buf, "sport=%u dport=%u ", htons(tuple->l4src.udp.port), htons(tuple->l4dst.udp.port))); @@ -42,9 +42,8 @@ static void build_tuple_proto(struct nfn &t->l4dst.udp.port, sizeof(u_int16_t)); } -static int compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - unsigned int flags) +static int compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, unsigned int flags) { if (flags & UDP_ORIG_SPORT) if (ct1->tuple[NFCT_DIR_ORIGINAL].l4src.udp.port != diff --git a/include/libnetfilter_conntrack/libnetfilter_conntrack.h b/include/libnetfilter_conntrack/libnetfilter_conntrack.h index 3bd30ff..c9ae564 100644 --- a/include/libnetfilter_conntrack/libnetfilter_conntrack.h +++ b/include/libnetfilter_conntrack/libnetfilter_conntrack.h @@ -299,9 +299,9 @@ extern int nfct_sprintf_id(char *buf, u_ /* * Conntrack comparison */ -extern int nfct_conntrack_compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - struct nfct_conntrack_compare *cmp); +extern int nfct_conntrack_compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, + const struct nfct_conntrack_compare *cmp); /* * Expectations diff --git a/include/libnetfilter_conntrack/libnetfilter_conntrack_extensions.h b/include/libnetfilter_conntrack/libnetfilter_conntrack_extensions.h index db7828d..c678f01 100644 --- a/include/libnetfilter_conntrack/libnetfilter_conntrack_extensions.h +++ b/include/libnetfilter_conntrack/libnetfilter_conntrack_extensions.h @@ -27,10 +27,10 @@ struct nfct_proto { void (*parse_protoinfo)(struct nfattr **, struct nfct_conntrack *); void (*build_tuple_proto)(struct nfnlhdr *, int, struct nfct_tuple *); void (*build_protoinfo)(struct nfnlhdr *, int, struct nfct_conntrack *); - int (*print_protoinfo)(char *, union nfct_protoinfo *); - int (*print_proto)(char *, struct nfct_tuple *); - int (*compare)(struct nfct_conntrack *, struct nfct_conntrack *, - unsigned int); + int (*print_protoinfo)(char *, const union nfct_protoinfo *); + int (*print_proto)(char *, const struct nfct_tuple *); + int (*compare)(const struct nfct_conntrack *, + const struct nfct_conntrack *, unsigned int); }; extern void nfct_register_proto(struct nfct_proto *h); diff --git a/include/libnetfilter_conntrack/libnetfilter_conntrack_l3extensions.h b/include/libnetfilter_conntrack/libnetfilter_conntrack_l3extensions.h index 86e002a..2f840ec 100644 --- a/include/libnetfilter_conntrack/libnetfilter_conntrack_l3extensions.h +++ b/include/libnetfilter_conntrack/libnetfilter_conntrack_l3extensions.h @@ -19,9 +19,10 @@ struct nfct_l3proto { void (*parse_proto)(struct nfattr **, struct nfct_tuple *); void (*build_tuple_proto)(struct nfnlhdr *, int, struct nfct_tuple *); - int (*print_proto)(char *, struct nfct_tuple *); - int (*compare)(struct nfct_conntrack *, struct nfct_conntrack *, - unsigned int); + int (*print_proto)(char *, const struct nfct_tuple *); + int (*compare)(const struct nfct_conntrack *, + const struct nfct_conntrack *, + unsigned int); }; extern void nfct_register_l3proto(struct nfct_l3proto *h); diff --git a/l3extensions/libnetfilter_conntrack_ipv4.c b/l3extensions/libnetfilter_conntrack_ipv4.c index 727ea01..08b24b7 100644 --- a/l3extensions/libnetfilter_conntrack_ipv4.c +++ b/l3extensions/libnetfilter_conntrack_ipv4.c @@ -32,7 +32,7 @@ static void build_tuple_proto(struct nfn sizeof(u_int32_t)); } -static int print_proto(char *buf, struct nfct_tuple *tuple) +static int print_proto(char *buf, const struct nfct_tuple *tuple) { struct in_addr src = { .s_addr = tuple->src.v4 }; struct in_addr dst = { .s_addr = tuple->dst.v4 }; @@ -44,9 +44,8 @@ static int print_proto(char *buf, struct return size; } -static int compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - unsigned int flags) +static int compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, unsigned int flags) { if (flags & IPV4_ORIG) if (ct1->tuple[NFCT_DIR_ORIGINAL].l3protonum != diff --git a/l3extensions/libnetfilter_conntrack_ipv6.c b/l3extensions/libnetfilter_conntrack_ipv6.c index b0c7a3f..ec16b8b 100644 --- a/l3extensions/libnetfilter_conntrack_ipv6.c +++ b/l3extensions/libnetfilter_conntrack_ipv6.c @@ -41,7 +41,7 @@ static void build_tuple_proto(struct nfn sizeof(u_int32_t)*4); } -static int print_proto(char *buf, struct nfct_tuple *tuple) +static int print_proto(char *buf, const struct nfct_tuple *tuple) { struct in6_addr src; struct in6_addr dst; @@ -61,9 +61,8 @@ static int print_proto(char *buf, struct return size; } -static int compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - unsigned int flags) +static int compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, unsigned int flags) { if (flags & IPV6_ORIG) if (ct1->tuple[NFCT_DIR_ORIGINAL].l3protonum != diff --git a/src/libnetfilter_conntrack.c b/src/libnetfilter_conntrack.c index 0110261..1ec3231 100644 --- a/src/libnetfilter_conntrack.c +++ b/src/libnetfilter_conntrack.c @@ -926,9 +926,9 @@ void nfct_conntrack_free(struct nfct_con #define L3PROTONUM(ct) ct->tuple[NFCT_DIR_ORIGINAL].l3protonum #define L4PROTONUM(ct) ct->tuple[NFCT_DIR_ORIGINAL].protonum -int nfct_conntrack_compare(struct nfct_conntrack *ct1, - struct nfct_conntrack *ct2, - struct nfct_conntrack_compare *cmp) +int nfct_conntrack_compare(const struct nfct_conntrack *ct1, + const struct nfct_conntrack *ct2, + const struct nfct_conntrack_compare *cmp) { struct nfct_l3proto *l3proto; struct nfct_proto *proto; From max at nucleus.it Mon Jun 12 14:45:41 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Mon Jun 12 15:09:39 2006 Subject: [PATCH] entry_data In-Reply-To: <448D38DA.8000404@us.es> References: <200606050029.08602.max@nucleus.it> <200606120119.16503.max@nucleus.it> <448D38DA.8000404@us.es> Message-ID: <200606121445.42157.max@nucleus.it> On Monday 12 June 2006 11:50 am, Pablo Neira Ayuso wrote: > Fine, please next time send an incremental diff so we all can notice the > changes by having a look at the attachment. Thanks. OK. Here it is. Some of the changes in this diff are due to the 2.6.17 porting, but they are minor. -- Saluti, Massimiliano Hofer Nucleus -------------- next part -------------- A non-text attachment was scrubbed... Name: condition-entry_data.diff Type: text/x-diff Size: 5272 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060612/49894e8f/condition-entry_data-0001.bin From thomas.jarosch at intra2net.com Mon Jun 12 14:59:29 2006 From: thomas.jarosch at intra2net.com (Thomas Jarosch) Date: Mon Jun 12 15:23:19 2006 Subject: [ANNOUNCE] ipt_ACCOUNT 1.6 released Message-ID: <200606121459.29912.thomas.jarosch@intra2net.com> Hello, I'm pleased to announce the release of ipt_ACCOUNT 1.6. Due to popular request I ported it to kernel 2.6. Get it while it's still hot: http://www.intra2net.com/de/produkte/opensource/ipt_account/ Here is a list of changes since the last official release: - Kernel 2.6 support - Fix for /32 netmasks - Improved error handling - Patch-o-matic apt-like download repository Please note: The code in the netfilter SVN tree is not updated anymore. It will soon be completely replaced by the apt-like download repository. Best regards, Thomas Jarosch From heavytull at hotmail.com Mon Jun 12 15:52:16 2006 From: heavytull at hotmail.com (Jethro Tull) Date: Mon Jun 12 16:16:05 2006 Subject: to subscribe to mailing list Message-ID: heavytull@hotmail.com _________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://join.msn.com/messenger/overview From heavytull at hotmail.com Mon Jun 12 16:53:03 2006 From: heavytull at hotmail.com (Jethro Tull) Date: Mon Jun 12 17:16:55 2006 Subject: downloads site Message-ID: on the ftp place to download iptables source codes there are tar balls in the iptables/ directory and I can see the latest verion (1.3.5) but the another directry in it called snapshot/ In which there are some even newer versions, I would like to know what means that directry called snapshot/ is it the location of some special unstable version?? why do they not put those tar balls in the main dir iptables/ ??? also, I read in the INSTALL file in the tar ball that to get latest bugs solved one should apply the patch'o'matic files, but on the ftp site I find files called 'patch 1.y.x to 1.y.x+1' and older than the newest tarballs in the snapshot/ dir. usually on any project they suggest the main release and suggest a new patch very frequently. but here it is the contrary. also i can find patch'o'matic files but are older than newest 'patch 1.y.x to 1.y.x+1' files, does that mean patch'o'matic files are no more in use? _________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://join.msn.com/messenger/overview From danieldegraaf at gmail.com Tue Jun 13 03:51:11 2006 From: danieldegraaf at gmail.com (Daniel De Graaf) Date: Tue Jun 13 04:15:02 2006 Subject: downloads site In-Reply-To: References: Message-ID: <427c54c0606121851x4e8cddecvb9dc93784056c53b@mail.gmail.com> On 6/12/06, Jethro Tull wrote: > on the ftp place to download iptables source codes there are tar balls > in the iptables/ directory and I can see the latest verion (1.3.5) but > the another directry in it called snapshot/ In which there are some > even newer versions, I would like to know what means that directry > called snapshot/ is it the location of some special unstable version?? > why do they not put those tar balls in the main dir iptables/ ??? > > also, I read in the INSTALL file in the tar ball that to get latest > bugs solved one should apply the patch'o'matic files, but on the ftp > site I find files called 'patch 1.y.x to 1.y.x+1' and older than the > newest tarballs in the snapshot/ dir. > usually on any project they suggest the main release and suggest a new > patch very frequently. but here it is the contrary. > > also i can find patch'o'matic files but are older than newest 'patch > 1.y.x to 1.y.x+1' files, does that mean patch'o'matic files are no > more in use? > The snapshots are from subversion, which you can view at http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/. This is the development code, which may have bugfixes and/or new bugs; you can view the changes at that URL. Patch-o-matic is obsolete; it has been replaced by patch-o-matic-ng, which is just a collection of targets/matches. It should be retrieved from a snapshot or directly from svn. The bugfixes have all been added to the mainline kernel. From bjorn.mailinglist at gmail.com Tue Jun 13 09:19:07 2006 From: bjorn.mailinglist at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Lindstr=F6m?=) Date: Tue Jun 13 09:43:19 2006 Subject: writing iptables match Message-ID: <448E66EB.2050706@gmail.com> Im trying to create a new iptables match. I have writen and compiled the kernel module and iptables library. Is it possible to use the new match by inserting the module with insmod and copying the library file to /lib/iptables/ ? If I do this I get Segmantation fault when trying to use the match with iptables -m. Bj?rn From yuri at ecl-labs.org Mon Jun 12 09:35:06 2006 From: yuri at ecl-labs.org (Yuri Gushin) Date: Tue Jun 13 13:15:16 2006 Subject: [PATCH] xt_tcpudp.c match unregistration bug Message-ID: <200606121035.07231.yuri@ecl-labs.org> Hi all, There is a match unregistration bug in the __init function of xt_tcpudp.c; "xt_unregister_match(AF_INET, &tcp_matchstruct)" is called twice, leaving "udp_matchstruct" registered, in case of a failure in the registration of the udp6 structure. Attached is a patch to resolve this issue. Signed-off-by: Yuri Gushin --- a/net/netfilter/xt_tcpudp.c 2006-05-31 03:31:44.000000000 +0300 +++ b/net/netfilter/xt_tcpudp.c 2006-06-11 17:41:20.000000000 +0300 @@ -314,7 +314,7 @@ return ret; out_unreg_udp: - xt_unregister_match(AF_INET, &tcp_matchstruct); + xt_unregister_match(AF_INET, &udp_matchstruct); out_unreg_tcp6: xt_unregister_match(AF_INET6, &tcp6_matchstruct); out_unreg_tcp: From varun at rocsys.com Tue Jun 13 13:10:22 2006 From: varun at rocsys.com (varun) Date: Tue Jun 13 13:26:12 2006 Subject: doubt on Redirect Message-ID: <448E9D1E.9010806@rocsys.com> Hi all, When i use REDIRECT policy will the packet be changed before to the redirected port number before giving yo the next module registered to the same hook? If so why is it that the syn packet from LAN goes through but syn-ack from internet is dropped by my fw when used with iptables (Only for redirect to squid)? Varun From max at nucleus.it Tue Jun 13 22:56:09 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Tue Jun 13 23:39:07 2006 Subject: [PATCH] entry_data In-Reply-To: <448ED795.3010509@netfilter.org> References: <200606050029.08602.max@nucleus.it> <200606121445.42157.max@nucleus.it> <448ED795.3010509@netfilter.org> Message-ID: <200606132256.10384.max@nucleus.it> On Tuesday 13 June 2006 5:19 pm, Pablo Neira Ayuso wrote: > > static int > > match(const struct sk_buff *skb, const struct net_device *in, > > - const struct net_device *out, const void *matchinfo, int offset, > > - unsigned int protoff, int *hotdrop) > > + const struct net_device *out, const struct xt_match *match, > > + const void *matchinfo, int offset, > > + unsigned int protoff, int *hotdrop, void *entry_data) > > Hm, then you must have a patch to modify the interface match()? Of course. I sent a patch in the previous message: https://lists.netfilter.org/pipermail/netfilter-devel/2006-June/024656.html The patches are available here: https://lists.netfilter.org/pipermail/netfilter-devel/attachments/20060605/94b0d808/2.6.17-rc5-entry_data_core-0001.bin https://lists.netfilter.org/pipermail/netfilter-devel/attachments/20060605/94b0d808/2.6.17-rc5-entry_data_matches-0001.bin -- Bye, Massimiliano Hofer From vasanthakumar at iitb.ac.in Tue Jun 13 19:23:09 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Tue Jun 13 23:47:21 2006 Subject: PREROUTING:To update Source and destination IP field (plz reply) Message-ID: <3067.10.12.25.5.1150219389.squirrel@gpo.iitb.ac.in> Dear friends, I am new to iptables and libipq. Please somebody reply to this query Is it possible to change both source and destination field in an IP header in PREROUTING. If not, plz somebody suggest me a way to do that. Let me explain in detail Suppose there are 3 machines A B C. When a packet comes from machine A to machine B. I would like to capture these packets AT MACHINE B BEFORE it goes through routing decision. I would like change the source and the destinatio IP address(modified SOURCE IP = MACHINE B IP, modified DESTINATION IP= MACHINE C IP) including the payload, and then pass it to the routing decision unit. Is it possible to implement this using iptables ? if yes,plz let me know. If not, then plz suggest some ways to do this. Thanx in advance From eric at inl.fr Tue Jun 13 19:06:44 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Jun 13 23:54:18 2006 Subject: [PATCH 1/2] Specify nf_queue max length from userspace In-Reply-To: <1150217788.7164.4.camel@porky> References: <1150217788.7164.4.camel@porky> Message-ID: <1150218404.5386.2.camel@porky> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060613/e114f020/attachment.pgp From eric at inl.fr Tue Jun 13 19:07:58 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Jun 13 23:54:21 2006 Subject: [PATCH 2/2] [libnetfilter_queue] Specify nf_queue max length from userspace In-Reply-To: <1150217788.7164.4.camel@porky> References: <1150217788.7164.4.camel@porky> Message-ID: <1150218479.5386.5.camel@porky> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060613/8d2ab579/attachment-0001.pgp From eric at inl.fr Tue Jun 13 18:56:28 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Jun 13 23:54:22 2006 Subject: [PATCH 0/2] Specify nf_queue max length from userspace Message-ID: <1150217788.7164.4.camel@porky> Hi, With libnetfilter_queue it was not anymore possible to specify the max queue length from userspace. All needed framework was already in nfnetlink_queue code and as queue instance has its own max length, it was thus possible to specify max length on a per queue basis. To be able to do so, I've added a new function nfq_set_queue_maxlen to libnetfilter_queue and done needed modifications in nfnetlink_queue code. BR, -- Eric Leblond INL -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060613/34fd55d9/attachment.pgp From pablo at netfilter.org Tue Jun 13 16:59:41 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Jun 14 00:26:29 2006 Subject: [RFC] ctnetlink events drop benchmark Message-ID: <448ED2DD.30100@netfilter.org> Hi, Finally, I've got some results in my test enviroment about the ctnetlink event drop issue. The machine used as firewall is a PIII 866 256 Mbytes RAM, two NIC realtek 8139 100Mbits running debian unstable with linux kernel 2.6.16. I have run the same test with three different socket queue sizes: 107.520 (default) 215.040 (x2) 430.080 (x4) I used netperf to create the connections with a shell script that loops calling netperf -H ip -l 3 &. To get the number of events dropped I've used the following: $ conntrackd & (run as daemon) $ conntrackd -s (request statistics) Results are available in: http://people.netfilter.org/pablo/ctnetlink/events.eps Currently nlmsg_seq is not set in ctnetlink events, if we set it, we can do some kind of sequence tracking on netlink. If an event gets lost, we can request a resync with the conntrack via dump_conntrack. Another choice could be relax conntrackd states transitions, currently the valid transition sequence is: NEW -> UPDATE -> DESTROY, if an UPDATE event is received but no NEW was seen previously, then the event is ignored. Maybe this is too tight, but since I'm validating the whole thing I prefer remaining "tight" at the moment. Comments welcome. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Tue Jun 13 17:19:49 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Jun 14 00:46:29 2006 Subject: [PATCH] entry_data In-Reply-To: <200606121445.42157.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606120119.16503.max@nucleus.it> <448D38DA.8000404@us.es> <200606121445.42157.max@nucleus.it> Message-ID: <448ED795.3010509@netfilter.org> Massimiliano Hofer wrote: > On Monday 12 June 2006 11:50 am, Pablo Neira Ayuso wrote: > >>Fine, please next time send an incremental diff so we all can notice the >>changes by having a look at the attachment. Thanks. > > OK. Here it is. Some of the changes in this diff are due to the 2.6.17 > porting, but they are minor. > > ------------------------------------------------------------------------ > > diff -Nru linux-2.6.16/net/netfilter/xt_condition.c linux-2.6.17-entry_data/net/netfilter/xt_condition.c > --- linux-2.6.16/net/netfilter/xt_condition.c 2006-04-26 12:07:52.000000000 +0200 > +++ linux-2.6.17-entry_data/net/netfilter/xt_condition.c 2006-06-12 01:49:05.000000000 +0200 > @@ -116,42 +116,32 @@ > > static int > match(const struct sk_buff *skb, const struct net_device *in, > - const struct net_device *out, const void *matchinfo, int offset, > - unsigned int protoff, int *hotdrop) > + const struct net_device *out, const struct xt_match *match, > + const void *matchinfo, int offset, > + unsigned int protoff, int *hotdrop, void *entry_data) Hm, then you must have a patch to modify the interface match()? -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From kadlec at blackhole.kfki.hu Wed Jun 14 09:44:48 2006 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Wed Jun 14 10:08:50 2006 Subject: [RFC] ctnetlink events drop benchmark In-Reply-To: <448ED2DD.30100@netfilter.org> References: <448ED2DD.30100@netfilter.org> Message-ID: Hi Pablo, On Tue, 13 Jun 2006, Pablo Neira Ayuso wrote: > Finally, I've got some results in my test enviroment about the ctnetlink > event drop issue. The machine used as firewall is a PIII 866 256 Mbytes > RAM, two NIC realtek 8139 100Mbits running debian unstable with linux > kernel 2.6.16. > > I have run the same test with three different socket queue sizes: > 107.520 (default) > 215.040 (x2) > 430.080 (x4) > > I used netperf to create the connections with a shell script that loops > calling netperf -H ip -l 3 &. How can you control the connection rate (i.e NEW events) by netperf? > To get the number of events dropped I've used the following: > > $ conntrackd & (run as daemon) > $ conntrackd -s (request statistics) > > Results are available in: > > http://people.netfilter.org/pablo/ctnetlink/events.eps The results are pretty shocking! One would expect (hope) higher event rate without event dropping :-(. > Currently nlmsg_seq is not set in ctnetlink events, if we set it, we can > do some kind of sequence tracking on netlink. If an event gets lost, we > can request a resync with the conntrack via dump_conntrack. Isn't that overkill? I mean, it'd result even more traffic and thus more packet loss. > Another choice could be relax conntrackd states transitions, currently > the valid transition sequence is: NEW -> UPDATE -> DESTROY, if an UPDATE > event is received but no NEW was seen previously, then the event is > ignored. Maybe this is too tight, but since I'm validating the whole > thing I prefer remaining "tight" at the moment. As I see it does not improve the performance over netlink: the message is already received by conntrackd. Can we generalize your results and state that (ct)netlink can handle (on the given hardvare) max 500-1000 messages/s? Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From kadlec at blackhole.kfki.hu Wed Jun 14 10:04:12 2006 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Wed Jun 14 10:28:08 2006 Subject: [RFC] ctnetlink events drop benchmark In-Reply-To: References: <448ED2DD.30100@netfilter.org> Message-ID: On Wed, 14 Jun 2006, Jozsef Kadlecsik wrote: > Can we generalize your results and state that (ct)netlink can handle (on > the given hardvare) max 500-1000 messages/s? Oops, that's false: 500-1000 NEW messages/s. But what is the total number of messages/s? Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From anders at anduras.de Wed Jun 14 11:03:50 2006 From: anders at anduras.de (Sven Anders) Date: Wed Jun 14 11:26:44 2006 Subject: [PATCH] entry_data In-Reply-To: <200606050029.08602.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> Message-ID: <448FD0F6.3010506@anduras.de> Massimiliano Hofer schrieb: > Hi, > here is my proposed patch for an API change that supports entry specific data. > > As explained in my previous posts the purpose of this patch is to give matches > the opportunity to store entry specific data. Several matches already achieve > this reserving some space in the data fields, but these come from userspace > and I don't think it is the Right Way(TM) to do it. Does this mean we can reuse these fields for other puroposes without breaking compatibility with iptables? I'm particularly interested in adding a negation to the "limit" match and I think the match is using one of these special data fields... > /* Ugly, ugly fucker. */ > struct xt_rateinfo *master; If this gives us the possibility to add the negation, who do we distinguish between the old and new limit version. In other words: Who do we reach a maximum compatibility? Gru? Sven -- Sven Anders () Ascii Ribbon Campaign /\ Support plain text e-mail ANDURAS service solutions AG Innstra?e 71 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032 Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Sch?n Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tr?ger From pablo at netfilter.org Wed Jun 14 13:38:40 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Jun 14 13:58:47 2006 Subject: [RFC] ctnetlink events drop benchmark In-Reply-To: References: <448ED2DD.30100@netfilter.org> Message-ID: <448FF540.9050000@netfilter.org> Hi Jozsef, Jozsef Kadlecsik wrote: > On Tue, 13 Jun 2006, Pablo Neira Ayuso wrote: > > >>Finally, I've got some results in my test enviroment about the ctnetlink >>event drop issue. The machine used as firewall is a PIII 866 256 Mbytes >>RAM, two NIC realtek 8139 100Mbits running debian unstable with linux >>kernel 2.6.16. >> >>I have run the same test with three different socket queue sizes: >>107.520 (default) >>215.040 (x2) >>430.080 (x4) >> >>I used netperf to create the connections with a shell script that loops >>calling netperf -H ip -l 3 &. > > > How can you control the connection rate (i.e NEW events) by netperf? I can't, but I can measure the time required to create N connections >>To get the number of events dropped I've used the following: >> >>$ conntrackd & (run as daemon) >>$ conntrackd -s (request statistics) >> >>Results are available in: >> >>http://people.netfilter.org/pablo/ctnetlink/events.eps > > > The results are pretty shocking! One would expect (hope) higher event rate > without event dropping :-(. > > >>Currently nlmsg_seq is not set in ctnetlink events, if we set it, we can >>do some kind of sequence tracking on netlink. If an event gets lost, we >>can request a resync with the conntrack via dump_conntrack. > > Isn't that overkill? I mean, it'd result even more traffic and thus more > packet loss. AFAIK, dumping in done in data chunks of one memory page long. A data chunk isn't enqueued until the process calls recv(), therefore a new chunk is enqueued iff the process has processed the previous chunk. So, dumping really doesn't consumes too much space in the queue but you are right, if the dumping happens at the time that the queue is full, then the packet will get lost. >>Another choice could be relax conntrackd states transitions, currently >>the valid transition sequence is: NEW -> UPDATE -> DESTROY, if an UPDATE >>event is received but no NEW was seen previously, then the event is >>ignored. Maybe this is too tight, but since I'm validating the whole >>thing I prefer remaining "tight" at the moment. > > As I see it does not improve the performance over netlink: the message is > already received by conntrackd. > > Can we generalize your results and state that (ct)netlink can handle (on > the given hardvare) max 500-1000 messages/s? No, the graph doesn't talk about messages/s, just messages: after reading your comments, it seems that the graph can be misleading. Please, have a look at these results in text format: http://people.netfilter.org/pablo/ctnetlink/107520.txt I think that it can be better to get some conclusions. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Wed Jun 14 14:24:42 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Jun 14 14:45:32 2006 Subject: [RFC] ctnetlink events drop benchmark In-Reply-To: References: <448ED2DD.30100@netfilter.org> Message-ID: <4490000A.7020500@netfilter.org> Jozsef Kadlecsik wrote: > On Wed, 14 Jun 2006, Jozsef Kadlecsik wrote: > >>Can we generalize your results and state that (ct)netlink can handle (on >>the given hardvare) max 500-1000 messages/s? > > Oops, that's false: 500-1000 NEW messages/s. But what is the total number > of messages/s? Actually, my concern wasn't really to get the messages/s rate. I started the benchmark to know if ctnetlink can back off under big stress situation, in other words, if I could experiment messages loss. This is really important to validate conntrackd. And it could also be for other subsystems like nfqueue. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From kaber at trash.net Wed Jun 14 15:55:29 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Jun 14 16:19:42 2006 Subject: [RFC] ctnetlink events drop benchmark In-Reply-To: <448ED2DD.30100@netfilter.org> References: <448ED2DD.30100@netfilter.org> Message-ID: <44901551.8080400@trash.net> Pablo Neira Ayuso wrote: > Hi, > > Finally, I've got some results in my test enviroment about the ctnetlink > event drop issue. The machine used as firewall is a PIII 866 256 Mbytes > RAM, two NIC realtek 8139 100Mbits running debian unstable with linux > kernel 2.6.16. > > I have run the same test with three different socket queue sizes: > 107.520 (default) > 215.040 (x2) > 430.080 (x4) > > I used netperf to create the connections with a shell script that loops > calling netperf -H ip -l 3 &. > > To get the number of events dropped I've used the following: > > $ conntrackd & (run as daemon) > $ conntrackd -s (request statistics) > > Results are available in: > > http://people.netfilter.org/pablo/ctnetlink/events.eps Does "events" mean events/s? > Currently nlmsg_seq is not set in ctnetlink events, if we set it, we can > do some kind of sequence tracking on netlink. If an event gets lost, we > can request a resync with the conntrack via dump_conntrack. nlmsg_seq should only (but in that case it really should) be set for responses to queries, so userspace can associate responses with queries. Drops are reported as -ENOBUFS socket errors to all multicast listeners. > Another choice could be relax conntrackd states transitions, currently > the valid transition sequence is: NEW -> UPDATE -> DESTROY, if an UPDATE > event is received but no NEW was seen previously, then the event is > ignored. Maybe this is too tight, but since I'm validating the whole > thing I prefer remaining "tight" at the moment. I guess this could be made configurable, but I think for testing purposes its better to be stricter so it doesn't shadow real problems. From kaber at trash.net Wed Jun 14 16:05:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Jun 14 16:29:14 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes In-Reply-To: <1149771143.28481.87.camel@localhost.localdomain> References: <1149153349.28481.15.camel@localhost.localdomain> <447F1227.7050900@trash.net> <447F5204.4080505@trash.net> <1149771143.28481.87.camel@localhost.localdomain> Message-ID: <44901796.6040000@trash.net> Jesper Dangaard Brouer wrote: > For example something like the following patch? > > I have tracked down where the "Resource temporarily unavailable" occurs > in libiptc.c, and marked it with a comment... if you can use it for any > thing. Seems like you forgot to attach the patch :) From pablo at netfilter.org Wed Jun 14 18:39:01 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Jun 14 18:59:12 2006 Subject: [RFC] ctnetlink events drop benchmark In-Reply-To: <44901551.8080400@trash.net> References: <448ED2DD.30100@netfilter.org> <44901551.8080400@trash.net> Message-ID: <44903BA5.4030405@netfilter.org> Patrick McHardy wrote: > Pablo Neira Ayuso wrote: > >>Hi, >> >>Finally, I've got some results in my test enviroment about the ctnetlink >>event drop issue. The machine used as firewall is a PIII 866 256 Mbytes >>RAM, two NIC realtek 8139 100Mbits running debian unstable with linux >>kernel 2.6.16. >> >>I have run the same test with three different socket queue sizes: >>107.520 (default) >>215.040 (x2) >>430.080 (x4) >> >>I used netperf to create the connections with a shell script that loops >>calling netperf -H ip -l 3 &. >> >>To get the number of events dropped I've used the following: >> >>$ conntrackd & (run as daemon) >>$ conntrackd -s (request statistics) >> >>Results are available in: >> >>http://people.netfilter.org/pablo/ctnetlink/events.eps > > > Does "events" mean events/s? No, sorry, it seems that the graph is definitely misleading :(. Have a look at http://people.netfilter.org/pablo/ctnetlink/107520.txt >>Currently nlmsg_seq is not set in ctnetlink events, if we set it, we can >>do some kind of sequence tracking on netlink. If an event gets lost, we >>can request a resync with the conntrack via dump_conntrack. > > > nlmsg_seq should only (but in that case it really should) be set for > responses to queries, so userspace can associate responses with queries. > Drops are reported as -ENOBUFS socket errors to all multicast listeners. Good point. Thanks. >>Another choice could be relax conntrackd states transitions, currently >>the valid transition sequence is: NEW -> UPDATE -> DESTROY, if an UPDATE >>event is received but no NEW was seen previously, then the event is >>ignored. Maybe this is too tight, but since I'm validating the whole >>thing I prefer remaining "tight" at the moment. > > I guess this could be made configurable, but I think for testing > purposes its better to be stricter so it doesn't shadow real > problems. Indeed, I'm going to add a configurable parameter. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From kaber at trash.net Wed Jun 14 20:36:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Jun 14 21:00:20 2006 Subject: [RFC] ctnetlink events drop benchmark In-Reply-To: <44903BA5.4030405@netfilter.org> References: <448ED2DD.30100@netfilter.org> <44901551.8080400@trash.net> <44903BA5.4030405@netfilter.org> Message-ID: <4490571A.5070102@trash.net> Pablo Neira Ayuso wrote: > Patrick McHardy wrote: > >>> http://people.netfilter.org/pablo/ctnetlink/events.eps >> >> >> Does "events" mean events/s? > > > No, sorry, it seems that the graph is definitely misleading :(. Have a > look at http://people.netfilter.org/pablo/ctnetlink/107520.txt I can't seem to find the number of drops in that table, which I thought this test was all about :) I did some plotting with the numbers myself, comparing (1):(2)/(1) with (1):(3)/(1) (actually / 6.353 to scale the initial UPDATE value down to NEW) shows that UPDATE events scale much more linear than NEW events, which could either mean they get dropped more for some reason or that the connections had a higher number of packets in the runs with more connections (possibly because of more retransmissions). I think we need the number of packets per connection to make sense out of the data. From hawk at comx.dk Wed Jun 14 16:40:40 2006 From: hawk at comx.dk (Jesper Dangaard Brouer) Date: Thu Jun 15 14:05:22 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes In-Reply-To: <44901796.6040000@trash.net> References: <1149153349.28481.15.camel@localhost.localdomain> <447F1227.7050900@trash.net> <447F5204.4080505@trash.net> <1149771143.28481.87.camel@localhost.localdomain> <44901796.6040000@trash.net> Message-ID: <1150296040.26187.114.camel@localhost.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060614/426663ed/attachment.pgp From kaber at trash.net Sat Jun 17 17:24:04 2006 From: kaber at trash.net (Patrick McHardy) Date: Sun Jun 18 18:06:01 2006 Subject: [H.323 Helper 4/5]: Put expect after use In-Reply-To: References: Message-ID: <44941E94.1090600@trash.net> Jing Min Zhao wrote: > Bugfix: Put expect after use. I'll try to get this one in 2.6.17 - will take until tommorrow though since I'm currently travelling. From kaber at trash.net Sat Jun 17 17:20:33 2006 From: kaber at trash.net (Patrick McHardy) Date: Sun Jun 18 18:06:03 2006 Subject: [H.323 Helper 5/5]: Add support for Call Forwarding In-Reply-To: References: Message-ID: <44941DC1.8080904@trash.net> Jing Min Zhao wrote: > Add support for Call Forwarding. > > Signed-off-by: Jing Min Zhao That patch is already queued in Dave's net-2.6.18 tree, so I guess these patches are against Linus' current tree. Please rebase your patchset against the net-2.6.18 tree and resend. Thanks. git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.18.git From kaber at trash.net Sat Jun 17 17:21:19 2006 From: kaber at trash.net (Patrick McHardy) Date: Sun Jun 18 18:06:04 2006 Subject: [H.323 Helper 2/5]: Change helper definitions In-Reply-To: References: Message-ID: <44941DEF.3010106@trash.net> Jing Min Zhao wrote: > Change helpers' structure definitions to meet some old compilers. > > Signed-off-by: Jing Min Zhao This seems to be for gcc-2.95, which isn't supported by the kernel anymore. From eric at inl.fr Sat Jun 17 23:24:41 2006 From: eric at inl.fr (Eric Leblond) Date: Sun Jun 18 18:07:51 2006 Subject: [PATCH 1/2] Specify nf_queue max length from userspace In-Reply-To: <4492A5E5.1020308@netfilter.org> References: <1150217788.7164.4.camel@porky> <1150218404.5386.2.camel@porky> <4492A5E5.1020308@netfilter.org> Message-ID: <1150579481.20920.15.camel@porky> Hi Pablo, On Fri, 2006-06-16 at 14:36 +0200, Pablo Neira Ayuso wrote: > Hi Eric, > > enum nfqnl_config_mode { > > + NFQNL_COPY_UNSPEC, > > NFQNL_COPY_NONE, > > NFQNL_COPY_META, > > NFQNL_COPY_PACKET, > > If you have to add new attributes, do it always at the end, in other > words, just before NFQNL_COPY_MAX. Otherwise you're breaking backward > compatibility. See that old binaries use COPY_NONE set to 0, but after > applying your patch COPY_NONE is set to 1. Result: old binaries will no > work with nfnetlink_queue anymore. I agree with you on this point. But, as I know that second point was also breaking compatibility, I've made the choice to put less significant value first. It looks cleaner to me. > > @@ -75,6 +76,7 @@ enum nfqnl_config_mode { > > struct nfqnl_msg_config_params { > > u_int32_t copy_range; > > u_int8_t copy_mode; /* enum nfqnl_config_mode */ > > + u_int32_t queue_maxlen; > > } __attribute__ ((packed)); > > Same thing here. If you have to modify this structure, you need to > create a new one called struct nfqnl_msg_config_params2. Since I don't > like this option, I think that the best solution is to add a new > attribute called NFQNL_CFG_QUEUE_MAXLEN. I also think this is the cleanest way not to loose binary compatibility. But, as you notice it, it's ugly as queue max length is a param. The user-basis of libnetfilter_queue is really small for the moment: Only about two projects use it. There may be also some unpublished project but it should hurt too much to break binary compatibility to have a cleaner code. In fact, I think that having only one attribute and one structure could be used in the future to have a function that will be able to set copy mode and queue length in one call and one message. BR, -- Eric Leblond INL -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060618/08ed9365/attachment.pgp From max at nucleus.it Sun Jun 18 00:55:22 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Sun Jun 18 18:32:21 2006 Subject: [PATCH] entry_data In-Reply-To: <448FD0F6.3010506@anduras.de> References: <200606050029.08602.max@nucleus.it> <448FD0F6.3010506@anduras.de> Message-ID: <200606180055.25350.max@nucleus.it> On Wednesday 14 June 2006 11:03 am, Sven Anders wrote: > > As explained in my previous posts the purpose of this patch is to give > > matches the opportunity to store entry specific data. Several matches > > already achieve this reserving some space in the data fields, but these > > come from userspace and I don't think it is the Right Way(TM) to do it. > > Does this mean we can reuse these fields for other puroposes without > breaking compatibility with iptables? Yes, with some caveats. > I'm particularly interested in adding a negation to the "limit" match and I > think the match is using one of these special data fields... > > > /* Ugly, ugly fucker. */ > > struct xt_rateinfo *master; > > If this gives us the possibility to add the negation, who do we distinguish > between the old and new limit version. In other words: Who do we reach a > maximum compatibility? In your case, the current version doesn't use master in userspace and immediately wipes it in kernel space. You could just replace it with another field (without changing the total size), start using it in the new libipt_limit and detect it accordingly from userspace while using my patch for the real master (supposing my patch is accepted). This would never lead to a crash, but the new userspace wouldn't be able to distinguish if it has an appropriate kernel and it may silently drop the negation with older versions. For this purpose you could use the revision field and set a higher minum revision when the limit is negated. This leads me to a more radical proposal. Is there any reason we don't have a general way to negate matches? It wouldn't be too difficult and we could implement some new features such as negating the whole set of matches or a single entry. We could even abandon the madatory logical AND of every entry and pass a minterm set (with AND as the default), but maybe this is too general. -- Saluti, Massimiliano Hofer Nucleus From kernel at linuxace.com Sat Jun 17 23:29:45 2006 From: kernel at linuxace.com (Phil Oester) Date: Sun Jun 18 18:40:56 2006 Subject: Bugzilla down Message-ID: <20060617212945.GA31778@linuxace.com> Get this error on bugzilla for at least the past few days Software error: ./data/versioncache did not return a true value at globals.pl line 358. Harald? Phil From pablo at netfilter.org Sun Jun 18 19:13:11 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sun Jun 18 19:34:07 2006 Subject: [PATCH 1/2] Specify nf_queue max length from userspace In-Reply-To: <1150579481.20920.15.camel@porky> References: <1150217788.7164.4.camel@porky> <1150218404.5386.2.camel@porky> <4492A5E5.1020308@netfilter.org> <1150579481.20920.15.camel@porky> Message-ID: <449589A7.10508@netfilter.org> Eric Leblond wrote: > Hi Pablo, > > On Fri, 2006-06-16 at 14:36 +0200, Pablo Neira Ayuso wrote: > >>Hi Eric, >> >>> enum nfqnl_config_mode { >>>+ NFQNL_COPY_UNSPEC, >>> NFQNL_COPY_NONE, >>> NFQNL_COPY_META, >>> NFQNL_COPY_PACKET, >> >>If you have to add new attributes, do it always at the end, in other >>words, just before NFQNL_COPY_MAX. Otherwise you're breaking backward >>compatibility. See that old binaries use COPY_NONE set to 0, but after >>applying your patch COPY_NONE is set to 1. Result: old binaries will no >>work with nfnetlink_queue anymore. > > > I agree with you on this point. But, as I know that second point was > also breaking compatibility, I've made the choice to put less > significant value first. It looks cleaner to me. > > >>>@@ -75,6 +76,7 @@ enum nfqnl_config_mode { >>> struct nfqnl_msg_config_params { >>> u_int32_t copy_range; >>> u_int8_t copy_mode; /* enum nfqnl_config_mode */ >>>+ u_int32_t queue_maxlen; >>> } __attribute__ ((packed)); >> >>Same thing here. If you have to modify this structure, you need to >>create a new one called struct nfqnl_msg_config_params2. Since I don't >>like this option, I think that the best solution is to add a new >>attribute called NFQNL_CFG_QUEUE_MAXLEN. > > > I also think this is the cleanest way not to loose binary compatibility. > But, as you notice it, it's ugly as queue max length is a param. The > user-basis of libnetfilter_queue is really small for the moment: Only > about two projects use it. There may be also some unpublished project > but it should hurt too much to break binary compatibility to have a > cleaner code. Actually, this is what happen when you attach kernel and userspace to a certain structure. Instead, I think that it is better to split structures into fields. > In fact, I think that having only one attribute and one structure could > be used in the future to have a function that will be able to set copy > mode and queue length in one call and one message. This is not true, you can still implement a function that sets the queue length and copy mode with the solution that I proposed. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Fri Jun 16 14:36:53 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sun Jun 18 20:40:21 2006 Subject: [PATCH 1/2] Specify nf_queue max length from userspace In-Reply-To: <1150218404.5386.2.camel@porky> References: <1150217788.7164.4.camel@porky> <1150218404.5386.2.camel@porky> Message-ID: <4492A5E5.1020308@netfilter.org> Hi Eric, Eric Leblond wrote: > include/linux/netfilter/nfnetlink_queue.h | 2 ++ > net/netfilter/nfnetlink_queue.c | 7 ++++++- > 2 files changed, 8 insertions(+), 1 deletions(-) > > 1fb988dc51e2465500df50ff4e085f80acb7b6a3 > diff --git a/include/linux/netfilter/nfnetlink_queue.h b/include/linux/netfilter/nfnetlink_queue.h > index 9e77437..ce32c54 100644 > --- a/include/linux/netfilter/nfnetlink_queue.h > +++ b/include/linux/netfilter/nfnetlink_queue.h > @@ -67,6 +67,7 @@ struct nfqnl_msg_config_cmd { > } __attribute__ ((packed)); > > enum nfqnl_config_mode { > + NFQNL_COPY_UNSPEC, > NFQNL_COPY_NONE, > NFQNL_COPY_META, > NFQNL_COPY_PACKET, If you have to add new attributes, do it always at the end, in other words, just before NFQNL_COPY_MAX. Otherwise you're breaking backward compatibility. See that old binaries use COPY_NONE set to 0, but after applying your patch COPY_NONE is set to 1. Result: old binaries will no work with nfnetlink_queue anymore. > @@ -75,6 +76,7 @@ enum nfqnl_config_mode { > struct nfqnl_msg_config_params { > u_int32_t copy_range; > u_int8_t copy_mode; /* enum nfqnl_config_mode */ > + u_int32_t queue_maxlen; > } __attribute__ ((packed)); Same thing here. If you have to modify this structure, you need to create a new one called struct nfqnl_msg_config_params2. Since I don't like this option, I think that the best solution is to add a new attribute called NFQNL_CFG_QUEUE_MAXLEN. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From azez at ufomechanic.net Fri Jun 16 16:24:08 2006 From: azez at ufomechanic.net (Amin Azez) Date: Sun Jun 18 21:34:55 2006 Subject: [PATCH] ipt_account rate patch Message-ID: Here are some patches I did for ipt_account before ipt_ACCOUNT which supports larger subnets was re-released. As well as per-ip packet and byte counting, the patches also does per-ip rate calculating, so you can use this as part of a rate limiting rule and drop packets that would exceed the rate. You get to choose whether or not dropped packets should also be accounted. Just as ipt_account supports total-subnet accounting, so we also support total-subnet rate calculations as well. The rate calculations are an improved version of what is in ip_conntrack_rate.c, namely we can handle the timer wraps around zero. Sam -------------- next part -------------- --- extensions/libipt_account.c.rate 2006-05-16 11:14:35.000000000 +0100 +++ extensions/libipt_account.c 2006-05-16 15:23:38.000000000 +0100 @@ -34,14 +34,50 @@ "--ashort\n" " table will colect only short statistics (only total counters\n" " without splitting it into protocols.\n" + "--non-subnet\n" + " Traffic whose src or dst ip is not in the account subnet\n" + " should be counted as matching, even though no rate tests\n" + " can be done.\n" + "--above\n" + " Matches if any of the ranges are exceeded\n" + "--below\n" + " (Default) Matches if none of the ranges are exceeded\n" + "[!] --src-rate rate\n" + " TRUE if IP-specific rate on packets from that subnets [not] in range\n" + "[!] --src-subnet-rate\n" + " TRUE if rate on all packets from that subnets [not] in range\n" + "[!] --dst-rate rate\n" + " TRUE if IP-specific rate on packets to that subnets [not] in range\n" + "[!] --dst-subnet-rate rate\n" + " TRUE if rate on all packets to that subnets [not] in range\n" + "--ignore-src-over\n" + " Don't count packets if rate is exceeded.\n" + " Perhaps Use this if you intend to drop such packets.\n" + "--ignore-dst-over\n" + " Don't count packets if rate is exceeded.\n" + " Perhaps Use this if you intend to drop such packets.\n" + "--check-only\n" + " Don't count packets at all, just check decayed rate to\n" + " calculate if the packet would have been dropped.\n" , IPTABLES_VERSION); }; static struct option opts[] = { - { .name = "aaddr", .has_arg = 1, .flag = NULL, .val = 201 }, - { .name = "aname", .has_arg = 1, .flag = NULL, .val = 202 }, - { .name = "ashort", .has_arg = 0, .flag = NULL, .val = 203 }, + { .name = "aaddr", .has_arg = 1, .flag = NULL, .val = 201 }, + { .name = "aname", .has_arg = 1, .flag = NULL, .val = 202 }, + { .name = "ashort", .has_arg = 0, .flag = NULL, .val = 203 }, + { .name = "src-rate", .has_arg = 1, .flag = NULL, .val = 204 }, + { .name = "src-subnet-rate", .has_arg = 1, .flag = NULL, .val = 205 }, + { .name = "dst-rate", .has_arg = 1, .flag = NULL, .val = 206 }, + { .name = "dst-subnet-rate", .has_arg = 1, .flag = NULL, .val = 207 }, + { .name = "ignore-src-over", .has_arg = 0, .flag = NULL, .val = 208 }, + { .name = "ignore-dst-over", .has_arg = 0, .flag = NULL, .val = 209 }, + { .name = "check-only", .has_arg = 0, .flag = NULL, .val = 210 }, + { .name = "not", .has_arg = 0, .flag = NULL, .val = 211 }, + { .name = "above", .has_arg = 0, .flag = NULL, .val = 211 }, + { .name = "below", .has_arg = 0, .flag = NULL, .val = 212 }, + { .name = "non-subnet", .has_arg = 0, .flag = NULL, .val = 213 }, { .name = 0, .has_arg = 0, .flag = 0, .val = 0 } }; @@ -206,6 +242,39 @@ case 203: info->shortlisting = 1; break; + case 204: + info->src_rate=atoi(optarg); + if (invert) info->accounting|=IPT_ACCOUNT_INVERT_src_RATE; + break; + case 205: + info->src_subnet_rate=atoi(optarg); + if (invert) info->accounting|=IPT_ACCOUNT_INVERT_src_SUBNET_RATE; + break; + case 206: + info->dest_rate=atoi(optarg); + if (invert) info->accounting|=IPT_ACCOUNT_INVERT_dest_RATE; + break; + case 207: + info->dest_subnet_rate=atoi(optarg); + if (invert) info->accounting|=IPT_ACCOUNT_INVERT_dest_SUBNET_RATE; + break; + case 208: + info->accounting|=IPT_ACCOUNT_src_OVER; + break; + case 209: + info->accounting|=IPT_ACCOUNT_dest_OVER; + break; + case 210: + info->accounting|=IPT_ACCOUNT_CHECKONLY; + break; + case 211: + info->accounting|=IPT_ACCOUNT_INVERT; + break; + case 212: /* we default to below */ + break; + case 213: + info->accounting|=IPT_ACCOUNT_INVERT_NAME; + break; default: return 0; } @@ -235,6 +304,30 @@ printf("name: %s ", info->name); if (info->shortlisting) printf("short-listing "); + + if ((info->accounting & IPT_ACCOUNT_INVERT) && (info->src_rate || info->src_subnet_rate || info->dest_rate || info->dest_subnet_rate)) + printf("NOT "); + printf("("); + if (info->src_rate) + printf("src-rate: %c %u B/s ",(info->accounting & IPT_ACCOUNT_INVERT_src_RATE)?'>':'<',info->src_rate); + + if (info->src_subnet_rate) + printf("src-subnet-rate: %c %u B/s ",(info->accounting & IPT_ACCOUNT_INVERT_src_SUBNET_RATE)?'>':'<',info->src_subnet_rate); + + if (info->dest_rate) + printf("dst-rate: %c %u B/s ",(info->accounting & IPT_ACCOUNT_INVERT_dest_RATE)?'>':'<',info->dest_rate); + + if (info->dest_subnet_rate) + printf("dst-subnet-rate: %c %u B/s ",(info->accounting & IPT_ACCOUNT_INVERT_dest_SUBNET_RATE)?'>':'<',info->dest_subnet_rate); + printf(") "); + if (info->accounting & IPT_ACCOUNT_src_OVER) + printf("ignore-src-over "); + + if (info->accounting & IPT_ACCOUNT_dest_OVER) + printf("ignore-dst-over "); + + if (info->accounting & IPT_ACCOUNT_CHECKONLY) + printf("check-only "); } /* Function used for saving rule containing account match */ @@ -252,6 +345,41 @@ printf("--aname %s ", info->name); if (info->shortlisting) printf("--ashort "); + + if ((info->accounting & IPT_ACCOUNT_INVERT_NAME)) + printf("--non-subnet "); + + if ((info->accounting & IPT_ACCOUNT_INVERT) && (info->src_rate || info->src_subnet_rate || info->dest_rate || info->dest_subnet_rate)) + printf("--above "); + + if (info->src_rate) { + if (info->accounting & IPT_ACCOUNT_INVERT_src_RATE) printf("! "); + printf("--src-rate %u ",info->src_rate); + } + + if (info->src_subnet_rate) { + if (info->accounting & IPT_ACCOUNT_INVERT_src_SUBNET_RATE) printf("! "); + printf("--src-subnet-rate %u ",info->src_subnet_rate); + } + + if (info->dest_rate) { + if (info->accounting & IPT_ACCOUNT_INVERT_dest_RATE) printf("! "); + printf("--dst-rate %d ",info->dest_rate); + } + + if (info->dest_subnet_rate) { + if (info->accounting & IPT_ACCOUNT_INVERT_dest_SUBNET_RATE) printf("! "); + printf("--dst-subnet-rate %d ",info->dest_subnet_rate); + } + + if (info->accounting & IPT_ACCOUNT_src_OVER) + printf("--ignore-src-over "); + + if (info->accounting & IPT_ACCOUNT_dest_OVER) + printf("--ignore-dst-over "); + + if (info->accounting & IPT_ACCOUNT_CHECKONLY) + printf("--check-only "); } static struct iptables_match account = { -------------- next part -------------- A non-text attachment was scrubbed... Name: ipt_account_rate.patch Type: text/x-patch Size: 22145 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060618/97da5f71/ipt_account_rate-0001.bin From pablo at netfilter.org Mon Jun 19 01:26:58 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Jun 19 01:47:29 2006 Subject: [RFC,PATCH] introduce new API for libnfnetlink Message-ID: <4495E142.5000209@netfilter.org> Hi! I have been spending some time on libnfnetlink these days based on a previous patch that I sent some time ago [1]. Since the amount of changes would result in API breakages, that is something that I consider that we don't want, I decided to start some kind of version 2 of libnfnetlink, the major changes from the current version is: - Uniform error handling via errno - Use of new netlink ADD_MEMBERSHIP socket option to join multicast groups - A new approach for challenge functions listen/talk, now they use the callbacks registered via register_callback() - Single loop processing: nfnetlink_process() - Iterators: more control for the programmer in the nfnetlink data processing - addattr* simplification - Documentation available The patch is available at: http://people.netfilter.org/pablo/libnfnetlink-newapi.patch This is still a work in progress, it needs more testing. I have plans to do something similar for libnetfilter_conntrack in order to solve the existing limitations. Comments welcome. [1] http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3315 -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Mon Jun 19 02:15:10 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Jun 19 02:35:37 2006 Subject: [PATCH] entry_data In-Reply-To: <200606132256.10384.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606121445.42157.max@nucleus.it> <448ED795.3010509@netfilter.org> <200606132256.10384.max@nucleus.it> Message-ID: <4495EC8E.6030006@netfilter.org> Massimiliano Hofer wrote: > On Tuesday 13 June 2006 5:19 pm, Pablo Neira Ayuso wrote: > > >>> static int >>> match(const struct sk_buff *skb, const struct net_device *in, >>>- const struct net_device *out, const void *matchinfo, int offset, >>>- unsigned int protoff, int *hotdrop) >>>+ const struct net_device *out, const struct xt_match *match, >>>+ const void *matchinfo, int offset, >>>+ unsigned int protoff, int *hotdrop, void *entry_data) >> >>Hm, then you must have a patch to modify the interface match()? > > > Of course. I sent a patch in the previous message: > https://lists.netfilter.org/pipermail/netfilter-devel/2006-June/024656.html > > The patches are available here: > https://lists.netfilter.org/pipermail/netfilter-devel/attachments/20060605/94b0d808/2.6.17-rc5-entry_data_core-0001.bin > https://lists.netfilter.org/pipermail/netfilter-devel/attachments/20060605/94b0d808/2.6.17-rc5-entry_data_matches-0001.bin Unfortunately, your patch breaks old iptables binaries, so it can't guarantee backward compatibility :( pablo@Decadence:~$ head -10 2.6.17-rc5-entry_data_core-0001.bin diff -Nru linux-2.6.17-rc5/include/linux/netfilter/x_tables.h linux-2.6.17-rc5.entry_data_core/include/linux/netfilter/x_tables.h --- linux-2.6.17-rc5/include/linux/netfilter/x_tables.h 2006-06-04 21:30:58.000000000 +0200 +++ linux-2.6.17-rc5.entry_data_core/include/linux/netfilter/x_tables.h 2006-06-04 21:34:03.000000000 +0200 @@ -20,6 +20,7 @@ /* Used inside the kernel */ struct xt_match *match; + void *entry_data; } kernel; You can't modify the layout of xt_entry_[match|target] since this structure is shared between userspace (iptables) and kernel space. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From jain_m79 at yahoo.com Mon Jun 19 07:36:46 2006 From: jain_m79 at yahoo.com (Manish Jain) Date: Mon Jun 19 08:01:19 2006 Subject: New to IPSets - Not working as expected Message-ID: <20060619053646.47093.qmail@web42203.mail.yahoo.com> I want to dump all packets coming from IP 192.168.1.18 in syslog. For this, I have created following ipset and iptable. But it is not working for me. Please guide me. ipset -N test2 ipmap --from 192.168.1.1 --to 192.168.255.255 iptables -A INPUT -m set --set test2 src -j LOG Best Regards, Manish Jain __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From max at nucleus.it Mon Jun 19 09:02:08 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Mon Jun 19 09:26:45 2006 Subject: [PATCH] entry_data In-Reply-To: <4495EC8E.6030006@netfilter.org> References: <200606050029.08602.max@nucleus.it> <200606132256.10384.max@nucleus.it> <4495EC8E.6030006@netfilter.org> Message-ID: <200606190902.09597.max@nucleus.it> On Monday 19 June 2006 2:15 am, Pablo Neira Ayuso wrote: > Unfortunately, your patch breaks old iptables binaries, so it can't > guarantee backward compatibility :( I explicitly devoloped it in order not to break compatibility with userspace. Did you test it? What problems did you experience? Of course I break API compatibility within the kernel, so this is an all or nothing patch. If people think it's useful it should be merged in the mainline kernel and every patchlet updated accordingly. I think this API is cleaner and more expressive. > /* Used inside the kernel */ > struct xt_match *match; > + void *entry_data; > } kernel; > > You can't modify the layout of xt_entry_[match|target] since this > structure is shared between userspace (iptables) and kernel space. You're right, but I modified the kernel side of a union and I was careful not to change the total size. This union is never really used by both sides simultaneously. -- Saluti, Massimiliano Hofer Nucleus From bjorn.mailinglist at gmail.com Mon Jun 19 11:08:36 2006 From: bjorn.mailinglist at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Lindstr=F6m?=) Date: Mon Jun 19 11:33:33 2006 Subject: checking rule specifications in a match Message-ID: <44966994.6020402@gmail.com> Hi. I am writing an iptables match to match the IEC-60870-5-104 protocol. I only want this match to be used on tcp packets and therefore I want iptables to reject rules if does not specify tcp as the protocol (-p tcp). I am currently doing this check in the checkentry function in the kernel module. This works but the error message only say "iptables: Unknown error 4294967295" if -p tcp is left out. Is it possible to do this check any other way to get a more comprehensible error message? Thanks. Bj?rn Lindstr?m From mfarooq100 at hotmail.com Fri Jun 16 23:34:06 2006 From: mfarooq100 at hotmail.com (Mohammad Farooq) Date: Mon Jun 19 14:35:00 2006 Subject: Filtering RTP packet Message-ID: Hi All, I have a linux box which sits between the two RTP clients. I would like to have a kernel module which looks at the RTP packets. If this packet contailns DTMF digit, it passes the packet to the user space otherwise it forwards the packet to the destination address without any change. As we know RTP protocol sits on top of UDP. I am new to iptables and not very familar with the kernel module development. I would appreciate if someone point me to the right direction. Thanks in advance. M. Farooq From kaber at trash.net Mon Jun 19 16:53:30 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 17:18:14 2006 Subject: [PATCH] xt_sctp - add SCTP header size to IP header offset In-Reply-To: <200606081754.09073.jorge.matias@motorola.com> References: <200606081754.09073.jorge.matias@motorola.com> Message-ID: <4496BA6A.3040308@trash.net> Jorge Matias Martin wrote: > Hi, all. > > xt_sctp module is not working on 2.6.16 when --chunk-types option is used. I > have test this running sctp_darn and the following iptables options: > > -A INPUT -p sctp --chunk-types any INIT -j DROP > > And this is the kernel log output: > > spt: 32822 dpt: 10105 > Chunk num: 1 offset: 20 type: 128 length: 10105 flags: 36 > skb->len: 92 offset: 10128 > spt: 10105 dpt: 32822 > Chunk num: 1 offset: 20 type: 39 length: 32822 flags: 79 > skb->len: 284 offset: 32844 > spt: 32822 dpt: 10105 > Chunk num: 1 offset: 20 type: 128 length: 10105 flags: 36 > ... > > > Note that length is actually the local port, and offset must be 32 (20 IPv4 > header + 12 SCTP header). > > FYI, it works properly when --chunk-types is not used. Looks good too me. Please add a Signed-off-by: line so I can apply it. Thanks. From kaber at trash.net Mon Jun 19 16:55:27 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 17:20:02 2006 Subject: Packet Lost In-Reply-To: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> References: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> Message-ID: <4496BADF.5000405@trash.net> Vasantha Kumar Puttappa wrote: > Hi, > > I am working on a small application using iptables/libipq. In this, the > application would capture a specific packets based on the destination IP > address. Then I encapsulate this IP packet inside another new IP packet. > > My problem is that the encapsulation part works fine in > kernel-2.6.11-6(mandriva 2005) and IPtables V 1.2.9. > (I can capture encapsulated packets using tcpdump at the sender side i.e, > packets are being put on to the network) > > > But this doesn't work in kernel-2.6.12-12 and IPtables-1.3.5 > (even though there are no erros after callig ipq_set_verdict, the packets > are not being put on to the channel. The packets are getting lost after > the call to ipq_set_verdict) > > please let me know if you need more information IIRC some old versions accidentally fixed up broken checksums they received from userspace and this is not done anymore. Do your packets have correct checksums when sent from userspace to the kernel? From kaber at trash.net Mon Jun 19 17:00:03 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 17:24:38 2006 Subject: [PATCH] xt_tcpudp.c match unregistration bug In-Reply-To: <200606121035.07231.yuri@ecl-labs.org> References: <200606121035.07231.yuri@ecl-labs.org> Message-ID: <4496BBF3.2090209@trash.net> Yuri Gushin wrote: > Hi all, > > There is a match unregistration bug in the __init function of xt_tcpudp.c; > > "xt_unregister_match(AF_INET, &tcp_matchstruct)" is called twice, > leaving "udp_matchstruct" registered, in case of a failure in the > registration of the udp6 structure. > > Attached is a patch to resolve this issue. Applied. thanks. From kaber at trash.net Mon Jun 19 17:33:43 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 17:58:18 2006 Subject: Mailing list slow? Message-ID: <4496C3D7.2040809@trash.net> Is it just me or are other people also experiencing large delays with mails to netfilter-devel? My mails are visible on the lists.netfilter.org web interface but I receive them with large delay .. From kaber at trash.net Mon Jun 19 17:38:45 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:03:20 2006 Subject: [RFC][1/2] New netfilter match module : kernel patch In-Reply-To: <20060602190238.92524.qmail@web50208.mail.yahoo.com> References: <20060602190238.92524.qmail@web50208.mail.yahoo.com> Message-ID: <4496C505.9080907@trash.net> Alex Davis wrote: > This is an update the kernel netfilter patch that allows > matching the source or destination address of an IP > packet to a network interface. I can't see any other way to do this, but I'm not so thrilled to add a whole new match just for this. It's not a perfect match, but how about adding this as an option to the addrtype match for RTN_LOCAL addresses? Better suggestions where we can put this are welcome. From kaber at trash.net Mon Jun 19 17:50:16 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:14:55 2006 Subject: [PATCH] Named realm - updated In-Reply-To: <200606042135.49361.simonl@parknet.dk> References: <200606042135.49361.simonl@parknet.dk> Message-ID: <4496C7B8.5020006@trash.net> Simon Lodal wrote: > Make the realm match accept named realms, defined in /etc/iproute2/rt_realms. > > First sent 2006-05-21, improved since then: > - Only load rt_realms once, keep in memory. > - Output realm by name if it was originally specified that way, except if > iptables -n. Thanks. I still have a few points before we can merge this, please see below. > ------------------------------------------------------------------------ > > Index: linux-2.6/include/linux/netfilter/xt_realm.h > =================================================================== > --- linux-2.6/include/linux/netfilter/xt_realm.h (revision 44) > +++ linux-2.6/include/linux/netfilter/xt_realm.h (revision 45) > @@ -5,6 +5,7 @@ > u_int32_t id; > u_int32_t mask; > u_int8_t invert; > + u_int8_t is_named_realm; No no no :) This breaks compatibility (well, it does not due to structure padding, but still, structures shared between kernel and userspace should be considered untouchable). Names are to be shown when numeric == 0, otherwise not. It doesn't matter in which format the user specified the rule. > }; > > #endif /* _XT_REALM_H */ > > > ------------------------------------------------------------------------ > > diff -ruN iptables-1.3.5.base/extensions/libipt_realm.c iptables-1.3.5/extensions/libipt_realm.c > --- iptables-1.3.5.base/extensions/libipt_realm.c 2006-06-04 01:49:33.000000000 +0200 > +++ iptables-1.3.5/extensions/libipt_realm.c 2006-06-04 01:50:06.000000000 +0200 > @@ -3,6 +3,8 @@ > #include > #include > #include > +#include > +#include > #include > #if defined(__GLIBC__) && __GLIBC__ == 2 > #include > @@ -28,6 +30,116 @@ > {0} > }; > > +struct realmname { > + int id; > + char* name; > + int len; > + struct realmname* next; > +}; > + > +/* array of realms from /etc/iproute2/rt_realms */ > +static struct realmname *realms = NULL; > +/* 1 if loading failed */ > +static int rdberr = 0; > + > + > +void load_realms() > +{ > + const char* rfnm = "/etc/iproute2/rt_realms"; > + char buf[512]; > + FILE *fil; > + char *cur, *nxt; > + int id; > + struct realmname *oldnm = NULL, *newnm = NULL; > + > + fil = fopen(rfnm, "r"); > + if (!fil) { > + rdberr = 1; > + return; > + } > + > + while (fgets(buf, sizeof(buf), fil)) { > + cur = buf; > + while ((*cur == ' ') || (*cur == '\t')) cur++; > + if ((*cur == '#') || (*cur == '\n') || (*cur == 0)) > + continue; > + > + /* iproute2 allows hex and dec format */ > + errno = 0; Why do you need to fiddle with errno? Unless you missed to check it before that shouldn't be necessary. > + id = strtoul(cur, &nxt, strncmp(cur, "0x", 2) ? 10 : 16); > + if ((nxt == cur) || errno) { > + continue; > + } > + > + /* same boundaries as in iproute2 */ > + if (id < 0 || id > 256) continue; That doesn't look right. There is a limit of 256 for tables, but realms are 32 bit values. > + cur = nxt; > + > + if (!isspace(*cur)) continue; > + while ((*cur == ' ') || (*cur == '\t')) cur++; > + if ((*cur == '#') || (*cur == '\n') || (*cur == 0)) > + continue; > + nxt = cur; > + while ((*nxt != 0) && !isspace(*nxt)) nxt++; nxt++ goes on the next line > + if (nxt == cur) continue; continue goes on the next line. There are more instances of this, please just fix all of them. > + > + /* found valid data */ > + newnm = (struct realmname*)malloc(sizeof(struct realmname)); > + if (NULL == newnm) { Please stick to the coding style used commonly within iptables, i.e. newnm == NULL. Same for the other comparisons. > + perror("libipt_realm: malloc failed"); > + exit(1); > + } > + newnm->id = id; > + newnm->len = nxt - cur; > + newnm->name = (char*)malloc(newnm->len + 1); > + if (NULL == newnm->name) { > + perror("libipt_realm: malloc failed"); > + exit(1); > + } > + strncpy(newnm->name, cur, newnm->len); > + newnm->name[newnm->len] = 0; > + newnm->next = NULL; > + > + if (oldnm) { > + oldnm->next = newnm; > + } else { > + realms = newnm; > + } > + oldnm = newnm; > + } > + > + fclose(fil); > +} > + > +/* get realm id for name, -1 if error/not found */ > +int realm_name2id(const char* name) > +{ > + if ((NULL == realms) && (0 == rdberr)) load_realms(); > + if (NULL == realms) return -1; > + > + struct realmname* cur = realms; Besided beeing ugly in my opinion, declarations after statements are not supported by gcc-2.95. > + while (cur) { > + if (!strncmp(name, cur->name, cur->len + 1)) return cur->id; > + cur = cur->next; > + } > + return -1; > +} > + > +/* get realm name for id, NULL if error/not found */ > +const char* realm_id2name(int id) > +{ > + if ((NULL == realms) && (0 == rdberr)) load_realms(); > + if (NULL == realms) return NULL; > + > + struct realmname* cur = realms; > + while (cur) { > + if (id == cur->id) return cur->name; > + cur = cur->next; > + } > + return NULL; > +} > + > + > /* Function which parses command options; returns true if it > ate an option */ > static int > @@ -42,14 +154,26 @@ > char *end; > case '1': > check_inverse(argv[optind-1], &invert, &optind, 0); > - optarg = argv[optind-1]; > + end = optarg = argv[optind-1]; > realminfo->id = strtoul(optarg, &end, 0); > - if (*end == '/') { > - realminfo->mask = strtoul(end+1, &end, 0); > - } else > + if ((end != optarg) && (('/' == *end) || ('\0' == *end))) { > + if (*end == '/') { > + realminfo->mask = strtoul(end+1, &end, 0); > + } else > + realminfo->mask = 0xffffffff; > + if (*end != '\0' || end == optarg) > + exit_error(PARAMETER_PROBLEM, > + "Bad realm value `%s'", optarg); > + } else { > + int id = realm_name2id(optarg); > + if (-1 == id) { > + exit_error(PARAMETER_PROBLEM, > + "Realm `%s' not found", optarg); > + } > + realminfo->id = (u_int32_t)id; > realminfo->mask = 0xffffffff; > - if (*end != '\0' || end == optarg) > - exit_error(PARAMETER_PROBLEM, "Bad realm value `%s'", optarg); > + realminfo->is_named_realm = 1; > + } > if (invert) > realminfo->invert = 1; > *flags = 1; > @@ -62,12 +186,22 @@ > } > > static void > -print_realm(unsigned long id, unsigned long mask) > +print_realm(unsigned long id, unsigned long mask, int is_named) > { > + const char* name = NULL; > + > if (mask != 0xffffffff) > printf("0x%lx/0x%lx ", id, mask); > - else > - printf("0x%lx ", id); > + else { > + if (1 == is_named) { > + name = realm_id2name(id); > + } > + if (name) { > + printf("%s ", name); > + } else { > + printf("0x%lx ", id); > + } > + } > } > > /* Prints out the matchinfo. */ > @@ -82,7 +216,7 @@ > printf("! "); > > printf("realm "); > - print_realm(ri->id, ri->mask); > + print_realm(ri->id, ri->mask, numeric ? 0 : ri->is_named_realm); > } > > > @@ -96,7 +230,7 @@ > printf("! "); > > printf("--realm "); > - print_realm(ri->id, ri->mask); > + print_realm(ri->id, ri->mask, ri->is_named_realm); > } > > /* Final check; must have specified --mark. */ > diff -ruN iptables-1.3.5.base/extensions/libipt_realm.man iptables-1.3.5/extensions/libipt_realm.man > --- iptables-1.3.5.base/extensions/libipt_realm.man 2004-10-10 11:56:27.000000000 +0200 > +++ iptables-1.3.5/extensions/libipt_realm.man 2006-06-04 01:50:15.000000000 +0200 > @@ -1,5 +1,7 @@ > This matches the routing realm. Routing realms are used in complex routing > setups involving dynamic routing protocols like BGP. > .TP > -.BI "--realm " "[!]" "value[/mask]" > -Matches a given realm number (and optionally mask). > +.BI "--realm " "[!] " "value[/mask]" > +Matches a given realm number (and optionally mask). If not a number, value > +can be a named realm from /etc/iproute2/rt_realms (mask can not be used in > +that case). From kaber at trash.net Mon Jun 19 17:54:17 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:18:57 2006 Subject: [PATCH] fix conntrack compilation In-Reply-To: <1149512507.20946.5.camel@localhost.localdomain> References: <1149512507.20946.5.camel@localhost.localdomain> Message-ID: <4496C8A9.4000704@trash.net> Eric Leblond wrote: > It seems that subversion version of conntrack tool does not compile to > due the lack of inclusion of "config.h". I have no idea if this is "the right fix", but I trust someone will flame me if not, so applied :) Thanks. From kaber at trash.net Mon Jun 19 17:59:09 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:23:44 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <44888CD7.8090601@rtij.nl> References: <448051F3.1070509@trash.net> <1149267610.3021.11.camel@localhost.localdomain> <448072FC.3060902@trash.net> <44809B1C.2010907@gmx.net> <4487CEA8.8060701@trash.net> <44888CD7.8090601@rtij.nl> Message-ID: <4496C9CD.8070701@trash.net> Martijn Lievaart wrote: > Patrick McHardy wrote: > >> Yes, its getting a bit tight in there, but so far in all setups I've >> seen it was possible to get along with the 32 bits using masks or >> reusing bits after they are no longer needed. I guess we'll have to >> wait and see .. >> >> > > Something I've been thinking about. Currently it is impossible to write > any kind of generic tool that uses the mark and plays nice with other > generic tools. Maybe we need some kind of API that allocates bits in the > mark. Something like "give me two bits", that returns some handle to the > bits. That handle could then be used for identifying the bits in the mark. It can see that it would be useful for complex setups, but I can't think of an efficient implementation of this. You would have to carry a table of handle identifiers -> mark ranges with every packet, wouldn't you? From kaber at trash.net Mon Jun 19 18:01:59 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:26:34 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <4488B629.1070608@snapgear.com> References: <448051F3.1070509@trash.net> <4487CEA8.8060701@trash.net> <44888CD7.8090601@rtij.nl> <200606082340.41755.simonl@parknet.dk> <4488A215.5030305@rtij.nl> <4488B629.1070608@snapgear.com> Message-ID: <4496CA77.2050501@trash.net> Philip Craig wrote: > It may be enough to extend the conntrack mark, but not the packet mark, > so that we aren't growing the skb. Would need fancier operations for > transferring only parts of the conntrack mark to the packet mark. In my experience its really the nfmark bits that are getting hard to use in complex setups. I never had problems with conntrack mark .. I have an almost finished patch for nfmark mask support for routing rules, which should provide a bit of relief for people using it for routing. From kaber at trash.net Mon Jun 19 18:07:26 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:32:03 2006 Subject: [PATCH] xt_sctp - add SCTP header size to IP header offset In-Reply-To: <200606191758.48909.jorge.matias@motorola.com> References: <200606081754.09073.jorge.matias@motorola.com> <4496BA6A.3040308@trash.net> <200606191758.48909.jorge.matias@motorola.com> Message-ID: <4496CBBE.30902@trash.net> Jorge Matias Martin wrote: > On 19 June 2006 16:53, Patrick McHardy wrote: > >>Looks good too me. Please add a Signed-off-by: line so I can >>apply it. Thanks. > > > Signed-off-by: Jorge Matias Applied, thanks. From kaber at trash.net Mon Jun 19 18:26:24 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:50:59 2006 Subject: [PATCH 1/2] Specify nf_queue max length from userspace In-Reply-To: <1150218404.5386.2.camel@porky> References: <1150217788.7164.4.camel@porky> <1150218404.5386.2.camel@porky> Message-ID: <4496D030.1010400@trash.net> Eric Leblond wrote: > Attach patch is against current git kernel tree. > > > > ------------------------------------------------------------------------ > > Signed-off-by: Eric Leblond > > > --- > > include/linux/netfilter/nfnetlink_queue.h | 2 ++ > net/netfilter/nfnetlink_queue.c | 7 ++++++- > 2 files changed, 8 insertions(+), 1 deletions(-) > > 1fb988dc51e2465500df50ff4e085f80acb7b6a3 > diff --git a/include/linux/netfilter/nfnetlink_queue.h b/include/linux/netfilter/nfnetlink_queue.h > index 9e77437..ce32c54 100644 > --- a/include/linux/netfilter/nfnetlink_queue.h > +++ b/include/linux/netfilter/nfnetlink_queue.h > @@ -67,6 +67,7 @@ struct nfqnl_msg_config_cmd { > } __attribute__ ((packed)); > > enum nfqnl_config_mode { > + NFQNL_COPY_UNSPEC, > NFQNL_COPY_NONE, > NFQNL_COPY_META, > NFQNL_COPY_PACKET, Looks like an ABI breaker. > @@ -75,6 +76,7 @@ enum nfqnl_config_mode { > struct nfqnl_msg_config_params { > u_int32_t copy_range; > u_int8_t copy_mode; /* enum nfqnl_config_mode */ > + u_int32_t queue_maxlen; > } __attribute__ ((packed)); This too. Why not just use a new attribute? From kaber at trash.net Mon Jun 19 18:29:14 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 18:53:49 2006 Subject: Concurrency issues with the iptables userspace program andexitcodes In-Reply-To: <1150296040.26187.114.camel@localhost.localdomain> References: <1149153349.28481.15.camel@localhost.localdomain> <447F1227.7050900@trash.net> <447F5204.4080505@trash.net> <1149771143.28481.87.camel@localhost.localdomain> <44901796.6040000@trash.net> <1150296040.26187.114.camel@localhost.localdomain> Message-ID: <4496D0DA.6030300@trash.net> Jesper Dangaard Brouer wrote: > Hmmm... I though I did include it inline below my signature... well lets > try again...This time I also attach it as a file attachment. Applied, thanks. I got a reject on the libiptc part, so I just left it out. > diff --exclude '*.d' --exclude-from /var/kernel/exclude_these -urpN iptables-1.3.4-pom-l7/libiptc/libiptc.c iptables-1.3.4-pom-l7-blocking/libiptc/libiptc.c > --- iptables-1.3.4-pom-l7/libiptc/libiptc.c 2005-10-31 20:03:49.000000000 +0100 > +++ iptables-1.3.4-pom-l7-blocking/libiptc/libiptc.c 2006-06-07 10:25:02.000000000 +0200 > @@ -2104,6 +2104,7 @@ TC_COMMIT(TC_HANDLE_T *handle) > free(repl->counters); > free(repl); > free(newcounters); > + // The "EAGAIN: Resource temporarily unavailable" occurs here. > return 0; > } > From kaber at trash.net Mon Jun 19 18:36:56 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 19:01:48 2006 Subject: [RFC,PATCH] sequence numbering for ctnetlink events In-Reply-To: <4485B52C.7020207@netfilter.org> References: <4485B52C.7020207@netfilter.org> Message-ID: <4496D2A8.3080007@trash.net> Pablo Neira Ayuso wrote: > Hi, > > This patch adds sequence numbering for event messages generated by > ctnetlink, it is still imcomplete (nf_conntrack_netlink). > > I'm having tons of problems these days, and this makes everything really > hard: my laptop died, so my home pc did, my mail at eurodev was down... > so I'm reading netfilter mail from the archives and I have to spend some > time to set up again a git tree to test my patches, and... recent debian > kernels are broken with UML... :( UML works once every two month for me, but then randomly, without changing anything, stops working again. I've mostly given up on it, the time to figure out the problem du jour is just not worth it. > [RFC,PATCH] sequence numbering for ctnetlink events > > This patch adds sequence numbering to ctnetlink event messages > send to userspace. As we discussed in the ctnetlink benchmark thread, sequence numbers should only be sent for responses to queries to allow userspace to associate them with each other. Care to cook up another patch? Otherwise I'll take care of it. From kaber at trash.net Mon Jun 19 19:34:47 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 20:00:08 2006 Subject: [PATCH] entry_data In-Reply-To: <448FD0F6.3010506@anduras.de> References: <200606050029.08602.max@nucleus.it> <448FD0F6.3010506@anduras.de> Message-ID: <4496E037.2000706@trash.net> Sven Anders wrote: > Massimiliano Hofer schrieb: > >>Hi, >>here is my proposed patch for an API change that supports entry specific data. >> >>As explained in my previous posts the purpose of this patch is to give matches >>the opportunity to store entry specific data. Several matches already achieve >>this reserving some space in the data fields, but these come from userspace >>and I don't think it is the Right Way(TM) to do it. > > > Does this mean we can reuse these fields for other puroposes without breaking > compatibility with iptables? Yes, userspace ignores these fields. I still haven't really made up my mind about this patch yet. I don't like the void ** approach very much, but I didn't got around to thinking about something better yet. Please stay patient with me :) > I'm particularly interested in adding a negation to the "limit" match and I > think the match is using one of these special data fields... > > > /* Ugly, ugly fucker. */ > > struct xt_rateinfo *master; > > If this gives us the possibility to add the negation, who do we distinguish > between the old and new limit version. In other words: Who do we reach a maximum > compatibility? IIRC userspace zeroes this field, so you could just do the usual "0 -> no inversion, 1 -> inversion" thing and it would behave correctly for both old and new userspace. But you need check yourself if this is indeed true, I'm not really sure. From kaber at trash.net Mon Jun 19 19:45:22 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 20:10:44 2006 Subject: [PATCH] entry_data In-Reply-To: <200606180055.25350.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <448FD0F6.3010506@anduras.de> <200606180055.25350.max@nucleus.it> Message-ID: <4496E2B2.6010209@trash.net> Massimiliano Hofer wrote: > This leads me to a more radical proposal. Is there any reason we don't have a > general way to negate matches? It wouldn't be too difficult and we could > implement some new features such as negating the whole set of matches or a > single entry. > We could even abandon the madatory logical AND of every entry and pass a > minterm set (with AND as the default), but maybe this is too general. It would be useful for some matches (basically those that only check a single attribute), others may want to combine negated matching on some attributes with non-negated matching on others. In these cases it might still be useful to negate the entire result. It would have the advantage of getting more consistent behaviour, currently some matches treat unknown conditions or errors as "always no match", independant of inversion. For example xt_connmark: const u_int32_t *ctmark = nf_ct_get_mark(skb, &ctinfo); if (!ctmark) return 0; ... my opinion is that if the packet doesn't have a mark the expression ! is clearly true. Another questionable behaviour in my opinion is using hotdrop to drop packets which are missing the information we are interested in. The same argument holds here, if something is not present, it just doesn't match. And negated it does match. The least we should do is have consistent behaviour, so either connmark should also use hotdrop, or nobody should (well, except for the few cases where it is unsed in case of memory allocation failures and things like that). From vasanthakumar at iitb.ac.in Mon Jun 19 21:23:38 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Mon Jun 19 21:49:07 2006 Subject: Packet Lost In-Reply-To: <4496BADF.5000405@trash.net> References: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> <4496BADF.5000405@trash.net> Message-ID: <4921.10.12.25.5.1150745018.squirrel@gpo.iitb.ac.in> > Vasantha Kumar Puttappa wrote: >> Hi, >> >> I am working on a small application using iptables/libipq. In this, >> the >> application would capture a specific packets based on the destination IP >> address. Then I encapsulate this IP packet inside another new IP packet. >> >> My problem is that the encapsulation part works fine in >> kernel-2.6.11-6(mandriva 2005) and IPtables V 1.2.9. >> (I can capture encapsulated packets using tcpdump at the sender side >> i.e, >> packets are being put on to the network) >> >> >> But this doesn't work in kernel-2.6.12-12 and IPtables-1.3.5 >> (even though there are no erros after callig ipq_set_verdict, the >> packets >> are not being put on to the channel. The packets are getting lost after >> the call to ipq_set_verdict) >> >> please let me know if you need more information > > IIRC some old versions accidentally fixed up broken checksums > they received from userspace and this is not done anymore. > Do your packets have correct checksums when sent from userspace > to the kernel? > > ya my checksum calculation is correct. If my checksum is wrong, it would have been detected by tcpdump or ethereal(in 2.6.11-6). Any suggestions ? From kaber at trash.net Mon Jun 19 21:32:11 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 19 21:57:00 2006 Subject: Packet Lost In-Reply-To: <4921.10.12.25.5.1150745018.squirrel@gpo.iitb.ac.in> References: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> <4496BADF.5000405@trash.net> <4921.10.12.25.5.1150745018.squirrel@gpo.iitb.ac.in> Message-ID: <4496FBBB.8090303@trash.net> Vasantha Kumar Puttappa wrote: >>IIRC some old versions accidentally fixed up broken checksums >>they received from userspace and this is not done anymore. >>Do your packets have correct checksums when sent from userspace >>to the kernel? >> > > ya my checksum calculation is correct. If my checksum is wrong, it would > have been detected by tcpdump or ethereal(in 2.6.11-6). No it wouldn't have been, thats what I'm saying. Old ipq versions silently fixed broken checksums. Depending on the hook you're queueing packets at they might get dropped locally if the checksum is corrupt. From eric at inl.fr Mon Jun 19 21:57:10 2006 From: eric at inl.fr (Eric Leblond) Date: Mon Jun 19 22:21:48 2006 Subject: [PATCH 1/2] Specify nf_queue max length from userspace In-Reply-To: <4496D030.1010400@trash.net> References: <1150217788.7164.4.camel@porky> <1150218404.5386.2.camel@porky> <4496D030.1010400@trash.net> Message-ID: <1150747030.6979.6.camel@porky> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060619/175ae25d/attachment-0001.pgp From eric at inl.fr Mon Jun 19 22:01:08 2006 From: eric at inl.fr (Eric Leblond) Date: Mon Jun 19 22:25:46 2006 Subject: [PATCH 2/2] Specify nf_queue max length from userspace In-Reply-To: <4496D030.1010400@trash.net> References: <1150217788.7164.4.camel@porky> <1150218404.5386.2.camel@porky> <4496D030.1010400@trash.net> Message-ID: <1150747268.6979.10.camel@porky> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060619/77586e52/attachment.pgp From max at nucleus.it Tue Jun 20 00:35:06 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Tue Jun 20 00:59:47 2006 Subject: [PATCH] entry_data In-Reply-To: <4496E037.2000706@trash.net> References: <200606050029.08602.max@nucleus.it> <448FD0F6.3010506@anduras.de> <4496E037.2000706@trash.net> Message-ID: <200606200035.07197.max@nucleus.it> On Monday 19 June 2006 7:34 pm, Patrick McHardy wrote: > Yes, userspace ignores these fields. I still haven't really made up my > mind about this patch yet. I don't like the void ** approach very much, I understand your concerns, but it's either that or feeding it its own struct xt_entry_match *. This would be awfully circular, while the practice of passing someting * to functions is widespread. This only happens to be applied to a void *. If anyone has a better way s?he's more than welcome. > but I didn't got around to thinking about something better yet. Please > stay patient with me :) I'll be patient. :) -- Saluti, Massimiliano Hofer Nucleus From max at nucleus.it Tue Jun 20 01:05:03 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Tue Jun 20 01:29:45 2006 Subject: [PATCH] entry_data In-Reply-To: <4496E2B2.6010209@trash.net> References: <200606050029.08602.max@nucleus.it> <200606180055.25350.max@nucleus.it> <4496E2B2.6010209@trash.net> Message-ID: <200606200105.04286.max@nucleus.it> On Monday 19 June 2006 7:45 pm, Patrick McHardy wrote: > > This leads me to a more radical proposal. Is there any reason we don't > > have a general way to negate matches? It wouldn't be too difficult and we [...] > It would be useful for some matches (basically those that only check > a single attribute), others may want to combine negated matching > on some attributes with non-negated matching on others. In these I agree with you. Let's suppose we want to implement this feature and we don't want to cause major breakage. I can't find a suitable bit in xt_entry_match, but we could define a "wrapper match". We could set u.name to "!" or something similar and data to: struct { int invert; struct xt_entry_match nested_xt_entry_match; }; Similar wrappers would effectively transform a simple linear data structure in a tree, so I don't think this is a thing we should endorse lighly. Any better ideas? > ... my opinion is that if the packet doesn't have a mark the expression > ! is clearly true. Another questionable behaviour in my opinion > is using hotdrop to drop packets which are missing the information we > are interested in. The same argument holds here, if something is not > present, it just doesn't match. And negated it does match. The least > we should do is have consistent behaviour, so either connmark should > also use hotdrop, or nobody should (well, except for the few cases > where it is unsed in case of memory allocation failures and things > like that). I agree. -- Saluti, Massimiliano Hofer Nucleus From kaber at trash.net Tue Jun 20 01:13:55 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 01:39:32 2006 Subject: [PATCH] entry_data In-Reply-To: <200606200035.07197.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <448FD0F6.3010506@anduras.de> <4496E037.2000706@trash.net> <200606200035.07197.max@nucleus.it> Message-ID: <44972FB3.5070603@trash.net> Massimiliano Hofer wrote: > On Monday 19 June 2006 7:34 pm, Patrick McHardy wrote: > > >>Yes, userspace ignores these fields. I still haven't really made up my >>mind about this patch yet. I don't like the void ** approach very much, > > > I understand your concerns, but it's either that or feeding it its own struct > xt_entry_match *. This would be awfully circular, while the practice of > passing someting * to functions is widespread. This only happens to be > applied to a void *. I guess I just like externally allocated storage better (and a .privsize field or something in the match structures). It avoids each match having to deal with memory allocation failures and more complicated cleanup code. Currently some matches store state in the structures shared with userspace and keep a pointer to the first per-CPU copy so there is only a single state on SMP, others allocate memory and keep a pointer in the shared struct, yet others keep global state and do lookups based on some identifier in the shared struct. The first two cases really just want some amount of memory that is shared between per-CPU data and are happy with externally allocated memory, the last one is usually used to share state between selected instances of matches or targets, which will always need to be handled internally. So I think we should introduce a .priv_size field or something in struct xt_match/xt_target and pass memory allocated by xtables to the matches and targets. From pablo at netfilter.org Tue Jun 20 01:37:13 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Jun 20 01:57:50 2006 Subject: [PATCH] entry_data In-Reply-To: <200606190902.09597.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606132256.10384.max@nucleus.it> <4495EC8E.6030006@netfilter.org> <200606190902.09597.max@nucleus.it> Message-ID: <44973529.50600@netfilter.org> Massimiliano Hofer wrote: > >> /* Used inside the kernel */ >> struct xt_match *match; >>+ void *entry_data; >> } kernel; >> >>You can't modify the layout of xt_entry_[match|target] since this >>structure is shared between userspace (iptables) and kernel space. > > > You're right, but I modified the kernel side of a union and I was careful not > to change the total size. This union is never really used by both sides > simultaneously. Indeed, you're right, I can't see any problem with your patch at this moment. Although apart from the out of tree xt_condition match, there is no other clients for entry_data. I'd like to know what Patrick thinks about this. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From kernel at linuxace.com Tue Jun 20 03:22:08 2006 From: kernel at linuxace.com (Phil Oester) Date: Tue Jun 20 03:46:47 2006 Subject: [PATCH] REDIRECT does not accept IP Message-ID: <20060620012208.GA17152@linuxace.com> As pointed out by Nicolas Mailhot in bugzilla #483, REDIRECT does not accept an IP address and when supplied with one, provides unexpected results. Patch below fixes this. Phil -------------- next part -------------- diff -ruN ipt-orig/extensions/libipt_REDIRECT.c ipt-new/extensions/libipt_REDIRECT.c --- ipt-orig/extensions/libipt_REDIRECT.c 2005-07-21 23:39:45.000000000 -0700 +++ ipt-new/extensions/libipt_REDIRECT.c 2006-06-19 18:14:37.000000000 -0700 @@ -44,6 +44,9 @@ mr->range[0].flags |= IP_NAT_RANGE_PROTO_SPECIFIED; + if (strchr(arg, '.')) + exit_error(PARAMETER_PROBLEM, "IP address not permitted\n"); + port = atoi(arg); if (port == 0 || port > 65535) exit_error(PARAMETER_PROBLEM, "Port `%s' not valid\n", arg); From kaber at trash.net Tue Jun 20 03:29:21 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 03:54:51 2006 Subject: [PATCH] entry_data In-Reply-To: <200606200105.04286.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606180055.25350.max@nucleus.it> <4496E2B2.6010209@trash.net> <200606200105.04286.max@nucleus.it> Message-ID: <44974F71.3050209@trash.net> Massimiliano Hofer wrote: > On Monday 19 June 2006 7:45 pm, Patrick McHardy wrote: > > >>>This leads me to a more radical proposal. Is there any reason we don't >>>have a general way to negate matches? It wouldn't be too difficult and we > > [...] > >>It would be useful for some matches (basically those that only check >>a single attribute), others may want to combine negated matching >>on some attributes with non-negated matching on others. In these > > > I agree with you. > Let's suppose we want to implement this feature and we don't want to cause > major breakage. I can't find a suitable bit in xt_entry_match, but we could > define a "wrapper match". We could set u.name to "!" or something similar and > data to: > > struct { > int invert; > struct xt_entry_match nested_xt_entry_match; > }; > > Similar wrappers would effectively transform a simple linear data structure in > a tree, so I don't think this is a thing we should endorse lighly. I'm not sure how much effort we should put into glueing a generic method around the matches, most already support proper negation and we can just add it for the few(?) remaining ones manually (and I don't accept new matches without proper negation support) and hope for everything to get better with pkttables :) From kaber at trash.net Tue Jun 20 03:39:08 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 04:04:31 2006 Subject: [PATCH] entry_data In-Reply-To: <44973529.50600@netfilter.org> References: <200606050029.08602.max@nucleus.it> <200606132256.10384.max@nucleus.it> <4495EC8E.6030006@netfilter.org> <200606190902.09597.max@nucleus.it> <44973529.50600@netfilter.org> Message-ID: <449751BC.6050808@trash.net> Pablo Neira Ayuso wrote: > Massimiliano Hofer wrote: > >> You're right, but I modified the kernel side of a union and I was >> careful not to change the total size. This union is never really used >> by both sides simultaneously. > > > Indeed, you're right, I can't see any problem with your patch at this > moment. Although apart from the out of tree xt_condition match, there is > no other clients for entry_data. I'd like to know what Patrick thinks > about this. Actually there are quite a few things that can benefit from this (see also my other mail to netfilter-devel). Stateful matches like limit, quota, statistic can store their state in externally allocated memory and remove all the state and the pointers from the structure shared with userspace. hashlimit, recent and other matches that lookup global state can just keep a reference to it without affecting userspace visible structures. Besides it is in my opinion a major limitation of the iptables API that it doesn't cleanly support per-instance state, so I'm quite supportive of this patch :) From kaber at trash.net Tue Jun 20 03:21:29 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 04:16:03 2006 Subject: [PATCH 1/2] Specify nf_queue max length from userspace In-Reply-To: <1150747030.6979.6.camel@porky> References: <1150217788.7164.4.camel@porky> <1150218404.5386.2.camel@porky> <4496D030.1010400@trash.net> <1150747030.6979.6.camel@porky> Message-ID: <44974D99.8000807@trash.net> Eric Leblond wrote: > I did not like the idea of having params split between two structures. > And as the user base is still small, I thought we may break ABI to have > something cleaner. > Pablo and you do not like the idea, I wrote a patch that should not > break the ABI (attached to the mail). > In fact, after introducing the new attribute, I just found it is in a > way cleaner than my initial one because code does not depend from a > structure. Yes, that is better. I still would prefer to have all configuration attributes nested under some common attribute .. but I can't see a clean way to do that right now. Let me think about this some more. From vasanthakumar at iitb.ac.in Tue Jun 20 07:26:29 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Tue Jun 20 07:51:55 2006 Subject: Packet Lost In-Reply-To: <4496FBBB.8090303@trash.net> References: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> <4496BADF.5000405@trash.net> <4921.10.12.25.5.1150745018.squirrel@gpo.iitb.ac.in> <4496FBBB.8090303@trash.net> Message-ID: <4873.10.107.26.27.1150781189.squirrel@gpo.iitb.ac.in> Hi, Actually I did verified my calculated checksum value with the checksum value present in the actual transmitted packet(using ethereal, kernel-2.6.11-6), and the values are same. Here is my checksum code, please let me if something is wrong. ********************** // To calculate the new check sum unsigned short ip_sum_calc(unsigned short *addr,int len) { int nleft = len; int sum = 0; unsigned short *w = addr; unsigned short answer = 0; while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(unsigned char *)(&answer) = *(unsigned char *) w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return answer; } *********************** > Vasantha Kumar Puttappa wrote: >>>IIRC some old versions accidentally fixed up broken checksums >>>they received from userspace and this is not done anymore. >>>Do your packets have correct checksums when sent from userspace >>>to the kernel? >>> >> >> ya my checksum calculation is correct. If my checksum is wrong, it would >> have been detected by tcpdump or ethereal(in 2.6.11-6). > > No it wouldn't have been, thats what I'm saying. Old ipq versions > silently fixed broken checksums. Depending on the hook you're queueing > packets at they might get dropped locally if the checksum is corrupt. > From vasanthakumar at iitb.ac.in Tue Jun 20 08:50:42 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Tue Jun 20 09:15:51 2006 Subject: TCP connection and interface down In-Reply-To: <4496FBBB.8090303@trash.net> References: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> <4496BADF.5000405@trash.net> <4921.10.12.25.5.1150745018.squirrel@gpo.iitb.ac.in> <4496FBBB.8090303@trash.net> Message-ID: <1535.10.107.26.27.1150786242.squirrel@gpo.iitb.ac.in> Hi, Suppose I have an active tcp connection(web browser) bounded to an interface X. Whenever this interface goes down, this will be notified by the kernel stack to the transport layer and the tcp application will stop sending packets till interface becomes active. My questions is that , is it possible to allow tcp applications to keep on sending packets even after interface goes down. So, that I can catch packets using IPtables and do whatever manipulation I would like to do. Also I have another interface to send these manipulated packets. Guide me, Thanx in advance. From kadlec at blackhole.kfki.hu Tue Jun 20 11:49:23 2006 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Tue Jun 20 12:13:58 2006 Subject: New to IPSets - Not working as expected In-Reply-To: <20060619053646.47093.qmail@web42203.mail.yahoo.com> References: <20060619053646.47093.qmail@web42203.mail.yahoo.com> Message-ID: On Sun, 18 Jun 2006, Manish Jain wrote: > I want to dump all packets coming from IP 192.168.1.18 > in syslog. For this, I have created following ipset > and iptable. But it is not working for me. Please > guide me. > > ipset -N test2 ipmap --from 192.168.1.1 --to > 192.168.255.255 > iptables -A INPUT -m set --set test2 src -j LOG You created an empty set without adding any element to it. Just add 192.168.1.18 to test2 and the iptables rule will match: ipset -A test2 192.168.1.18 Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From max at nucleus.it Tue Jun 20 12:57:14 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Tue Jun 20 13:22:09 2006 Subject: Mailing list slow? In-Reply-To: <4496C3D7.2040809@trash.net> References: <4496C3D7.2040809@trash.net> Message-ID: <200606201257.16272.max@nucleus.it> On Monday 19 June 2006 5:33 pm, Patrick McHardy wrote: > Is it just me or are other people also experiencing large > delays with mails to netfilter-devel? My mails are visible > on the lists.netfilter.org web interface but I receive them > with large delay .. Some of my messages took 24 hours to make it throu (after being delivered to vishnu.netfilter.org). On several occasions I had problem sending them in the first place. Here is one of my postfix logs: Jun 18 09:16:53 waobagger postfix/smtp[9876]: 685DC3D3353: to=, relay=vishnu.netfilter.org[213.95.27.115], delay=30082, status=deferred (host vishnu.netfilter.org[213.95.27.115] said: 451 Error while writing spool file (in reply to end of DATA command)) -- Saluti, Massimiliano Hofer From azez at ufomechanic.net Tue Jun 20 12:57:33 2006 From: azez at ufomechanic.net (Amin Azez) Date: Tue Jun 20 13:22:39 2006 Subject: Mailing list slow? In-Reply-To: <4496C3D7.2040809@trash.net> References: <4496C3D7.2040809@trash.net> Message-ID: <4497D49D.4010304@ufomechanic.net> Patrick McHardy wrote: > Is it just me or are other people also experiencing large > delays with mails to netfilter-devel? My mails are visible > on the lists.netfilter.org web interface but I receive them > with large delay .. I post via NNTP at news.gmane.org and a rate patch for ipt_account has taken 4 days to arrive. I've also seen less posts in the last few days than I would expect. Sam From max at nucleus.it Tue Jun 20 13:25:01 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Tue Jun 20 13:49:46 2006 Subject: [PATCH] entry_data In-Reply-To: <44972FB3.5070603@trash.net> References: <200606050029.08602.max@nucleus.it> <200606200035.07197.max@nucleus.it> <44972FB3.5070603@trash.net> Message-ID: <200606201325.02775.max@nucleus.it> On Tuesday 20 June 2006 1:13 am, Patrick McHardy wrote: > So I think we should introduce a .priv_size field or something in struct > xt_match/xt_target and pass memory allocated by xtables to the matches > and targets. I changed the API on the (possibly wrong) assumption that most modules will need it for shared data (that's what I and at least some other modules need), but thinking about it there are other uses (multiple data with different sharing, non shared data that has no business in the userspace struct, etc.). In other words, you're right. Following your suggestion I could add a .priv_size field and if it is non zero I allocate the requested memory and pass it as void * (the same type passed to (*checkentry)(), (*destroy)() and (*match)()). We have 2 ways to implement this: - we can allocate priv_size more bytes after data; - we can separately allocate priv_size bytes and store a pointer in u.kernel.entry_data. Seeing how the initialization code works, the first one is a bit hairy. The latter is really easy to implement, but if someone just needs 4 bytes we end up storing a pointer to a pointer with no good reason. -- Saluti, Massimiliano Hofer Nucleus From jorge.matias at motorola.com Mon Jun 19 17:58:48 2006 From: jorge.matias at motorola.com (Jorge Matias Martin) Date: Tue Jun 20 14:14:55 2006 Subject: [PATCH] xt_sctp - add SCTP header size to IP header offset In-Reply-To: <4496BA6A.3040308@trash.net> References: <200606081754.09073.jorge.matias@motorola.com> <4496BA6A.3040308@trash.net> Message-ID: <200606191758.48909.jorge.matias@motorola.com> On 19 June 2006 16:53, Patrick McHardy wrote: > Jorge Matias Martin wrote: > > Hi, all. > > > > xt_sctp module is not working on 2.6.16 when --chunk-types option is > > used. I have test this running sctp_darn and the following iptables > > options: > > > > -A INPUT -p sctp --chunk-types any INIT -j DROP > > > > And this is the kernel log output: > > > > spt: 32822 dpt: 10105 > > Chunk num: 1 offset: 20 type: 128 length: 10105 flags: 36 > > skb->len: 92 offset: 10128 > > spt: 10105 dpt: 32822 > > Chunk num: 1 offset: 20 type: 39 length: 32822 flags: 79 > > skb->len: 284 offset: 32844 > > spt: 32822 dpt: 10105 > > Chunk num: 1 offset: 20 type: 128 length: 10105 flags: 36 > > ... > > > > > > Note that length is actually the local port, and offset must be 32 (20 > > IPv4 header + 12 SCTP header). > > > > FYI, it works properly when --chunk-types is not used. > > Looks good too me. Please add a Signed-off-by: line so I can > apply it. Thanks. Signed-off-by: Jorge Matias ----------- --- linux-2.6.16.19/net/netfilter/xt_sctp.c.orig????????2006-05-31 02:31:44.000000000 +0200 +++ linux-2.6.16.19/net/netfilter/xt_sctp.c?????2006-06-08 17:32:53.000000000 +0200 @@ -152,7 +152,7 @@ match(const struct sk_buff *skb, ????????????????&& SCCHECK(((ntohs(sh->dest) >= info->dpts[0]) ????????????????????????&& (ntohs(sh->dest) <= info->dpts[1])), ????????????????????????XT_SCTP_DEST_PORTS, info->flags, info->invflags) -???????????????&& SCCHECK(match_packet(skb, protoff, +???????????????&& SCCHECK(match_packet(skb, protoff + sizeof (sctp_sctphdr_t), ????????????????????????????????????????info->chunkmap, info->chunk_match_type, ? ??????????????????????????????????????info->flag_info, info->flag_count, ????????????????????????????????????????hotdrop), From kaber at trash.net Tue Jun 20 14:38:32 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 15:03:16 2006 Subject: Mailing list slow? In-Reply-To: <4497D49D.4010304@ufomechanic.net> References: <4496C3D7.2040809@trash.net> <4497D49D.4010304@ufomechanic.net> Message-ID: <4497EC48.6010303@trash.net> Amin Azez wrote: > Patrick McHardy wrote: > >>Is it just me or are other people also experiencing large >>delays with mails to netfilter-devel? My mails are visible >>on the lists.netfilter.org web interface but I receive them >>with large delay .. > > > I post via NNTP at news.gmane.org and a rate patch for ipt_account has > taken 4 days to arrive. > > I've also seen less posts in the last few days than I would expect. Harald took care of it, apparantly the mails were stuck in the queue for some reason. From kaber at trash.net Tue Jun 20 15:17:21 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 15:42:02 2006 Subject: [PATCH] entry_data In-Reply-To: <200606201325.02775.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606200035.07197.max@nucleus.it> <44972FB3.5070603@trash.net> <200606201325.02775.max@nucleus.it> Message-ID: <4497F561.4000503@trash.net> Massimiliano Hofer wrote: > I changed the API on the (possibly wrong) assumption that most modules will > need it for shared data (that's what I and at least some other modules need), > but thinking about it there are other uses (multiple data with different > sharing, non shared data that has no business in the userspace struct, etc.). > In other words, you're right. > > Following your suggestion I could add a .priv_size field and if it is non zero > I allocate the requested memory and pass it as void * (the same type passed > to (*checkentry)(), (*destroy)() and (*match)()). > > We have 2 ways to implement this: > - we can allocate priv_size more bytes after data; > - we can separately allocate priv_size bytes and store a pointer in > u.kernel.entry_data. > > Seeing how the initialization code works, the first one is a bit hairy. The > latter is really easy to implement, but if someone just needs 4 bytes we end > up storing a pointer to a pointer with no good reason. The case of just needing a pointer is just an optimization for a special-case in my opinion (avoid lookup of globally shared state), per-instance state is probably more common. So I'd suggest to go with the second possibility. From kaber at trash.net Tue Jun 20 15:21:14 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 15:45:57 2006 Subject: [PATCH] REDIRECT does not accept IP In-Reply-To: <20060620012208.GA17152@linuxace.com> References: <20060620012208.GA17152@linuxace.com> Message-ID: <4497F64A.6020508@trash.net> Phil Oester wrote: > As pointed out by Nicolas Mailhot in bugzilla #483, REDIRECT > does not accept an IP address and when supplied with one, > provides unexpected results. Patch below fixes this. Applied, thanks Phil. From olenf at ans.pl Tue Jun 20 15:21:50 2006 From: olenf at ans.pl (Krzysztof Oledzki) Date: Tue Jun 20 15:46:33 2006 Subject: [CONNTRACKD]: Fix segfault Message-ID: Hello, Attached (trivial) patch fixes segfault in conntrackd caused by wrong "usage" calls. Best regards, Krzysztof Ol?dzki -------------- next part -------------- diff -Nur conntrackd-0.8.1-orig/src/main.c conntrackd-0.8.1/src/main.c --- conntrackd-0.8.1-orig/src/main.c 2006-06-20 14:04:06.000000000 +0200 +++ conntrackd-0.8.1/src/main.c 2006-06-20 14:06:14.000000000 +0200 @@ -111,7 +111,7 @@ config_set = 1; break; } - fprintf(stdout, usage, VERSION); + fprintf(stdout, usage, VERSION, argv[0]); fprintf(stdout, "Missing config filename\n"); break; case 'F': @@ -136,7 +136,7 @@ set_operation_mode(&mode, STATS_MODE, argv); break; default: - fprintf(stdout, usage, VERSION); + fprintf(stdout, usage, VERSION, argv[0]); fprintf(stdout, "Unknown option: %s\n", argv[i]); return 0; break; From kaber at trash.net Tue Jun 20 15:23:23 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 15:48:05 2006 Subject: checking rule specifications in a match In-Reply-To: <44966994.6020402@gmail.com> References: <44966994.6020402@gmail.com> Message-ID: <4497F6CB.4030600@trash.net> Bj?rn Lindstr?m wrote: > Hi. > I am writing an iptables match to match the IEC-60870-5-104 protocol. > I only want this match to be used on tcp packets and therefore I want > iptables to reject rules if does not specify tcp as the protocol (-p > tcp). I am currently doing this check in the checkentry function in the > kernel module. This works but the error message only say "iptables: > Unknown error 4294967295" if -p tcp is left out. Is it possible to do > this check any other way to get a more comprehensible error message? This is probably because you're using a broken version of iptables userspace. Current kernels allow you to enforce a specific protocol by setting the .proto field in struct xt_match, which will also handle inversion correctly and logs a message to the ringbuffer on error. From kaber at trash.net Tue Jun 20 15:49:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 16:13:51 2006 Subject: [PATCH] ipt_account rate patch In-Reply-To: References: Message-ID: <4497FCD6.2000706@trash.net> Amin Azez wrote: > Here are some patches I did for ipt_account before ipt_ACCOUNT which > supports larger subnets was re-released. > > As well as per-ip packet and byte counting, the patches also does per-ip > rate calculating, so you can use this as part of a rate limiting rule > and drop packets that would exceed the rate. > > You get to choose whether or not dropped packets should also be accounted. > > Just as ipt_account supports total-subnet accounting, so we also support > total-subnet rate calculations as well. > > The rate calculations are an improved version of what is in > ip_conntrack_rate.c, namely we can handle the timer wraps around zero. How do you want me to handle this? The account patch is no longer in pom, the extension is still part of iptables. Do you want me to apply the iptables part or do you simply want to add it as an iptables.patch to the account repository? From kaber at trash.net Tue Jun 20 15:51:55 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 16:16:36 2006 Subject: Packet Lost In-Reply-To: <4873.10.107.26.27.1150781189.squirrel@gpo.iitb.ac.in> References: <58963.10.107.26.27.1149788221.squirrel@gpo.iitb.ac.in> <4496BADF.5000405@trash.net> <4921.10.12.25.5.1150745018.squirrel@gpo.iitb.ac.in> <4496FBBB.8090303@trash.net> <4873.10.107.26.27.1150781189.squirrel@gpo.iitb.ac.in> Message-ID: <4497FD7B.6080008@trash.net> Vasantha Kumar Puttappa wrote: > Hi, > Actually I did verified my calculated checksum value with the checksum > value present in the actual transmitted packet(using ethereal, > kernel-2.6.11-6), and the values are same. OK. Then please describe what you're doing in more detail (at what hook are you queueing, what are you doing to the packet, what is the last spot you can see the packet, ...). Try to add some LOG rules to see if the packet really is dropped by ip_queue or later in the stack. From kaber at trash.net Tue Jun 20 15:55:03 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 16:19:48 2006 Subject: [nfqueue] libnetfilter_queue python wrapper In-Reply-To: <20060607180531.09652ae1@ganymede> References: <20060607180531.09652ae1@ganymede> Message-ID: <4497FE37.9010706@trash.net> Mathieu Geli wrote: > Hi, > > If anyone is interested I adapted Neale Pickett's ipqueue code for the > libnfnetlink/libnetfilter_queue API. That's called nfqueue. I know the > code is far from perfect and will be glad to receive comments. > > You can download it here [1]. I recommend using scapy [2] and > uncommenting the specific lines in the test file. Please just post it to the list, most developers (including me) tend to ignore things that require downloading and unpacking tars. From kaber at trash.net Tue Jun 20 15:57:53 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Jun 20 16:22:34 2006 Subject: [PATCH] modify the nf-hipac-0.9.1.patch to apply it to the kernel 2.6.16.16 In-Reply-To: <447A8B18.2090509@kernelproject.org> References: <447A8B18.2090509@kernelproject.org> Message-ID: <4497FEE1.2050300@trash.net> Jeho-Park wrote: > > nf-hipac-0.9.1 was made to apply it to the kernel 2.6.13, so it need > some modification > here is my patched nf-hipac 0.9.1 patch. some small bit was changed > > http://www.kernelproject.org/people/jhpark/nf-hipac-0.9.1-to-linux-2.6.16.16.patch I guess you should send this to Michael Bellion , I think he doesn't follow netfilter-devel that closely (and the hipac announce list is probably read-only). From m at rtij.nl Tue Jun 20 23:26:06 2006 From: m at rtij.nl (Martijn Lievaart) Date: Tue Jun 20 23:50:59 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <4496C9CD.8070701@trash.net> References: <448051F3.1070509@trash.net> <1149267610.3021.11.camel@localhost.localdomain> <448072FC.3060902@trash.net> <44809B1C.2010907@gmx.net> <4487CEA8.8060701@trash.net> <44888CD7.8090601@rtij.nl> <4496C9CD.8070701@trash.net> Message-ID: <449867EE.5080808@rtij.nl> Patrick McHardy wrote: >Martijn Lievaart wrote: > > >>Patrick McHardy wrote: >> >> >> >>Something I've been thinking about. Currently it is impossible to write >>any kind of generic tool that uses the mark and plays nice with other >>generic tools. Maybe we need some kind of API that allocates bits in the >>mark. Something like "give me two bits", that returns some handle to the >>bits. That handle could then be used for identifying the bits in the mark. >> >> > >It can see that it would be useful for complex setups, but I can't think >of an efficient implementation of this. You would have to carry a table >of handle identifiers -> mark ranges with every packet, wouldn't you? > > No, no! Just an API (which doesn't need to be coupled to iptables kernel part at all) where one can "reserve" some bits in the nfmark. That handle would refer to the same bit(s) everywhere, but you don't need to know which bits in the mark you are exactly using. So this implies ANDing as well. Something along these lines (error handling simplified): # reserve 1 bit MYMARK=`iptables-mark --reserve mybits:1` # This would return some 'handle' (most probably the offset in the mark, prefixed with something) # Use MYMARK to set just one bit in the mark iptables -A ..... -j MARK --set $MYMARK M4 From kaber at trash.net Tue Jun 20 23:44:18 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Jun 21 00:09:10 2006 Subject: Bridge netfilter defered hooks In-Reply-To: <449867EE.5080808@rtij.nl> References: <448051F3.1070509@trash.net> <1149267610.3021.11.camel@localhost.localdomain> <448072FC.3060902@trash.net> <44809B1C.2010907@gmx.net> <4487CEA8.8060701@trash.net> <44888CD7.8090601@rtij.nl> <4496C9CD.8070701@trash.net> <449867EE.5080808@rtij.nl> Message-ID: <44986C32.60105@trash.net> Martijn Lievaart wrote: > Patrick McHardy wrote: > >> It can see that it would be useful for complex setups, but I can't think >> of an efficient implementation of this. You would have to carry a table >> of handle identifiers -> mark ranges with every packet, wouldn't you? >> >> > > No, no! Just an API (which doesn't need to be coupled to iptables kernel > part at all) where one can "reserve" some bits in the nfmark. That > handle would refer to the same bit(s) everywhere, but you don't need to > know which bits in the mark you are exactly using. So this implies > ANDing as well. Something along these lines (error handling simplified): > > # reserve 1 bit > MYMARK=`iptables-mark --reserve mybits:1` > # This would return some 'handle' (most probably the offset in the mark, > prefixed with something) > > # Use MYMARK to set just one bit in the mark > iptables -A ..... -j MARK --set $MYMARK It seems I misunderstood you, I thought you were talking about dynamic reservations :) Sure, something like /etc/iproute/rt_realms would make life easier for users. But it doesn't really solve the problem that its sometimes really hard to get along with 32 bits. From max at nucleus.it Wed Jun 21 02:03:30 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Wed Jun 21 02:28:30 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <4497F561.4000503@trash.net> References: <200606050029.08602.max@nucleus.it> <200606201325.02775.max@nucleus.it> <4497F561.4000503@trash.net> Message-ID: <200606210203.33209.max@nucleus.it> On Tuesday 20 June 2006 3:17 pm, Patrick McHardy wrote: > The case of just needing a pointer is just an optimization for a > special-case in my opinion (avoid lookup of globally shared state), > per-instance state is probably more common. So I'd suggest to go > with the second possibility. Is this better? I'll send an example of its use in a few minutes. -- Saluti, Massimiliano Hofer -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.6.17.1-priv_data_core.patch Type: text/x-diff Size: 5290 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060621/e32c2a63/2.6.17.1-priv_data_core-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.6.17.1-priv_data_matches.patch Type: text/x-diff Size: 35699 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060621/e32c2a63/2.6.17.1-priv_data_matches-0001.bin From kaber at trash.net Wed Jun 21 02:30:25 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Jun 21 02:55:23 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <200606210203.33209.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606201325.02775.max@nucleus.it> <4497F561.4000503@trash.net> <200606210203.33209.max@nucleus.it> Message-ID: <44989321.2000106@trash.net> Massimiliano Hofer wrote: > On Tuesday 20 June 2006 3:17 pm, Patrick McHardy wrote: > > >>The case of just needing a pointer is just an optimization for a >>special-case in my opinion (avoid lookup of globally shared state), >>per-instance state is probably more common. So I'd suggest to go >>with the second possibility. > > > Is this better? > I'll send an example of its use in a few minutes. Very nice, thanks. > diff -Nru linux-2.6.17.1/net/ipv4/netfilter/ip_tables.c linux-2.6.17.1-priv_data_core/net/ipv4/netfilter/ip_tables.c > --- linux-2.6.17.1/net/ipv4/netfilter/ip_tables.c 2006-06-20 11:31:55.000000000 +0200 > +++ linux-2.6.17.1-priv_data_core/net/ipv4/netfilter/ip_tables.c 2006-06-21 00:49:12.000000000 +0200 > @@ -519,10 +522,20 @@ > if (ret) > goto err; > > + if (match->priv_size) { > + m->u.kernel.priv_data = kzalloc(match->priv_size, > + GFP_KERNEL); > + if (!m->u.kernel.priv_data) { > + ret = -ENOMEM; > + goto err; > + } > + } > + I think this should be done somewhere in x_tables. I think I would rename xt_check_match to xt_init_match, put the allocation there and finally rename ->checkentry to ->init .. the name doesn't really fit anymore since people started doing real initialization in there, and changing prototypes is a good opportunity for fixing that. From max at nucleus.it Wed Jun 21 02:33:53 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Wed Jun 21 02:59:03 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <200606210203.33209.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <4497F561.4000503@trash.net> <200606210203.33209.max@nucleus.it> Message-ID: <200606210233.55724.max@nucleus.it> Hi, this is an example of how condition works with priv_data. This is a patch against the new version of condition for kernel version 2.6.17 (available on the repository). -- Saluti, Massimiliano Hofer -------------- next part -------------- A non-text attachment was scrubbed... Name: condition-priv_data.patch Type: text/x-diff Size: 3948 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060621/61fe6b3e/condition-priv_data.bin From philipc at snapgear.com Wed Jun 21 02:42:20 2006 From: philipc at snapgear.com (Philip Craig) Date: Wed Jun 21 03:07:13 2006 Subject: [RFC][1/2] New netfilter match module : kernel patch In-Reply-To: <4496C505.9080907@trash.net> References: <20060602190238.92524.qmail@web50208.mail.yahoo.com> <4496C505.9080907@trash.net> Message-ID: <449895EC.5060603@snapgear.com> On 06/20/2006 01:38 AM, Patrick McHardy wrote: > Alex Davis wrote: >> This is an update the kernel netfilter patch that allows >> matching the source or destination address of an IP >> packet to a network interface. > > I can't see any other way to do this, but I'm not so thrilled to > add a whole new match just for this. My current solution for this is to reinstall the iptables rules from the dhcp client script hooks, or from the ppp ip-up script. Another option that doesn't require reinstalling rules would be to use an ipset in the rule, and then use the scripts to update the address in the ipset. From max at nucleus.it Wed Jun 21 02:42:26 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Wed Jun 21 03:07:19 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <200606210233.55724.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606210203.33209.max@nucleus.it> <200606210233.55724.max@nucleus.it> Message-ID: <200606210242.27657.max@nucleus.it> On Wednesday 21 June 2006 2:33 am, Massimiliano Hofer wrote: > This is a patch against the new version of condition for kernel version > 2.6.17 (available on the repository). Ops. I mixed 2 versions. Disregard my previous message. This is the real diff. -- Saluti, Massimiliano Hofer -------------- next part -------------- A non-text attachment was scrubbed... Name: condition-priv_data.patch Type: text/x-diff Size: 3874 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060621/4111dbce/condition-priv_data.bin From max at nucleus.it Wed Jun 21 02:45:25 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Wed Jun 21 03:10:14 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <44989321.2000106@trash.net> References: <200606050029.08602.max@nucleus.it> <200606210203.33209.max@nucleus.it> <44989321.2000106@trash.net> Message-ID: <200606210245.26564.max@nucleus.it> On Wednesday 21 June 2006 2:30 am, Patrick McHardy wrote: > I think this should be done somewhere in x_tables. I think I would > rename xt_check_match to xt_init_match, put the allocation there > and finally rename ->checkentry to ->init .. the name doesn't really > fit anymore since people started doing real initialization in there, > and changing prototypes is a good opportunity for fixing that. I was wandering why it was duplicated between IPv4 and IPv6. Are these changes planned for 2.6.18? -- Saluti, Massimiliano Hofer From kaber at trash.net Wed Jun 21 03:04:38 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Jun 21 03:30:14 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <200606210245.26564.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606210203.33209.max@nucleus.it> <44989321.2000106@trash.net> <200606210245.26564.max@nucleus.it> Message-ID: <44989B26.8070704@trash.net> Massimiliano Hofer wrote: > On Wednesday 21 June 2006 2:30 am, Patrick McHardy wrote: > > >>I think this should be done somewhere in x_tables. I think I would >>rename xt_check_match to xt_init_match, put the allocation there >>and finally rename ->checkentry to ->init .. the name doesn't really >>fit anymore since people started doing real initialization in there, >>and changing prototypes is a good opportunity for fixing that. > > > I was wandering why it was duplicated between IPv4 and IPv6. Do you mean the check_match functions and the ->checkentry calls? The only reason is because they use a different type for the "ip" argument. > Are these changes planned for 2.6.18? I was hoping you could do it while you're changing this stuff .. I'd like to avoid touching all >30 files twice for a related change. From alex14641 at yahoo.com Wed Jun 21 05:44:00 2006 From: alex14641 at yahoo.com (Alex Davis) Date: Wed Jun 21 06:08:46 2006 Subject: [RFC][1/2] New netfilter match module : kernel patch In-Reply-To: <449895EC.5060603@snapgear.com> Message-ID: <20060621034400.20413.qmail@web50207.mail.yahoo.com> --- Philip Craig wrote: > On 06/20/2006 01:38 AM, Patrick McHardy wrote: > > Alex Davis wrote: > >> This is an update the kernel netfilter patch that allows > >> matching the source or destination address of an IP > >> packet to a network interface. > > > > I can't see any other way to do this, but I'm not so thrilled to > > add a whole new match just for this. > > My current solution for this is to reinstall the iptables > rules from the dhcp client script hooks, or from the ppp > ip-up script. > I had thought about that, but I think this new match is a cleaner way to accomplish it. > Another option that doesn't require reinstalling rules would > be to use an ipset in the rule, and then use the scripts to > update the address in the ipset. Hadn't thought about that, but still..... I code, therefore I am __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From max at nucleus.it Wed Jun 21 10:31:50 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Wed Jun 21 10:56:41 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <44989B26.8070704@trash.net> References: <200606050029.08602.max@nucleus.it> <200606210245.26564.max@nucleus.it> <44989B26.8070704@trash.net> Message-ID: <200606211031.51291.max@nucleus.it> On Wednesday 21 June 2006 3:04 am, Patrick McHardy wrote: > >>I think this should be done somewhere in x_tables. I think I would > >>rename xt_check_match to xt_init_match, put the allocation there > >>and finally rename ->checkentry to ->init .. the name doesn't really > >>fit anymore since people started doing real initialization in there, > >>and changing prototypes is a good opportunity for fixing that. > > > > I was wandering why it was duplicated between IPv4 and IPv6. > > Do you mean the check_match functions and the ->checkentry calls? > The only reason is because they use a different type for the "ip" > argument. No, I noticed several functions in ip_tables.c and ip6_tables.c that differentiate only by having struct ipt_entry_match * instead of struct ip6t_entry_match *, while they're both defines to xt_entry_match (the same goes for xt_entry_target). I've not checked it throu yet, but I think that most of them could be moved to x_tables.c. > > Are these changes planned for 2.6.18? > > I was hoping you could do it while you're changing this stuff .. > I'd like to avoid touching all >30 files twice for a related > change. OK, I didn't know if someone else was already at work. I can't do it today, though. I hope I'll start working on it tomorrow. -- Saluti, Massimiliano Hofer Nucleus From azez at ufomechanic.net Wed Jun 21 11:16:53 2006 From: azez at ufomechanic.net (Amin Azez) Date: Wed Jun 21 11:41:51 2006 Subject: [PATCH] ipt_account rate patch In-Reply-To: <4497FCD6.2000706@trash.net> References: <4497FCD6.2000706@trash.net> Message-ID: <44990E85.4080308@ufomechanic.net> Patrick McHardy wrote: > Amin Azez wrote: > >> Here are some patches I did for ipt_account before ipt_ACCOUNT which >> supports larger subnets was re-released. >> >> As well as per-ip packet and byte counting, the patches also does per-ip >> rate calculating, so you can use this as part of a rate limiting rule >> and drop packets that would exceed the rate. >> >> You get to choose whether or not dropped packets should also be accounted. >> >> Just as ipt_account supports total-subnet accounting, so we also support >> total-subnet rate calculations as well. >> >> The rate calculations are an improved version of what is in >> ip_conntrack_rate.c, namely we can handle the timer wraps around zero. >> > > How do you want me to handle this? The account patch is no longer in > pom, the extension is still part of iptables. oh. Was there a strong reason for it being dropped? I see that most of the patchlets have gone from: http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/patchlets/ including the newer ipt_ACCOUNT > Do you want me to apply > the iptables part or do you simply want to add it as an iptables.patch > to the account repository? > It won't make sense to do either until I can work out where the kernel side bit needs stashing. Did I miss something about pom-ng cleanup? Sam From vasanthakumar at iitb.ac.in Wed Jun 21 11:18:35 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Wed Jun 21 11:43:49 2006 Subject: Virutal Network Interface Message-ID: <1424.10.107.26.27.1150881515.squirrel@gpo.iitb.ac.in> Hi, I am working on a small application involving IPtables . But now I have to make use of this virtual interface driver (insane) for my application(http://www.linux.it/~rubini/docs/vinter/insane.tar.gz). I tried compiling it on kernel-2.6.11-6. but I got the following errors. I am new to kernel programming and require your help to solve this compile time errors. This has been successfully tested under kernel-2.3 Please give me your valuable suggestion. Thanx **************ERROR*********************************8 cc -MM *.c > .depend In file included from /usr/include/linux/sched.h:14, from /usr/include/linux/module.h:9, from insane.c:29: /usr/include/linux/cpumask.h:238:5: error: missing binary operator before token "(" /usr/include/linux/cpumask.h:297:5: error: missing binary operator before token "(" /usr/include/linux/cpumask.h:366:5: error: missing binary operator before token "(" In file included from /usr/include/linux/module.h:22, from insane.c:29: /usr/include/asm/module.h:60:2: error: #error unknown processor family insane.c:32:45: error: linux/malloc.h: No such file or directory insane.c:37:50: error: net/arp.h: No such file or directory make: *** [depend] Error 1 ********************************** From azez at ufomechanic.net Wed Jun 21 18:24:47 2006 From: azez at ufomechanic.net (Amin Azez) Date: Wed Jun 21 18:50:00 2006 Subject: [RFC,PATCH] introduce new API for libnfnetlink In-Reply-To: <4495E142.5000209@netfilter.org> References: <4495E142.5000209@netfilter.org> Message-ID: <449972CF.6060402@ufomechanic.net> Pablo Neira Ayuso wrote: > Hi! > > I have been spending some time on libnfnetlink these days based on a > previous patch that I sent some time ago [1]. Since the amount of > changes would result in API breakages, that is something that I consider > that we don't want, I decided to start some kind of version 2 of > libnfnetlink, the major changes from the current version is: > > - Uniform error handling via errno > - Use of new netlink ADD_MEMBERSHIP socket option to join multicast groups > - A new approach for challenge functions listen/talk, now they use the > callbacks registered via register_callback() > - Single loop processing: nfnetlink_process() > - Iterators: more control for the programmer in the nfnetlink data > processing > - addattr* simplification > - Documentation available > > The patch is available at: > > http://people.netfilter.org/pablo/libnfnetlink-newapi.patch Thanks for this Pablo. As long as there is still a way to exit the message reading loop at the end of the current packet (without discarding any messages), then it will suit me. I'm using the old conntrack API by receiving events and periodic dumps of all conntracks over the same netlink. At certain times a signal goes off which sets a flag to exit the read loop after the current netlink packet, then a conntrack dump is requested and the readloop is re-entered. I suppose this will still be possible? Sam From pneira at us.es Wed Jun 21 23:49:05 2006 From: pneira at us.es (pneira@us.es) Date: Thu Jun 22 00:07:45 2006 Subject: [CONNTRACKD]: Fix segfault In-Reply-To: References: Message-ID: ----- Mensaje original ----- De: Krzysztof Oledzki Fecha: Martes, Junio 20, 2006 3:40 pm Asunto: [CONNTRACKD]: Fix segfault A: Pablo Neira Ayuso CC: netfilter-devel@lists.netfilter.org > Hello, > > Attached (trivial) patch fixes segfault in conntrackd caused by > wrong > "usage" calls. Thanks, I'm going to include it in 0.8.2 that will be released soon. From max at nucleus.it Thu Jun 22 01:50:20 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Thu Jun 22 02:15:26 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <44989321.2000106@trash.net> References: <200606050029.08602.max@nucleus.it> <200606210203.33209.max@nucleus.it> <44989321.2000106@trash.net> Message-ID: <200606220150.23537.max@nucleus.it> On Wednesday 21 June 2006 2:30 am, Patrick McHardy wrote: > and finally rename ->checkentry to ->init .. the name doesn't really What about struct xt_target? It has the same general structure, but I've not touched it yet. It would be coherent to change it too, but I'd break compatibility with external targets for no real gain. Would any target benefit from having priv_data? -- Saluti, Massimiliano Hofer Nucleus From mohammadfarooq at tango-networks.com Tue Jun 20 18:28:39 2006 From: mohammadfarooq at tango-networks.com (Mohammad Farooq) Date: Thu Jun 22 14:18:57 2006 Subject: From where can I get libipq? In-Reply-To: 4496D030.1010400@trash.net Message-ID: <1150820919.29962.54.camel@mfarooq-1.tango-networks.com> Hi Eric, I am trying to build an application which filters RTP packets. I am planing to use iptables QUEUE to implement this application. I am running RedHat enterprise linux WS version 4 on a 64bit hardware. The rpc shows me iptables-1.2.11-3.1.RHEL4. But I couldn't find libipq. Could you please kindly tell me where to find libipq? I would really appreciate your help. Thanks. Mohammad From kaber at trash.net Thu Jun 22 17:18:36 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Jun 22 17:44:03 2006 Subject: [PATCH] priv_data (formerly entry_data) In-Reply-To: <200606220150.23537.max@nucleus.it> References: <200606050029.08602.max@nucleus.it> <200606210203.33209.max@nucleus.it> <44989321.2000106@trash.net> <200606220150.23537.max@nucleus.it> Message-ID: <449AB4CC.6030804@trash.net> Massimiliano Hofer wrote: > What about struct xt_target? > It has the same general structure, but I've not touched it yet. > It would be coherent to change it too, but I'd break compatibility with > external targets for no real gain. > Would any target benefit from having priv_data? I think the CLUSTERIP target would. I think we should keep the interfaces in sync, we've changed it twice during the last two kernel versions, so I don't really see external stuff as a problem. From eric at inl.fr Thu Jun 22 20:25:57 2006 From: eric at inl.fr (Eric Leblond) Date: Thu Jun 22 20:50:53 2006 Subject: From where can I get libipq? In-Reply-To: <1150820919.29962.54.camel@mfarooq-1.tango-networks.com> References: <1150820919.29962.54.camel@mfarooq-1.tango-networks.com> Message-ID: <1151000757.7942.5.camel@porky> Hi Mohammad On Tue, 2006-06-20 at 11:28 -0500, Mohammad Farooq wrote: > Hi Eric, > > I am trying to build an application which filters RTP packets. I am > planing to use iptables QUEUE to implement this application. I am > running RedHat enterprise linux WS version 4 on a 64bit hardware. The > rpc shows me iptables-1.2.11-3.1.RHEL4. But I couldn't find libipq. > Could you please kindly tell me where to find libipq? libipq is a bad choice on 64bits system. It has some design problem and you shoulod try to use libnetfilter_queue. Nethertheless you should find libipq.a in the iptables devel packet. BR, -- Eric Leblond INL -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060622/312a3c5e/attachment.pgp From wert at metreos.com Fri Jun 23 02:01:53 2006 From: wert at metreos.com (scott comer) Date: Fri Jun 23 02:26:43 2006 Subject: extra space in packet for iptables mangle table extension Message-ID: <772C6A8C-06CE-44E2-B082-0F1787B4093E@metreos.com> we are developing a mangle table extension which adds a bit of info to the end of a udp packet. when our extension gets a packet, sometimes there is enough extra space in the buffer to add what we want, but sometimes there isn't. in the latter case we have to allocate a new buffer with enough extra room and copy the data. is there any way to request a certain minimum amount of extra space in the buffers? thanks, scott From t.luettgert at pressestimmen.de Fri Jun 23 22:58:31 2006 From: t.luettgert at pressestimmen.de (Torsten Luettgert) Date: Fri Jun 23 23:21:33 2006 Subject: concerning p-o-m fixes for 2.6.17 API change Message-ID: <1151096311.3421.10.camel@murdegern.hindenburgdamm.example> Hi list, I noticed the match/target API changed a bit in 2.6.17, so a bunch of code in patch-o-matic-ng needs updates. I fixed ipp2p, ROUTE, time, and u32 (it's quite trivial). I'd like to submit the patches (and thus work against the "bit-rot" we all hate). Problem is, they are quite clumsy - the correct way IMHO is to copy the latest kernel directory (normally linux-2.6/) to linux-2.6.17 and then fix that, so 2.6.16 and older kernels still work, too. So you can't see what is happening in the patches, they just create 99% identical copies of the old files. Patrick, I guess you're the one to ask - would you like those patches, and in what format? Regards, Torsten From t.luettgert at pressestimmen.de Fri Jun 23 23:14:38 2006 From: t.luettgert at pressestimmen.de (Torsten Luettgert) Date: Fri Jun 23 23:37:36 2006 Subject: set breaks in 2.6.17 Message-ID: <1151097278.3421.26.camel@murdegern.hindenburgdamm.example> Hi list, and especially Jozsef, your set match and SET target break because of API changes in 2.6.17. The fix is trivial (insert a bunch of "const struct xt_match/target *" parameters), but necessary. set will really break now, because a new param is inserted before params which are actually used. How do you want to handle it? I'd prefer to add a linux-2.6.17 dir in the patchlet and then fix both trees, so 2.6.16 will still work. Regards, Torsten From heavytull at hotmail.com Sat Jun 24 01:15:23 2006 From: heavytull at hotmail.com (Jethro Tull) Date: Sat Jun 24 01:40:35 2006 Subject: iptable compiled but errors returned Message-ID: I just compiled iptables by doing so: make KERNEL_DIR=/kernel/source but the returned message for all files compiled is as follows: cc -O2 -Wall -Wunused -I/usr/src/kernel/linux-2.6.17//include -Iinclude/ -DIPTABLES_VERSION=\"1.3.5-20060622\" -D_UNKNOWN_KERNEL_POINTER_SIZE -DIP6T_LIB_DIR=\"/usr/local/lib/iptables\" -c -o ip6tables.o ip6tables.c the "-D_UNKNOWN_KERNEL_POINTER_SIZE..." is it normal?? _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters From PCDiem at FoxValley.net Sat Jun 24 06:52:29 2006 From: PCDiem at FoxValley.net (Paul C. Diem) Date: Sat Jun 24 07:17:40 2006 Subject: [PATCH] libiptc.c blob parser Message-ID: We have about 30,000 mangle table rules in about 8,000 chains. iptc_init takes about 10 seconds just to load and parse the table. The problem is the second parse phase that iterates through every chain and every rule searching for the offset of the target for every jump rule. I've applied the following small patch that loads the offset of the chain entry into the comefrom field of the first rule ipt entry in each user-defined chain in the first pass. This comefrom field is then used in the second pass to easily locate the target chain. This minor change has reduced the load time of our mangle table to 1 second. Paul C. Diem PCDiem@FoxValley.net 309a310,314 > /*+PCD > * Modification to use the offset to the chain entry in the ipt > * entry comefrom field as loaded by iptcc_find_chain_by_offset. > */ > #if 0 319a325,329 > #else > STRUCT_ENTRY * e = ((STRUCT_ENTRY *)((char *)handle->entries->entrytable + offset)); > return (struct chain_head *)((char *)e + e->comefrom); > #endif > /*-PCD*/ 496a507,512 > /*+PCD > * Load the offset to the chain entry relative to the > * ipt entry into the ipt entry comefrom field. > */ > e->comefrom = (char *)h->chains.prev - (char *)e; > /*-PCD*/ From olenf at ans.pl Sat Jun 24 09:13:45 2006 From: olenf at ans.pl (Krzysztof Oledzki) Date: Sat Jun 24 09:38:55 2006 Subject: concerning p-o-m fixes for 2.6.17 API change In-Reply-To: <1151096311.3421.10.camel@murdegern.hindenburgdamm.example> References: <1151096311.3421.10.camel@murdegern.hindenburgdamm.example> Message-ID: On Fri, 23 Jun 2006, Torsten Luettgert wrote: > Hi list, > > I noticed the match/target API changed a bit in 2.6.17, > so a bunch of code in patch-o-matic-ng needs updates. > I fixed ipp2p, ROUTE, time, and u32 (it's quite trivial). > > I'd like to submit the patches (and thus work against the > "bit-rot" we all hate). Problem is, they are quite clumsy - > the correct way IMHO is to copy the latest kernel directory > (normally linux-2.6/) to linux-2.6.17 and then fix that, > so 2.6.16 and older kernels still work, too. So you can't > see what is happening in the patches, they just create 99% > identical copies of the old files. > > Patrick, I guess you're the one to ask - would you like > those patches, and in what format? As for time and ipp2p current pom-ng contains versions for 2.6.16 and 2.6.16.x (-stable) kernels. There is no need to keep patches for that kernels since anyone interesed in older kernels than 2.6.17 is able to take older pom-ng tarball. So, please send ipp2p and time (with CC to me) and patches that only corrects API in the "linux-2.6" directory . The same advise is probably correct for both ROUTE and u32 but I think Patrick should confirm this. Thanks. Best regards, Krzysztof Ol?dzki From hawk at diku.dk Sat Jun 24 14:06:33 2006 From: hawk at diku.dk (Jesper Dangaard Brouer) Date: Sat Jun 24 14:31:46 2006 Subject: [PATCH] libiptc.c blob parser In-Reply-To: References: Message-ID: Hi Paul To confirm, I have notized the same issus. I wrote to Harald but he has not responded yet. So, I guess I'll follow up on this one... Nice to hear the you have solved the issue. First of all, could you please produce a proper patch!? (diff -Nurp) So that we can see whats going on... Here is my post to Harald: ------- Sent: Mon 6/19/2006 16:14 Subject: Performance work on libiptc Hi Harald I hope you can help me out. I have a performance issue with iptables which I have tracked down to the libiptc parsing. I would like to solve it, but need some help with the data structures. There is a scalability/performance issue in libiptc.c, when parsing the ruleset blob. The problem lies in the "Second pass" (of func parse_table) where the userchain jump targets are fixed/corrected. The "Second pass" loop has a bad worstcase run time of O(C*R). For each rule "R" with a IPTCC_R_JUMP target, func iptcc_find_chain_by_offset searches through the chain list "C" (worstcase hitting the last one). In my real life production system I have R=4492 and C=2238, giving a worstcase loop of 10.053.096. Basically, we need to make "iptcc_find_chain_by_offset" smarter... do you have any proposals? ------ I simply tracked down the problem using gprof. gprof output: +----- Each sample counts as 0.000999001 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 77.99 0.20 0.20 4492 0.04 0.04 iptcc_find_chain_by_offset 20.46 0.25 0.05 2238 0.02 0.02 iptc_insert_chain 1.16 0.26 0.00 16218 0.00 0.00 cache_add_entry 0.39 0.26 0.00 1 1.00 258.74 parse_table 0.00 0.26 0.00 13982 0.00 0.00 iptcc_alloc_rule 0.00 0.26 0.00 2239 0.00 0.00 __iptcc_p_del_policy 0.00 0.26 0.00 2238 0.00 0.02 __iptcc_p_add_chain 0.00 0.26 0.00 2238 0.00 0.00 iptcc_alloc_chain_head 0.00 0.26 0.00 2238 0.00 0.00 iptcc_delete_rule 0.00 0.26 0.00 1 0.00 0.00 add_command 0.00 0.26 0.00 1 0.00 0.00 alloc_handle 0.00 0.26 0.00 1 0.00 0.00 clear_rule_matches 0.00 0.26 0.00 1 0.00 258.74 do_command 0.00 0.26 0.00 1 0.00 0.00 find_target 0.00 0.26 0.00 1 0.00 0.00 free_opts 0.00 0.26 0.00 1 0.00 0.00 generic_opt_check 0.00 0.26 0.00 1 0.00 0.00 iptc_create_chain 0.00 0.26 0.00 1 0.00 258.74 iptc_init 0.00 0.26 0.00 1 0.00 0.00 iptc_strerror 0.00 0.26 0.00 1 0.00 0.00 iptcc_find_label +----- Cheers, Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- On Fri, 23 Jun 2006, Paul C. Diem wrote: > We have about 30,000 mangle table rules in about 8,000 chains. iptc_init > takes about 10 seconds just to load and parse the table. The problem is the > second parse phase that iterates through every chain and every rule > searching for the offset of the target for every jump rule. > > I've applied the following small patch that loads the offset of the chain > entry into the comefrom field of the first rule ipt entry in each > user-defined chain in the first pass. This comefrom field is then used in > the second pass to easily locate the target chain. This minor change has > reduced the load time of our mangle table to 1 second. > > Paul C. Diem > PCDiem@FoxValley.net > > 309a310,314 >> /*+PCD >> * Modification to use the offset to the chain entry in the ipt >> * entry comefrom field as loaded by iptcc_find_chain_by_offset. >> */ >> #if 0 > 319a325,329 >> #else >> STRUCT_ENTRY * e = ((STRUCT_ENTRY *)((char *)handle->entries->entrytable > + offset)); >> return (struct chain_head *)((char *)e + e->comefrom); >> #endif >> /*-PCD*/ > 496a507,512 >> /*+PCD >> * Load the offset to the chain entry relative to the >> * ipt entry into the ipt entry comefrom field. >> */ >> e->comefrom = (char *)h->chains.prev - (char *)e; >> /*-PCD*/ > > From kaber at trash.net Sat Jun 24 14:26:17 2006 From: kaber at trash.net (Patrick McHardy) Date: Sat Jun 24 14:52:56 2006 Subject: concerning p-o-m fixes for 2.6.17 API change In-Reply-To: <1151096311.3421.10.camel@murdegern.hindenburgdamm.example> References: <1151096311.3421.10.camel@murdegern.hindenburgdamm.example> Message-ID: <449D2F69.5090909@trash.net> Torsten Luettgert wrote: > Hi list, > > I noticed the match/target API changed a bit in 2.6.17, > so a bunch of code in patch-o-matic-ng needs updates. > I fixed ipp2p, ROUTE, time, and u32 (it's quite trivial). > > I'd like to submit the patches (and thus work against the > "bit-rot" we all hate). Problem is, they are quite clumsy - > the correct way IMHO is to copy the latest kernel directory > (normally linux-2.6/) to linux-2.6.17 and then fix that, > so 2.6.16 and older kernels still work, too. So you can't > see what is happening in the patches, they just create 99% > identical copies of the old files. > > Patrick, I guess you're the one to ask - would you like > those patches, and in what format? Sure, just send them along as normal diffs. But please no new directories, we decided to keep only a single version of things in pomng that runs with the latest kernel. From t.luettgert at pressestimmen.de Sat Jun 24 15:51:05 2006 From: t.luettgert at pressestimmen.de (Torsten Luettgert) Date: Sat Jun 24 16:11:50 2006 Subject: [PATCH] 2.6.17 API changes for ROUTE, u32, set In-Reply-To: <449D2F69.5090909@trash.net> References: <1151096311.3421.10.camel@murdegern.hindenburgdamm.example> <449D2F69.5090909@trash.net> Message-ID: <1151157065.29998.26.camel@scaramouche.combox.de> On Sa, 2006-06-24 at 14:26 +0200, Patrick McHardy wrote: > Sure, just send them along as normal diffs. But please no new > directories, we decided to keep only a single version of things > in pomng that runs with the latest kernel. Here are the patches for ROUTE, u32, and set. Regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: ROUTE.patch Type: text/x-patch Size: 706 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060624/4422de7b/ROUTE.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: set.patch Type: text/x-patch Size: 2067 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060624/4422de7b/set.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: u32.patch Type: text/x-patch Size: 723 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060624/4422de7b/u32.bin From t.luettgert at pressestimmen.de Sat Jun 24 15:51:06 2006 From: t.luettgert at pressestimmen.de (Torsten Luettgert) Date: Sat Jun 24 16:11:51 2006 Subject: [PATCH] 2.6.17 API changes for ipp2p, time In-Reply-To: References: <1151096311.3421.10.camel@murdegern.hindenburgdamm.example> Message-ID: <1151157066.29998.28.camel@scaramouche.combox.de> On Sa, 2006-06-24 at 09:13 +0200, Krzysztof Oledzki wrote: > > So, please send ipp2p and time (with CC to me) > and patches that only corrects API in the "linux-2.6" directory . Ok, here you are... Regards, Torsten L?ttgert -------------- next part -------------- A non-text attachment was scrubbed... Name: ipp2p.patch Type: text/x-patch Size: 736 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060624/2b3147b7/ipp2p.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: time.patch Type: text/x-patch Size: 725 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060624/2b3147b7/time.bin From PCDiem at FoxValley.net Sat Jun 24 17:57:50 2006 From: PCDiem at FoxValley.net (Paul C. Diem) Date: Sat Jun 24 18:23:14 2006 Subject: [PATCH] libiptc.c blob parser In-Reply-To: Message-ID: Sorry, I'm not familiar yet with submitting patches. I had to create a second tree from the original tarball and build it in order to get diff output that didn't list a bunch of unrelated files. Here's the diff -Nurp output with the leading notices about changed images (ip6tables, iptables, iptables-restore, etc) removed: Paul C. Diem PCDiem@FoxValley.net diff -Nurp --exclude '*.o' --exclude '*.so' iptables-1.3.5/libiptc/libiptc.c iptables-1.3.5-new/libiptc/libiptc.c --- iptables-1.3.5/libiptc/libiptc.c 2006-01-30 02:43:09.000000000 -0600 +++ iptables-1.3.5-new/libiptc/libiptc.c 2006-06-23 20:37:53.000000000 -0500 @@ -307,6 +307,11 @@ static struct rule_head *iptcc_get_rule_ static struct chain_head * iptcc_find_chain_by_offset(TC_HANDLE_T handle, unsigned int offset) { +/*+PCD +* Modification to use the offset to the chain entry in the ipt +* entry comefrom field as loaded by iptcc_find_chain_by_offset. +*/ +#if 0 struct list_head *pos; if (list_empty(&handle->chains)) @@ -317,6 +322,11 @@ iptcc_find_chain_by_offset(TC_HANDLE_T h if (offset >= c->head_offset && offset <= c->foot_offset) return c; } +#else + STRUCT_ENTRY * e = ((STRUCT_ENTRY *)((char *)handle->entries->entrytable + offset)); + return (struct chain_head *)((char *)e + e->comefrom); +#endif +/*-PCD*/ return NULL; } @@ -494,6 +504,12 @@ new_rule: r->index = *num; r->offset = offset; memcpy(r->entry, e, e->next_offset); +/*+PCD +* Load the offset to the chain entry relative to the +* ipt entry into the ipt entry comefrom field. +*/ + e->comefrom = (char *)h->chains.prev - (char *)e; +/*-PCD*/ r->counter_map.maptype = COUNTER_MAP_NORMAL_MAP; r->counter_map.mappos = r->index; ---------------------------------------------------------------------------- ----------------------------------------- -----Original Message----- From: netfilter-devel-bounces@lists.netfilter.org [mailto:netfilter-devel-bounces@lists.netfilter.org]On Behalf Of Jesper Dangaard Brouer Sent: Saturday, June 24, 2006 7:07 AM To: Paul C. Diem Cc: netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] libiptc.c blob parser Hi Paul To confirm, I have notized the same issus. I wrote to Harald but he has not responded yet. So, I guess I'll follow up on this one... Nice to hear the you have solved the issue. First of all, could you please produce a proper patch!? (diff -Nurp) So that we can see whats going on... Here is my post to Harald: ------- Sent: Mon 6/19/2006 16:14 Subject: Performance work on libiptc Hi Harald I hope you can help me out. I have a performance issue with iptables which I have tracked down to the libiptc parsing. I would like to solve it, but need some help with the data structures. There is a scalability/performance issue in libiptc.c, when parsing the ruleset blob. The problem lies in the "Second pass" (of func parse_table) where the userchain jump targets are fixed/corrected. The "Second pass" loop has a bad worstcase run time of O(C*R). For each rule "R" with a IPTCC_R_JUMP target, func iptcc_find_chain_by_offset searches through the chain list "C" (worstcase hitting the last one). In my real life production system I have R=4492 and C=2238, giving a worstcase loop of 10.053.096. Basically, we need to make "iptcc_find_chain_by_offset" smarter... do you have any proposals? ------ I simply tracked down the problem using gprof. gprof output: +----- Each sample counts as 0.000999001 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 77.99 0.20 0.20 4492 0.04 0.04 iptcc_find_chain_by_offset 20.46 0.25 0.05 2238 0.02 0.02 iptc_insert_chain 1.16 0.26 0.00 16218 0.00 0.00 cache_add_entry 0.39 0.26 0.00 1 1.00 258.74 parse_table 0.00 0.26 0.00 13982 0.00 0.00 iptcc_alloc_rule 0.00 0.26 0.00 2239 0.00 0.00 __iptcc_p_del_policy 0.00 0.26 0.00 2238 0.00 0.02 __iptcc_p_add_chain 0.00 0.26 0.00 2238 0.00 0.00 iptcc_alloc_chain_head 0.00 0.26 0.00 2238 0.00 0.00 iptcc_delete_rule 0.00 0.26 0.00 1 0.00 0.00 add_command 0.00 0.26 0.00 1 0.00 0.00 alloc_handle 0.00 0.26 0.00 1 0.00 0.00 clear_rule_matches 0.00 0.26 0.00 1 0.00 258.74 do_command 0.00 0.26 0.00 1 0.00 0.00 find_target 0.00 0.26 0.00 1 0.00 0.00 free_opts 0.00 0.26 0.00 1 0.00 0.00 generic_opt_check 0.00 0.26 0.00 1 0.00 0.00 iptc_create_chain 0.00 0.26 0.00 1 0.00 258.74 iptc_init 0.00 0.26 0.00 1 0.00 0.00 iptc_strerror 0.00 0.26 0.00 1 0.00 0.00 iptcc_find_label +----- Cheers, Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- On Fri, 23 Jun 2006, Paul C. Diem wrote: > We have about 30,000 mangle table rules in about 8,000 chains. iptc_init > takes about 10 seconds just to load and parse the table. The problem is the > second parse phase that iterates through every chain and every rule > searching for the offset of the target for every jump rule. > > I've applied the following small patch that loads the offset of the chain > entry into the comefrom field of the first rule ipt entry in each > user-defined chain in the first pass. This comefrom field is then used in > the second pass to easily locate the target chain. This minor change has > reduced the load time of our mangle table to 1 second. > > Paul C. Diem > PCDiem@FoxValley.net > > 309a310,314 >> /*+PCD >> * Modification to use the offset to the chain entry in the ipt >> * entry comefrom field as loaded by iptcc_find_chain_by_offset. >> */ >> #if 0 > 319a325,329 >> #else >> STRUCT_ENTRY * e = ((STRUCT_ENTRY *)((char *)handle->entries->entrytable > + offset)); >> return (struct chain_head *)((char *)e + e->comefrom); >> #endif >> /*-PCD*/ > 496a507,512 >> /*+PCD >> * Load the offset to the chain entry relative to the >> * ipt entry into the ipt entry comefrom field. >> */ >> e->comefrom = (char *)h->chains.prev - (char *)e; >> /*-PCD*/ > > -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.3/374 - Release Date: 6/23/2006 From PCDiem at FoxValley.net Sat Jun 24 23:09:38 2006 From: PCDiem at FoxValley.net (Paul C. Diem) Date: Sat Jun 24 23:35:06 2006 Subject: [PATCH] libiptc.c blob parser In-Reply-To: Message-ID: The patch I posted earlier assumed that the rule's chain was the last one on the chain list and used the 32-bit comefrom field to hold the offset of the chain list entry. This improved patch uses the chain_iterator_cur handle field to more accurately get the chain, uses the counters field cast as a pointer to hold a pointer directly to the chain list entry and only bothers to load the pointer for the first rule in each chain (since that's the only one we need it in). Paul C. Diem PCDiem@FoxValley.net diff -Nurp --exclude '*.d' iptables-1.3.5-org/libiptc/libiptc.c iptables-1.3.5/libiptc/libiptc.c --- iptables-1.3.5-org/libiptc/libiptc.c 2006-01-30 02:43:09.000000000 -0600 +++ iptables-1.3.5/libiptc/libiptc.c 2006-06-24 15:59:28.000000000 -0500 @@ -307,6 +307,11 @@ static struct rule_head *iptcc_get_rule_ static struct chain_head * iptcc_find_chain_by_offset(TC_HANDLE_T handle, unsigned int offset) { +/*+PCD +* Modification to use the pointer to the chain entry in the ipt +* entry counters field as loaded by iptcc_find_chain_by_offset. +*/ +#if 0 struct list_head *pos; if (list_empty(&handle->chains)) @@ -317,6 +322,11 @@ iptcc_find_chain_by_offset(TC_HANDLE_T h if (offset >= c->head_offset && offset <= c->foot_offset) return c; } +#else + STRUCT_ENTRY * e = ((STRUCT_ENTRY *)((char *)handle->entries->entrytable + offset)); + return *(struct chain_head **)&e->counters; +#endif +/*-PCD*/ return NULL; } @@ -494,6 +504,16 @@ new_rule: r->index = *num; r->offset = offset; memcpy(r->entry, e, e->next_offset); +/*+PCD +* Load a pointer to the chain entry into the ipt entry +* counters field for use by iptcc_find_chain_by_offset +* in the second pass. +*/ + if (h->chain_iterator_cur->num_rules == 0) { + struct chain_head ** chain_head_ptr_ptr = (struct chain_head **)&e->counters; + *chain_head_ptr_ptr = h->chain_iterator_cur; + } +/*-PCD*/ r->counter_map.maptype = COUNTER_MAP_NORMAL_MAP; r->counter_map.mappos = r->index; ---------------------------------------------------------------------------- ---- -----Original Message----- From: netfilter-devel-bounces@lists.netfilter.org [mailto:netfilter-devel-bounces@lists.netfilter.org]On Behalf Of Jesper Dangaard Brouer Sent: Saturday, June 24, 2006 7:07 AM To: Paul C. Diem Cc: netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] libiptc.c blob parser Hi Paul To confirm, I have notized the same issus. I wrote to Harald but he has not responded yet. So, I guess I'll follow up on this one... Nice to hear the you have solved the issue. First of all, could you please produce a proper patch!? (diff -Nurp) So that we can see whats going on... Here is my post to Harald: ------- Sent: Mon 6/19/2006 16:14 Subject: Performance work on libiptc Hi Harald I hope you can help me out. I have a performance issue with iptables which I have tracked down to the libiptc parsing. I would like to solve it, but need some help with the data structures. There is a scalability/performance issue in libiptc.c, when parsing the ruleset blob. The problem lies in the "Second pass" (of func parse_table) where the userchain jump targets are fixed/corrected. The "Second pass" loop has a bad worstcase run time of O(C*R). For each rule "R" with a IPTCC_R_JUMP target, func iptcc_find_chain_by_offset searches through the chain list "C" (worstcase hitting the last one). In my real life production system I have R=4492 and C=2238, giving a worstcase loop of 10.053.096. Basically, we need to make "iptcc_find_chain_by_offset" smarter... do you have any proposals? ------ I simply tracked down the problem using gprof. gprof output: +----- Each sample counts as 0.000999001 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 77.99 0.20 0.20 4492 0.04 0.04 iptcc_find_chain_by_offset 20.46 0.25 0.05 2238 0.02 0.02 iptc_insert_chain 1.16 0.26 0.00 16218 0.00 0.00 cache_add_entry 0.39 0.26 0.00 1 1.00 258.74 parse_table 0.00 0.26 0.00 13982 0.00 0.00 iptcc_alloc_rule 0.00 0.26 0.00 2239 0.00 0.00 __iptcc_p_del_policy 0.00 0.26 0.00 2238 0.00 0.02 __iptcc_p_add_chain 0.00 0.26 0.00 2238 0.00 0.00 iptcc_alloc_chain_head 0.00 0.26 0.00 2238 0.00 0.00 iptcc_delete_rule 0.00 0.26 0.00 1 0.00 0.00 add_command 0.00 0.26 0.00 1 0.00 0.00 alloc_handle 0.00 0.26 0.00 1 0.00 0.00 clear_rule_matches 0.00 0.26 0.00 1 0.00 258.74 do_command 0.00 0.26 0.00 1 0.00 0.00 find_target 0.00 0.26 0.00 1 0.00 0.00 free_opts 0.00 0.26 0.00 1 0.00 0.00 generic_opt_check 0.00 0.26 0.00 1 0.00 0.00 iptc_create_chain 0.00 0.26 0.00 1 0.00 258.74 iptc_init 0.00 0.26 0.00 1 0.00 0.00 iptc_strerror 0.00 0.26 0.00 1 0.00 0.00 iptcc_find_label +----- Cheers, Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- On Fri, 23 Jun 2006, Paul C. Diem wrote: > We have about 30,000 mangle table rules in about 8,000 chains. iptc_init > takes about 10 seconds just to load and parse the table. The problem is the > second parse phase that iterates through every chain and every rule > searching for the offset of the target for every jump rule. > > I've applied the following small patch that loads the offset of the chain > entry into the comefrom field of the first rule ipt entry in each > user-defined chain in the first pass. This comefrom field is then used in > the second pass to easily locate the target chain. This minor change has > reduced the load time of our mangle table to 1 second. > > Paul C. Diem > PCDiem@FoxValley.net > > 309a310,314 >> /*+PCD >> * Modification to use the offset to the chain entry in the ipt >> * entry comefrom field as loaded by iptcc_find_chain_by_offset. >> */ >> #if 0 > 319a325,329 >> #else >> STRUCT_ENTRY * e = ((STRUCT_ENTRY *)((char *)handle->entries->entrytable > + offset)); >> return (struct chain_head *)((char *)e + e->comefrom); >> #endif >> /*-PCD*/ > 496a507,512 >> /*+PCD >> * Load the offset to the chain entry relative to the >> * ipt entry into the ipt entry comefrom field. >> */ >> e->comefrom = (char *)h->chains.prev - (char *)e; >> /*-PCD*/ > > -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.3/374 - Release Date: 6/23/2006 From kadlec at blackhole.kfki.hu Mon Jun 26 15:10:07 2006 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Mon Jun 26 15:35:23 2006 Subject: ipset updated in svn Message-ID: Hi, I just wanted to let you know that the kernel part of ipset has been updated in svn: thanks to everyone who sent patches to catch up the internal 2.6.x API changes. The committed code should work on every latest release from the 2.6.15.x, 2.6.16.x and 2.6.17.x series but it might still be be incompatible with earlier releases as extraversion cannot be checked at preprocessing time. If you have got problems to compile/run it using the latest extraversion, please let me know. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From max at nucleus.it Mon Jun 26 16:41:46 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Mon Jun 26 17:09:39 2006 Subject: [PATCH] priv_data 0/2 Message-ID: <200606261641.47294.max@nucleus.it> Hi, this is a version of my priv_data patch that updates targets and renames functions as suggested by Patrick. Since xt_init_match() and xt_init_target() (formerly xt_check_match() and xt_check_target()) no longer just check and they needed some argument changes anyway, I included some more common code previously replicated in ip_tables.c, ip6_tables.c and arp_tables.c. Similarly I introduced xt_destroy_match() and xt_destroy_taget(). The resulting patches are larger than I anticipated, but most of the space is taken by function ranames and argument adjustments. My previous example with xt_condition still applies (just rename checkentry to init in struct xt_match). I tested several combination with iptables, ip6tables and arptables. It can't make it fail, but I didn't try it with a real world network load. Right now I don't have a 64 bit machine available for testing (I should be able to use one in a few days), so I didn't test compat at all. Testing and comments, as always, are appreciated. -- Saluti, Massimiliano Hofer From max at nucleus.it Mon Jun 26 16:43:07 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Mon Jun 26 17:09:44 2006 Subject: [PATCH] priv_data 1/2 Message-ID: <200606261643.08269.max@nucleus.it> Hi, this is the first part. Modifications to the core netfilter code. -- Saluti, Massimiliano Hofer -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-2.6.17.1-priv_data-core.patch Type: text/x-diff Size: 25813 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060626/8c3875be/01-2.6.17.1-priv_data-core-0001.bin From max at nucleus.it Mon Jun 26 16:44:03 2006 From: max at nucleus.it (Massimiliano Hofer) Date: Mon Jun 26 17:09:50 2006 Subject: [PATCH] priv_data Message-ID: <200606261644.04399.max@nucleus.it> Hi, this is a the bulk of it, but it's just renaming and paramter adjustments. -- Saluti, Massimiliano Hofer -------------- next part -------------- A non-text attachment was scrubbed... Name: 02-2.6.17.1-priv_data-matchesandtargets.patch Type: text/x-diff Size: 89174 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060626/b17c366c/02-2.6.17.1-priv_data-matchesandtargets-0001.bin From kaber at trash.net Mon Jun 26 17:43:07 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 26 18:08:28 2006 Subject: [NETFILTER 00/06]: Netfilter Update Message-ID: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Hi Dave, following is a small netfilter update. Nothing exciting, just minor fixes and a missing helptext. Please apply, thanks. net/ipv4/netfilter/arp_tables.c | 3 ++- net/ipv4/netfilter/ip_queue.c | 12 ++++++++++-- net/ipv4/netfilter/ip_tables.c | 3 ++- net/ipv6/netfilter/ip6_tables.c | 3 ++- net/netfilter/Kconfig | 5 ++++- net/netfilter/nf_conntrack_netlink.c | 1 + net/netfilter/nf_conntrack_proto_sctp.c | 2 ++ net/netfilter/nfnetlink_queue.c | 12 ++++++++++-- net/netfilter/xt_sctp.c | 2 +- net/netfilter/xt_tcpudp.c | 2 +- 10 files changed, 35 insertions(+), 10 deletions(-) Jorge Matias: [NETFILTER]: xt_sctp: fix --chunk-types matching Patrick McHardy: [NETFILTER]: x_tables: fix xt_register_table error propagation [NETFILTER]: ip_queue/nfnetlink_queue: drop bridge port references when dev disappears [NETFILTER]: statistic match: add missing Kconfig help text Yasuyuki Kozakai: [NETFILTER]: nf_conntrack: Fix undefined references to local_bh_* Yuri Gushin: [NETFILTER]: xt_tcpudp: fix double unregistration in error path From kaber at trash.net Mon Jun 26 17:43:08 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 26 18:08:32 2006 Subject: [NETFILTER 01/06]: x_tables: fix xt_register_table error propagation In-Reply-To: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> References: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Message-ID: <20060626154308.11682.91317.sendpatchset@localhost.localdomain> [NETFILTER]: x_tables: fix xt_register_table error propagation When xt_register_table fails the error is not properly propagated back. Based on patch by Lepton Wu . Signed-off-by: Patrick McHardy --- commit c223657397019f91ab8f7a7b8b417eae4a378c72 tree 016c6c6cd56cd11ef4d4250ab083da1894df03eb parent 80cd9e86e65901f97f3c77b914985cff387d331d author Patrick McHardy Mon, 19 Jun 2006 16:48:07 +0200 committer Patrick McHardy Mon, 19 Jun 2006 16:48:07 +0200 net/ipv4/netfilter/arp_tables.c | 3 ++- net/ipv4/netfilter/ip_tables.c | 3 ++- net/ipv6/netfilter/ip6_tables.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c index d0d1919..ad39bf6 100644 --- a/net/ipv4/netfilter/arp_tables.c +++ b/net/ipv4/netfilter/arp_tables.c @@ -1120,7 +1120,8 @@ int arpt_register_table(struct arpt_tabl return ret; } - if (xt_register_table(table, &bootstrap, newinfo) != 0) { + ret = xt_register_table(table, &bootstrap, newinfo); + if (ret != 0) { xt_free_table_info(newinfo); return ret; } diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c index cee3397..101ad98 100644 --- a/net/ipv4/netfilter/ip_tables.c +++ b/net/ipv4/netfilter/ip_tables.c @@ -2113,7 +2113,8 @@ int ipt_register_table(struct xt_table * return ret; } - if (xt_register_table(table, &bootstrap, newinfo) != 0) { + ret = xt_register_table(table, &bootstrap, newinfo); + if (ret != 0) { xt_free_table_info(newinfo); return ret; } diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c index 2e72f89..0b5bd55 100644 --- a/net/ipv6/netfilter/ip6_tables.c +++ b/net/ipv6/netfilter/ip6_tables.c @@ -1281,7 +1281,8 @@ int ip6t_register_table(struct xt_table return ret; } - if (xt_register_table(table, &bootstrap, newinfo) != 0) { + ret = xt_register_table(table, &bootstrap, newinfo); + if (ret != 0) { xt_free_table_info(newinfo); return ret; } From kaber at trash.net Mon Jun 26 17:43:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 26 18:08:33 2006 Subject: [NETFILTER 02/06]: nf_conntrack: Fix undefined references to local_bh_* In-Reply-To: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> References: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Message-ID: <20060626154310.11682.21299.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack: Fix undefined references to local_bh_* CC net/netfilter/nf_conntrack_proto_sctp.o net/netfilter/nf_conntrack_proto_sctp.c: In function `sctp_print_conntrack': net/netfilter/nf_conntrack_proto_sctp.c:206: warning: implicit declaration of function `local_bh_disable' net/netfilter/nf_conntrack_proto_sctp.c:208: warning: implicit declaration of function `local_bh_enable' CC net/netfilter/nf_conntrack_netlink.o net/netfilter/nf_conntrack_netlink.c: In function `ctnetlink_dump_table': net/netfilter/nf_conntrack_netlink.c:429: warning: implicit declaration of function `local_bh_disable' net/netfilter/nf_conntrack_netlink.c:452: warning: implicit declaration of function `local_bh_enable' Spotted by Toralf Förster Signed-off-by: Yasuyuki Kozakai Signed-off-by: Patrick McHardy --- commit 7cb7437f3a26e2054d315a9baea52f9d825a7286 tree 72c74e7b320d2763b3ba2e7387cf3f003c250b67 parent c223657397019f91ab8f7a7b8b417eae4a378c72 author Yasuyuki Kozakai Mon, 19 Jun 2006 16:48:59 +0200 committer Patrick McHardy Mon, 19 Jun 2006 16:48:59 +0200 net/netfilter/nf_conntrack_netlink.c | 1 + net/netfilter/nf_conntrack_proto_sctp.c | 2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index b8c7c56..af48459 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -29,6 +29,7 @@ #include #include #include #include +#include #include #include diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c index 0c6da49..0839b70 100644 --- a/net/netfilter/nf_conntrack_proto_sctp.c +++ b/net/netfilter/nf_conntrack_proto_sctp.c @@ -28,6 +28,8 @@ #include #include #include #include +#include +#include #include #include From kaber at trash.net Mon Jun 26 17:43:11 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 26 18:08:34 2006 Subject: [NETFILTER 03/06]: xt_tcpudp: fix double unregistration in error path In-Reply-To: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> References: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Message-ID: <20060626154311.11682.33519.sendpatchset@localhost.localdomain> [NETFILTER]: xt_tcpudp: fix double unregistration in error path "xt_unregister_match(AF_INET, &tcp_matchstruct)" is called twice, leaving "udp_matchstruct" registered, in case of a failure in the registration of the udp6 structure. Signed-off-by: Yuri Gushin Signed-off-by: Patrick McHardy --- commit a81302ac4c22da108602d0c053c168a700c81e32 tree b420da32ec06dd3d9e9a42b581bcfcc05b6eee53 parent 7cb7437f3a26e2054d315a9baea52f9d825a7286 author Yuri Gushin Mon, 19 Jun 2006 16:59:55 +0200 committer Patrick McHardy Mon, 19 Jun 2006 16:59:55 +0200 net/netfilter/xt_tcpudp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netfilter/xt_tcpudp.c b/net/netfilter/xt_tcpudp.c index 1b61dac..a9a63aa 100644 --- a/net/netfilter/xt_tcpudp.c +++ b/net/netfilter/xt_tcpudp.c @@ -260,7 +260,7 @@ static int __init xt_tcpudp_init(void) return ret; out_unreg_udp: - xt_unregister_match(&tcp_matchstruct); + xt_unregister_match(&udp_matchstruct); out_unreg_tcp6: xt_unregister_match(&tcp6_matchstruct); out_unreg_tcp: From kaber at trash.net Mon Jun 26 17:43:12 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 26 18:08:39 2006 Subject: [NETFILTER 04/06]: xt_sctp: fix --chunk-types matching In-Reply-To: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> References: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Message-ID: <20060626154312.11682.68659.sendpatchset@localhost.localdomain> [NETFILTER]: xt_sctp: fix --chunk-types matching xt_sctp uses an incorrect header offset when --chunk-types is used. Signed-off-by: Jorge Matias Signed-off-by: Patrick McHardy --- commit 9565b859bc682e4c208f73e83adb21a7f86d0143 tree 7823e21bbe10b265fe011cb895f30160789210ad parent a81302ac4c22da108602d0c053c168a700c81e32 author Jorge Matias Mon, 19 Jun 2006 18:04:28 +0200 committer Patrick McHardy Mon, 19 Jun 2006 18:04:28 +0200 net/netfilter/xt_sctp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netfilter/xt_sctp.c b/net/netfilter/xt_sctp.c index b5110e5..919c037 100644 --- a/net/netfilter/xt_sctp.c +++ b/net/netfilter/xt_sctp.c @@ -151,7 +151,7 @@ match(const struct sk_buff *skb, && SCCHECK(((ntohs(sh->dest) >= info->dpts[0]) && (ntohs(sh->dest) <= info->dpts[1])), XT_SCTP_DEST_PORTS, info->flags, info->invflags) - && SCCHECK(match_packet(skb, protoff, + && SCCHECK(match_packet(skb, protoff + sizeof (sctp_sctphdr_t), info->chunkmap, info->chunk_match_type, info->flag_info, info->flag_count, hotdrop), From kaber at trash.net Mon Jun 26 17:43:15 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 26 18:08:40 2006 Subject: [NETFILTER 06/06]: statistic match: add missing Kconfig help text In-Reply-To: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> References: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Message-ID: <20060626154315.11682.84446.sendpatchset@localhost.localdomain> [NETFILTER]: statistic match: add missing Kconfig help text Signed-off-by: Patrick McHardy --- commit 761a7b483e46977e51f703ec5ff5d5861f328eb8 tree 18b8e54efc62a8c6d03ae8fba782b1b0c5d1f18f parent 5e9d63f46ae2805245fcc9ec58f844d1347bd469 author Patrick McHardy Mon, 26 Jun 2006 17:17:25 +0200 committer Patrick McHardy Mon, 26 Jun 2006 17:17:25 +0200 net/netfilter/Kconfig | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index b1622b7..42a178a 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -411,7 +411,10 @@ config NETFILTER_XT_MATCH_STATISTIC tristate '"statistic" match support' depends on NETFILTER_XTABLES help - statistic module + This option adds a `statistic' match, which allows you to match + on packets periodically or randomly with a given percentage. + + To compile it as a module, choose M here. If unsure, say N. config NETFILTER_XT_MATCH_STRING tristate '"string" match support' From kaber at trash.net Mon Jun 26 17:43:13 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Jun 26 18:08:41 2006 Subject: [NETFILTER 05/06]: ip_queue/nfnetlink_queue: drop bridge port references when dev disappears In-Reply-To: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> References: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Message-ID: <20060626154313.11682.382.sendpatchset@localhost.localdomain> [NETFILTER]: ip_queue/nfnetlink_queue: drop bridge port references when dev disappears When a device that is acting as a bridge port is unregistered, the ip_queue/nfnetlink_queue notifier doesn't check if its one of physindev/physoutdev and doesn't release the references if it is. Signed-off-by: Patrick McHardy --- commit 5e9d63f46ae2805245fcc9ec58f844d1347bd469 tree 96f0d37e0f70100ba2b31b7eaa5453125a4d6ac4 parent 9565b859bc682e4c208f73e83adb21a7f86d0143 author Patrick McHardy Mon, 26 Jun 2006 17:15:02 +0200 committer Patrick McHardy Mon, 26 Jun 2006 17:15:02 +0200 net/ipv4/netfilter/ip_queue.c | 12 ++++++++++-- net/netfilter/nfnetlink_queue.c | 12 ++++++++++-- 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c index b93f049..213d116 100644 --- a/net/ipv4/netfilter/ip_queue.c +++ b/net/ipv4/netfilter/ip_queue.c @@ -457,11 +457,19 @@ dev_cmp(struct ipq_queue_entry *entry, u if (entry->info->indev) if (entry->info->indev->ifindex == ifindex) return 1; - if (entry->info->outdev) if (entry->info->outdev->ifindex == ifindex) return 1; - +#ifdef CONFIG_BRIDGE_NETFILTER + if (entry->skb->nf_bridge) { + if (entry->skb->nf_bridge->physindev && + entry->skb->nf_bridge->physindev->ifindex == ifindex) + return 1; + if (entry->skb->nf_bridge->physoutdev && + entry->skb->nf_bridge->physoutdev->ifindex == ifindex) + return 1; + } +#endif return 0; } diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c index 86a4ac3..49ef41e 100644 --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -680,11 +680,19 @@ dev_cmp(struct nfqnl_queue_entry *entry, if (entinf->indev) if (entinf->indev->ifindex == ifindex) return 1; - if (entinf->outdev) if (entinf->outdev->ifindex == ifindex) return 1; - +#ifdef CONFIG_BRIDGE_NETFILTER + if (entry->skb->nf_bridge) { + if (entry->skb->nf_bridge->physindev && + entry->skb->nf_bridge->physindev->ifindex == ifindex) + return 1; + if (entry->skb->nf_bridge->physoutdev && + entry->skb->nf_bridge->physoutdev->ifindex == ifindex) + return 1; + } +#endif return 0; } From ianbrn at gmail.com Tue Jun 27 06:38:46 2006 From: ianbrn at gmail.com (Ian Brown) Date: Tue Jun 27 07:04:13 2006 Subject: netfilter and packets which are created locally Message-ID: Hello, This message was sent 2 days ago to the netdev mailing list but got no answers. And in a second thought,this list may be a better place for it: I had looked at the diagrams and read the explanations about netfilter in Netfilter Architecture page: http://netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html I want to make sure wheter I undestood something regarding packets which are created locally (as opposed to packets that are received on the network interface). My question is: Do I understand the following 2 sceanrios right? For local packets which are sent out of the machine it seems to me to be the case. (Am I right?): Such packets , that are created locally on the machine, first reach the NF_IP_LOCAL_OUT [5] hook. Than they go to the routing stage, and than they go to NF_IP_POST_ROUTING [4]. And then they go out ? Such packets, which are created locally, don't pass at all at the [1] stage, NF_IP_PRE_ROUTING [1] , and not in NF_IP_LOCAL_IN [2] stage and not in NF_IP_FORWARD [3] . Is it true? Suppose I create locally packets which are destined to myself (like ping myself). I assume that they will go first to the NF_IP_LOCAL_OUT [5] , than to the routing stage, but will they go to the NF_IP_POST_ROUTING [4].? And again,such packets, which are created locally, don't pass at all at the [1] stage, NF_IP_PRE_ROUTING [1] , and not in NF_IP_LOCAL_IN [2] stage and not in NF_IP_FORWARD [3] . Is it true? IB From davem at davemloft.net Tue Jun 27 12:02:38 2006 From: davem at davemloft.net (David Miller) Date: Tue Jun 27 12:28:27 2006 Subject: [NETFILTER 00/06]: Netfilter Update In-Reply-To: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> References: <20060626154307.11682.28562.sendpatchset@localhost.localdomain> Message-ID: <20060627.030238.59467015.davem@davemloft.net> From: Patrick McHardy Date: Mon, 26 Jun 2006 17:43:07 +0200 (MEST) > following is a small netfilter update. Nothing exciting, just minor fixes and > a missing helptext. Please apply, thanks. All applied, thanks Patrick. From kaber at trash.net Wed Jun 28 00:43:14 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Jun 28 01:10:02 2006 Subject: pppd stuck in ioctl(TIOCSETD) in Linux 2.6.15.4+ In-Reply-To: <004b01c69a3a$6b80c660$0201a8c0@athlon64> References: <004b01c69a3a$6b80c660$0201a8c0@athlon64> Message-ID: <44A1B482.80901@trash.net> Jorge Daniel Sequeira Matias wrote: > > Hi everyone, > > I'm running a PPTP VPN Server for almost 4 years now. This server is > running in a Debian Linux (unstable). > The configuration for the last 1 year and a half was the following: > > Computer 2x Intel Xeon 2.6GHz and 512MB RAM > Linux v2.6.11.6 (vanilla) with MPPE patch > Debian distribution with the following packages > - pppd 2.4.3-20050321 > - libradius1 0.3.2-8 > - radiusclient1 0.3.2-8 > > With this configuration I had reach a peek of aprox. 600 hundred PPTP > connections simultaneously. The computer gets heavy loaded doing MPPE > compression/decompression with 40Mbits/sec of PPP traffic but didn't > have any problem with this setup. The authentication process is using a > pool of RADIUS servers. > > This machine is also a firewall, and now a new feature was needed: > PPTP VPN connections from the inside. > > The problem: > > After the upgrade to a Linux v2.6.15.4 (vanilla) with no patches to > use the new "ip_conntrack_pptp" module, I started to get "pppd" > processes hanging in "S" state and consuming CPU power. Does the problem go away without the ip_conntrack_pptp module loaded? From martin at andorinha.ist.utl.pt Wed Jun 28 00:50:30 2006 From: martin at andorinha.ist.utl.pt (Jorge Daniel Sequeira Matias) Date: Wed Jun 28 13:56:31 2006 Subject: pppd stuck in ioctl(TIOCSETD) in Linux 2.6.15.4+ References: <004b01c69a3a$6b80c660$0201a8c0@athlon64> <44A1B482.80901@trash.net> Message-ID: <006801c69a3c$29f846d0$0201a8c0@athlon64> ----- Original Message ----- From: "Patrick McHardy" To: "Jorge Daniel Sequeira Matias" Cc: ; "Netfilter Development Mailinglist" Sent: Tuesday, June 27, 2006 11:43 PM Subject: Re: pppd stuck in ioctl(TIOCSETD) in Linux 2.6.15.4+ >> [...] > Does the problem go away without the ip_conntrack_pptp module loaded? When I had the 2.6.15.4 installed I have recompiled without this module. The problem didn't go away. I know that 2.6.16.x has a different Netfilter structure but I have not tried yet to remove "ip_conntrack_pptp" with this version. Right now I have 2.6.16.16 with the module loaded. Regards, Jorge Matias From inox_kas at yahoo.com Wed Jun 28 21:19:55 2006 From: inox_kas at yahoo.com (kas turi) Date: Thu Jun 29 14:25:20 2006 Subject: Patches for SIP, H323 for 2.4.20 kernel Message-ID: <20060628191955.56364.qmail@web32208.mail.mud.yahoo.com> Hi I would like to know where I can find connection tracking and NAT patches for H.323 and SIP for 2.4.20 kernel. Thanks in advance Kasturi __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From azez at ufomechanic.net Thu Jun 29 16:48:04 2006 From: azez at ufomechanic.net (Amin Azez) Date: Thu Jun 29 17:14:10 2006 Subject: ip_conntrack_get ip_conntrack_put assymetry Message-ID: How is it that ip_conntrack_put does an nf_conntrack_put, but ip_conntrack_get does not do nf_conntrack_get or otherwise increase the ref count. This asymmetry is likely to be confusing, or am I already confused? Sam From delleceste at gmail.com Fri Jun 30 09:08:15 2006 From: delleceste at gmail.com (Giacomo) Date: Fri Jun 30 09:34:04 2006 Subject: Question about a locking problem Message-ID: <885896af0606300008h341cd400mf66700400bba28e2@mail.gmail.com> Good morning. Some time ago i wrote a module in kernel space which does some filtering. While running `dhclient eth0' and plugging/unplugging the ethernet cable from the network card, kernel freezed saying the culprit was the following function (EIP is at get_ifaddr_by_name() ) : /* returns in *addr the internet address having the name ifname */ int get_ifaddr_by_name(const char *ifname, __u32 * addr) { struct net_device *pnet_device; struct in_device *pin_device; read_lock_bh(&dev_base_lock); pnet_device = dev_base; while (pnet_device != NULL) { if ((netif_running(pnet_device)) && (pnet_device->ip_ptr != NULL) && (strcmp(pnet_device->name, ifname) == 0)) { pin_device = (struct in_device *) pnet_device->ip_ptr; /* ifa_local: ifa_address is the remote point in ppp */ *addr = (pin_device->ifa_list->ifa_local); read_unlock_bh(&dev_base_lock); return 1; } pnet_device = pnet_device->next; } read_unlock_bh(&dev_base_lock); return -1; /* address not found! */ } What could be wrong? I think the problem is that read_lock_bh is not correct, perhaps i would need read_lock_irq instead?? Can anyone suggest if i am right. Thanks a lot Giacomo. -- Giacomo S. http://www.giacomos.it - - - - - - - - - - - - - - - - - - - - - - Proteggi il tuo PC provando il mio semplice FIREWALL: http://www.giacomos.it/ipfire mailto: delleceste@gmail.com giacomo.strangolino@elettra.trieste.it jacum@libero.it - - - - - - - - - - - - - - - - - - - - - - . '' `. : :' : `. ` ' `- Debian GNU/Linux -- The power of freedom http://www.debian.org From azez at ufomechanic.net Fri Jun 30 11:10:50 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 30 11:36:49 2006 Subject: Hacking iptables 1.3.5 for 2.6.17 Message-ID: Whats the official way to add extra extensions targets extensions/Makefile? I generally patch extensions/Makefile to add to PF_EXT_SLIB, like PF_EXT_SLIB+=new_extension but then I get complaints about it being listed twice. Is there a neater way to express extra extensions to the Makefile? Also; I don't think this problem is specific to iptables, but general to building anything against a kernel. If a kernel is built with the -O=dir option to place build files outside of the source tree, then version.h, autoconf.h and compile.h are written to dir/include/linux instead of src/include/linux This means that make KERNEL_DIR=src is not enough, as dir also needs to be in the search path (or dir/include) Probably it needs to be before KERNEL_DIR in the search path. Sam From yasuyuki.kozakai at toshiba.co.jp Fri Jun 30 11:48:22 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Jun 30 12:14:20 2006 Subject: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: References: Message-ID: <200606300948.k5U9mNpF019373@toshiba.co.jp> From: Amin Azez Date: Fri, 30 Jun 2006 10:10:50 +0100 > Whats the official way to add extra extensions targets extensions/Makefile? > > I generally patch extensions/Makefile to add to PF_EXT_SLIB, like > PF_EXT_SLIB+=new_extension > > but then I get complaints about it being listed twice. Is there a neater > way to express extra extensions to the Makefile? You can build your extension with iptables by putting .new_extension-test (or .new_extension-test6 if it is for ip6tables) which tests whether kernel source support the extension. Please look extensions/.test-* . > Also; > > I don't think this problem is specific to iptables, but general to > building anything against a kernel. > > If a kernel is built with the -O=dir option to place build files outside > of the source tree, then version.h, autoconf.h and compile.h are written > to dir/include/linux instead of src/include/linux > > This means that > make KERNEL_DIR=src > is not enough, as dir also needs to be in the search path (or dir/include) > > Probably it needs to be before KERNEL_DIR in the search path. The automatically generated files at kernel compilation are not necessary to build iptables, then KERNEL_DIR is enough. Or do I miss something ? -- Yasuyuki Kozakai From yasuyuki.kozakai at toshiba.co.jp Fri Jun 30 13:57:18 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Jun 30 14:23:12 2006 Subject: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A50091.7070003@ufomechanic.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> Message-ID: <200606301157.k5UBvJTl016149@toshiba.co.jp> From: Amin Azez Date: Fri, 30 Jun 2006 11:44:33 +0100 > Well, my src/linux-2.6.17.1/include/linux/config.h (line 6) tries to > include linux/autoconf.h, which is now part of the O=dir build output. > If it can't find my build autoconf.h then it falls back to > /usr/include/linux/autoconf.h which is: > #error Invalid kernel header included in userspace > > In case this much is bogus, here are the include dependancies; > > Extensions found: IPv4:CLUSTERIP IPv4:connbytes IPv4:dccp IPv4:recent > IPv4:string IPv6:ah IPv6:esp IPv6:frag IPv6:ipv6header IPv6:hbh IPv6:dst > IPv6:REJECT IPv6:rt > cc -O2 -Wall -Wunused -I/opt/KERNEL/linux-2.6.17.1//include -Iinclude/ > -DIPTABLES_VERSION=\"1.3.5-20060629\" -D_UNKNOWN_KERNEL_POINTER_SIZE > -fPIC -o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c > In file included from /opt/KERNEL/linux-2.6.17.1/include/linux/config.h:6, > from /opt/KERNEL/linux-2.6.17.1/include/linux/netfilter_ipv4.h:8, > from /opt/KERNEL/linux-2.6.17.1/include/linux/netfilter_ipv4/ip_tables.h:26, > from include/libiptc/libiptc.h:6, > from include/iptables.h:5, > from extensions/libipt_ah.c:8: > /usr/include/linux/autoconf.h:1:2: #error Invalid kernel header included > in usersp I was seeing the recent git tree that the above problem was fixed. As you says, netfilter_ipv4.h in 2.6.17.x has unnecessary '#include ' outside of __KERNEL__. But it seemd to be deleted in recent kernel as follows. > commit 62c4f0a2d5a188f73a94f2cb8ea0dba3e7cf0a7f > Author: David Woodhouse > Date: Wed Apr 26 12:56:16 2006 +0100 > > Don't include linux/config.h from anywhere else in include/ > > Signed-off-by: David Woodhouse I don't think/know that this goes to stable tree, though. -- Yasuyuki Kozakai From azez at ufomechanic.net Fri Jun 30 14:40:43 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 30 15:06:42 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <200606301157.k5UBvJTl016149@toshiba.co.jp> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> Message-ID: <44A51BCB.7090006@ufomechanic.net> Yasuyuki KOZAKAI wrote: > As you says, netfilter_ipv4.h in 2.6.17.x has unnecessary > '#include ' outside of __KERNEL__. But it seemd to be deleted > in recent kernel as follows. > >> commit 62c4f0a2d5a188f73a94f2cb8ea0dba3e7cf0a7f >> Author: David Woodhouse >> Date: Wed Apr 26 12:56:16 2006 +0100 >> >> Don't include linux/config.h from anywhere else in include/ >> >> Signed-off-by: David Woodhouse > > I don't think/know that this goes to stable tree, though. Thanks; thats helpful and also solves a long-standing puzzlement for me. (Into my quilt stack it goes) Next question relates to the port to xtables and friends, and what I need to do to convert iptables targets. I notice a lot of things have moved to net/netfilter/xt_*.c Is this an absolute requirement, or is there some compatability system? I'm porting the layer7 match first, currently when adding a layer7 rule I get (dmesg): [71987.513531] ip_tables: layer7 match: invalid size 0 != 8452 I know where the error is coming from I just wonder if I have to do a complete conversion now, or a quick fix and fuller conversion later... thanks Sam From azez at ufomechanic.net Fri Jun 30 14:40:43 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 30 15:06:51 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <200606301157.k5UBvJTl016149@toshiba.co.jp> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> Message-ID: <44A51BCB.7090006@ufomechanic.net> Yasuyuki KOZAKAI wrote: > As you says, netfilter_ipv4.h in 2.6.17.x has unnecessary > '#include ' outside of __KERNEL__. But it seemd to be deleted > in recent kernel as follows. > >> commit 62c4f0a2d5a188f73a94f2cb8ea0dba3e7cf0a7f >> Author: David Woodhouse >> Date: Wed Apr 26 12:56:16 2006 +0100 >> >> Don't include linux/config.h from anywhere else in include/ >> >> Signed-off-by: David Woodhouse > > I don't think/know that this goes to stable tree, though. Thanks; thats helpful and also solves a long-standing puzzlement for me. (Into my quilt stack it goes) Next question relates to the port to xtables and friends, and what I need to do to convert iptables targets. I notice a lot of things have moved to net/netfilter/xt_*.c Is this an absolute requirement, or is there some compatability system? I'm porting the layer7 match first, currently when adding a layer7 rule I get (dmesg): [71987.513531] ip_tables: layer7 match: invalid size 0 != 8452 I know where the error is coming from I just wonder if I have to do a complete conversion now, or a quick fix and fuller conversion later... thanks Sam From menno at netboxblue.com Fri Jun 30 16:19:45 2006 From: menno at netboxblue.com (Menno Smits) Date: Fri Jun 30 16:46:22 2006 Subject: conntrack table filling up due to missing ACKs near the end of a TCP session Message-ID: <44A53301.1090603@netboxblue.com> Hi all, I'm seeing a problem on a customer box that acts as a primary MX and is running netfilter. The secondary MXs (run by the ISP) appear to be broken and cause the conntrack table on the primary MX to fill up. What happens is this: - secondary connects to deliver mail - connection is established and SMTP conversation takes place - secondary issues QUIT - primary sends response "221 Bye" - primary sends FIN - secondary sends FIN - primary ACKs FIN from secondary The secondary never ACKs the last data packet ("221 Bye") or FIN sent by the primary. Later the primary retries the "221 Bye" packets several times. Interestingly the secondary also sends a Keep-Alive soon after it sends it's FIN. This happens for every inbound connection from the secondaries and the result is 1000's of ESTABLISHED entries with 5 day timeouts in the conntrack table. The table eventually fills up causing packet loss. The conntrack entries are all of the form: tcp 6 24826 ESTABLISHED src=pri.ma.ry.ip dst=sec.ond.ary.ip sport=25 dport=54334 packets=3 bytes=183 [UNREPLIED] src=sec.ond.ary.ip dst=pri.ma.ry.ip sport=54334 dport=25 packets=0 bytes=0 mark=0 use=1 The primary is blocking packets that aren't NEW, ESTALISHED or RELATED. This could be contributing to the problem but I haven't looked closely at this. Clearly the secondary mail servers are broken but shouldn't netfilter handle this situation better. Shouldn't the timeout of a connection be greatly reduced if a FIN has been sent? I have an isolated packet dump for one connection. I'm happy to send it to a netfilter developer privately but am hesitant to post it to the list since it is from a customer site. Any thoughts or advice on this would be greatly appreciated. Regards, Menno Smits NetBox Blue http://netboxblue.com/ From kaber at trash.net Fri Jun 30 16:39:16 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Jun 30 17:05:07 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A51BCB.7090006@ufomechanic.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> Message-ID: <44A53794.6060405@trash.net> Amin Azez wrote: > I notice a lot of things have moved to net/netfilter/xt_*.c > > Is this an absolute requirement, or is there some compatability system? No requirement, things can just stay where they are. > I'm porting the layer7 match first, currently when adding a layer7 rule > I get (dmesg): > [71987.513531] ip_tables: layer7 match: invalid size 0 != 8452 8452? Thats ridiculous much .. anyway, you need to initialize the .matchsize field to sizeof(struct ...) (the one shared with userspace). From kaber at trash.net Fri Jun 30 16:53:11 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Jun 30 17:19:01 2006 Subject: conntrack table filling up due to missing ACKs near the end of a TCP session In-Reply-To: <44A53301.1090603@netboxblue.com> References: <44A53301.1090603@netboxblue.com> Message-ID: <44A53AD7.9000007@trash.net> Menno Smits wrote: > Hi all, > > I'm seeing a problem on a customer box that acts as a primary MX and is > running netfilter. The secondary MXs (run by the ISP) appear to be > broken and cause the conntrack table on the primary MX to fill up. > > What happens is this: > > - secondary connects to deliver mail > - connection is established and SMTP conversation takes place > - secondary issues QUIT > - primary sends response "221 Bye" > - primary sends FIN > - secondary sends FIN > - primary ACKs FIN from secondary > > The secondary never ACKs the last data packet ("221 Bye") or FIN sent by > the primary. Later the primary retries the "221 Bye" packets several > times. Interestingly the secondary also sends a Keep-Alive soon after it > sends it's FIN. > > This happens for every inbound connection from the secondaries and the > result is 1000's of ESTABLISHED entries with 5 day timeouts in the > conntrack table. The table eventually fills up causing packet loss. The > conntrack entries are all of the form: > > tcp 6 24826 ESTABLISHED src=pri.ma.ry.ip dst=sec.ond.ary.ip > sport=25 dport=54334 packets=3 bytes=183 [UNREPLIED] src=sec.ond.ary.ip > dst=pri.ma.ry.ip sport=54334 dport=25 packets=0 bytes=0 mark=0 use=1 > > The primary is blocking packets that aren't NEW, ESTALISHED or RELATED. > This could be contributing to the problem but I haven't looked closely > at this. If you look at the byte counters, the connection seems to consist only of three packets sent by the primary. I guess one of them was an ACK, which through connection pick-up places the conntrack in ESTABLISHED state. The first question would be why they're not properly associated with the real connection. Please try "echo 255 > /proc/net/ipv4/netfilter/ip_conntrack_log_invalid". As a work-around you could disable connection pickup or drop outgoing TCP packets with state NEW but no SYN. From GregScott at InfraSupportEtc.com Fri Jun 30 17:15:42 2006 From: GregScott at InfraSupportEtc.com (Greg Scott) Date: Fri Jun 30 17:41:31 2006 Subject: 2.6.17.1 compile error with a netfilter module Message-ID: <925A849792280C4E80C5461017A4B8A206F783@mail733.InfraSupportEtc.com> Does anyone know what this means and how to fix it? I know it looks like a file named lockhelp.h is missing. I guess my question is, what can I do to fix it? With this build, I tried to put in some POM patches from patch-o-matic-ng-20060624. Could this have been my problem? . . . CC [M] net/ipv4/ipvs/ip_vs_nq.o CC [M] net/ipv4/ipvs/ip_vs_ftp.o scripts/Makefile.build:52: kbuild: net/ipv4/netfilter/Makefile - Usage of export-objs is obsolete in 2.6. Please fix! LD net/ipv4/netfilter/built-in.o CC [M] net/ipv4/netfilter/ip_conntrack_standalone.o In file included from include/linux/netfilter_ipv4/ip_conntrack.h:32, from net/ipv4/netfilter/ip_conntrack_standalone.c:35: include/linux/netfilter_ipv4/ip_conntrack_talk.h:7:43: error: linux/netfilter_ipv4/lockhelp.h: No such file or directory In file included from include/linux/netfilter_ipv4/ip_conntrack.h:32, from net/ipv4/netfilter/ip_conntrack_standalone.c:35: include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: data definition has no type or storage class include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: type defaults to 'int' in declaration of 'DECLARE_LOCK_EXTERN' include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: parameter names (without types) in function declaration make[3]: *** [net/ipv4/netfilter/ip_conntrack_standalone.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 You have new mail in /var/spool/mail/root [root@HHHC-fw linux]# [root@HHHC-fw linux]# [ thanks - Greg Scott From kaber at trash.net Fri Jun 30 17:28:19 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Jun 30 17:54:07 2006 Subject: 2.6.17.1 compile error with a netfilter module In-Reply-To: <925A849792280C4E80C5461017A4B8A206F783@mail733.InfraSupportEtc.com> References: <925A849792280C4E80C5461017A4B8A206F783@mail733.InfraSupportEtc.com> Message-ID: <44A54313.4050901@trash.net> Greg Scott wrote: > Does anyone know what this means and how to fix it? I know it looks > like a file named lockhelp.h is missing. I guess my question is, what > can I do to fix it? > > With this build, I tried to put in some POM patches from > patch-o-matic-ng-20060624. Could this have been my problem? Yes. It looks like you managed to apply some old 2.4 patches :) If you don't need them I'd suggest to just don't use them. From azez at ufomechanic.net Fri Jun 30 17:55:24 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 30 18:21:25 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A53794.6060405@trash.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> <44A53794.6060405@trash.net> Message-ID: <44A5496C.3030504@ufomechanic.net> Patrick McHardy wrote: > Amin Azez wrote: >> I notice a lot of things have moved to net/netfilter/xt_*.c >> >> Is this an absolute requirement, or is there some compatability system? > > No requirement, things can just stay where they are. > >> I'm porting the layer7 match first, currently when adding a layer7 rule >> I get (dmesg): >> [71987.513531] ip_tables: layer7 match: invalid size 0 != 8452 > > 8452? Thats ridiculous much too right! Layer7 permits up to 8192 for the regex - like anyone is going to want to run a regex that long on every packet (well the first few of each connection) Whats anyones feelings on flexible sizes of iptables match structs? Or even on making the kernel size struct bigger? Right now layer7 does a linear search through a cache of pre-compiled regexes with the original regex as the key - PER PACKET - it would make much more sense to store a pointer to the cached regex in the matchinfo - which is what I'm doing now; but the lack of extra kernelside fields is restrictive, so I'm canibalizing (in an ugly way) the last few bytes of the refex field. >.. anyway, you need to initialize the > .matchsize field to sizeof(struct ...) (the one shared with userspace). aye, that works fine, thanks. To my surprise I'm getting checkinfo called lots of times, I thought it would only be called once when a new rule was being accepted kernel-side. Do you know why it would be called many times (with the same value matchinfo pointer) Sam From azez at ufomechanic.net Fri Jun 30 17:55:24 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 30 18:21:32 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A53794.6060405@trash.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> <44A53794.6060405@trash.net> Message-ID: <44A5496C.3030504@ufomechanic.net> Patrick McHardy wrote: > Amin Azez wrote: >> I notice a lot of things have moved to net/netfilter/xt_*.c >> >> Is this an absolute requirement, or is there some compatability system? > > No requirement, things can just stay where they are. > >> I'm porting the layer7 match first, currently when adding a layer7 rule >> I get (dmesg): >> [71987.513531] ip_tables: layer7 match: invalid size 0 != 8452 > > 8452? Thats ridiculous much too right! Layer7 permits up to 8192 for the regex - like anyone is going to want to run a regex that long on every packet (well the first few of each connection) Whats anyones feelings on flexible sizes of iptables match structs? Or even on making the kernel size struct bigger? Right now layer7 does a linear search through a cache of pre-compiled regexes with the original regex as the key - PER PACKET - it would make much more sense to store a pointer to the cached regex in the matchinfo - which is what I'm doing now; but the lack of extra kernelside fields is restrictive, so I'm canibalizing (in an ugly way) the last few bytes of the refex field. >.. anyway, you need to initialize the > .matchsize field to sizeof(struct ...) (the one shared with userspace). aye, that works fine, thanks. To my surprise I'm getting checkinfo called lots of times, I thought it would only be called once when a new rule was being accepted kernel-side. Do you know why it would be called many times (with the same value matchinfo pointer) Sam From kaber at trash.net Fri Jun 30 18:08:05 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Jun 30 18:33:53 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A5496C.3030504@ufomechanic.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> <44A53794.6060405@trash.net> <44A5496C.3030504@ufomechanic.net> Message-ID: <44A54C65.20906@trash.net> Amin Azez wrote: > Patrick McHardy wrote: > >>Amin Azez wrote: >> >>>I notice a lot of things have moved to net/netfilter/xt_*.c >>> >>>Is this an absolute requirement, or is there some compatability system? >> >>No requirement, things can just stay where they are. >> >> >>>I'm porting the layer7 match first, currently when adding a layer7 rule >>>I get (dmesg): >>>[71987.513531] ip_tables: layer7 match: invalid size 0 != 8452 >> >>8452? Thats ridiculous much > > > too right! Layer7 permits up to 8192 for the regex - like anyone is > going to want to run a regex that long on every packet (well the first > few of each connection) > > Whats anyones feelings on flexible sizes of iptables match structs? Its not possible with the current architecture, and overcoming this would probably not be worth it measured in both time and the resulting uglyness compared to just introducing a netlink interface. > Right now layer7 does a linear search through a cache of pre-compiled > regexes with the original regex as the key - PER PACKET - it would make > much more sense to store a pointer to the cached regex in the matchinfo > - which is what I'm doing now; but the lack of extra kernelside fields > is restrictive, so I'm canibalizing (in an ugly way) the last few bytes > of the refex field. Thats a bit of a different problem. Per-instance private data will soon be possible in a nicer way. >>.. anyway, you need to initialize the >>.matchsize field to sizeof(struct ...) (the one shared with userspace). > > > aye, that works fine, thanks. > To my surprise I'm getting checkinfo called lots of times, I thought it > would only be called once when a new rule was being accepted > kernel-side. Do you know why it would be called many times (with the > same value matchinfo pointer) It gets called whenever you add a new rule. Thats a result of the atomic-exchange of the entire ruleset, each "generation" of your ruleset (while adding rules incrementally) is an entirely new ruleset to the kernel. From azez at ufomechanic.net Fri Jun 30 18:28:06 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 30 18:54:05 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A54C65.20906@trash.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> <44A53794.6060405@trash.net> <44A5496C.3030504@ufomechanic.net> <44A54C65.20906@trash.net> Message-ID: <44A55116.9080107@ufomechanic.net> Patrick McHardy wrote: > Amin Azez wrote: >> To my surprise I'm getting checkinfo called lots of times, I thought it >> would only be called once when a new rule was being accepted >> kernel-side. Do you know why it would be called many times (with the >> same value matchinfo pointer) > > It gets called whenever you add a new rule. Thats a result of the > atomic-exchange of the entire ruleset, each "generation" of your > ruleset (while adding rules incrementally) is an entirely new > ruleset to the kernel. iptables -Z dsrateentries -t mangle causes the checkentry to all be called again. (It just so happens I was doing that every 10 seconds) I guess iptables -z is not as lightweight as I thought, it perhaps re-applies all the rules - or maybe checkentry is wrongly being called from -z? Or maybe checkentry can do more these days and I need to check why it is called Sam From azez at ufomechanic.net Fri Jun 30 18:28:06 2006 From: azez at ufomechanic.net (Amin Azez) Date: Fri Jun 30 18:54:23 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A54C65.20906@trash.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> <44A53794.6060405@trash.net> <44A5496C.3030504@ufomechanic.net> <44A54C65.20906@trash.net> Message-ID: <44A55116.9080107@ufomechanic.net> Patrick McHardy wrote: > Amin Azez wrote: >> To my surprise I'm getting checkinfo called lots of times, I thought it >> would only be called once when a new rule was being accepted >> kernel-side. Do you know why it would be called many times (with the >> same value matchinfo pointer) > > It gets called whenever you add a new rule. Thats a result of the > atomic-exchange of the entire ruleset, each "generation" of your > ruleset (while adding rules incrementally) is an entirely new > ruleset to the kernel. iptables -Z dsrateentries -t mangle causes the checkentry to all be called again. (It just so happens I was doing that every 10 seconds) I guess iptables -z is not as lightweight as I thought, it perhaps re-applies all the rules - or maybe checkentry is wrongly being called from -z? Or maybe checkentry can do more these days and I need to check why it is called Sam From kaber at trash.net Fri Jun 30 18:37:12 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Jun 30 19:03:00 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A55116.9080107@ufomechanic.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> <44A53794.6060405@trash.net> <44A5496C.3030504@ufomechanic.net> <44A54C65.20906@trash.net> <44A55116.9080107@ufomechanic.net> Message-ID: <44A55338.8080903@trash.net> Amin Azez wrote: > iptables -Z dsrateentries -t mangle > > causes the checkentry to all be called again. > (It just so happens I was doing that every 10 seconds) > > I guess iptables -z is not as lightweight as I thought, it perhaps > re-applies all the rules - or maybe checkentry is wrongly being called > from -z? I'm actually not sure how this is implemented, I guess it just dumps the ruleset to userspace, changes counters and pumps it back to the kernel again (which means it needs to be revalidated). From GregScott at InfraSupportEtc.com Fri Jun 30 19:36:50 2006 From: GregScott at InfraSupportEtc.com (Greg Scott) Date: Fri Jun 30 20:02:39 2006 Subject: 2.6.17.1 compile error with a netfilter module Message-ID: <925A849792280C4E80C5461017A4B8A206F784@mail733.InfraSupportEtc.com> Hmmm - Here are the POM modules I tried to use: Base connlimit iprange time Extra comment IPMARK ipp2p ROUTE sip-conntrack-nat Of these, the runme script for connlimit, iprange, comment, and IPMARM blew up with errors like this: ./runme --batch connlimit (Blows up with this error: unable to find ladd slot in src /tmp/pom-15223/net/ipv4/netfilter/Makefile (./patchlets/connlimit/linux-2.6.11/./net/ipv4/netfilter/Makefile.ladd) ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y unable to find ladd slot in src /tmp/pom-15223/net/ipv4/netfilter/Makefile (./patchlets/connlimit/linux-2.6.11/./net/ipv4/netfilter/Makefile.ladd) - ./runme --batch iprange (Blows up with the same error as above) # ./runme --batch comment (Blows up and then asks about more modules) ./runme --batch IPMARK (Blows up same as above) Expanding the latest POM dated 20060629, it looks like the latest connlimit is more than a year old. iprange has a linux tree with ipt_iprange.c dated 2003 and another one from 2004 in linux-2.6. comment isn't even in the 20060629 snapshot. The modules for IPMARK look like they are dated Jan 21 of this year. One of the time modules is dated March 29 of this year. Most of the ipp2p modules look like they are dated March 29 of this year. It looks like ROUTE had some ipv6 work recently. The ipv4 stuff is a little bit old. sip-conntrack-nat has a 2.6.13 tree. The modules are dated May and July 2005. I'll try another build, this time with 2.6.17.2 and POM 20060629 using these POM modules: time ipp2p ROUTE sip-conntrack-nat These are the ones that did not generate any errors with the runme script last time. I'll post the results here in a couple of hours. - Greg Scott -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Friday, June 30, 2006 10:28 AM To: Greg Scott Cc: netfilter-devel@lists.netfilter.org Subject: Re: 2.6.17.1 compile error with a netfilter module Greg Scott wrote: > Does anyone know what this means and how to fix it? I know it looks > like a file named lockhelp.h is missing. I guess my question is, what > can I do to fix it? > > With this build, I tried to put in some POM patches from > patch-o-matic-ng-20060624. Could this have been my problem? Yes. It looks like you managed to apply some old 2.4 patches :) If you don't need them I'd suggest to just don't use them. From kernel at linuxace.com Fri Jun 30 22:18:58 2006 From: kernel at linuxace.com (Phil Oester) Date: Fri Jun 30 22:44:52 2006 Subject: [PATCH] icmpv6 match --icmpv6-type confusion Message-ID: <20060630201858.GA5845@linuxace.com> Adding a rule such as this: -A INPUT -p ipv6-icmp -m icmpv6 ends up creating a rule with "ipv6-icmp type 0", instead of "ipv6-icmp type any" which is what was expected. Granted, the match is redundant anyway, but it should not assume a specific type when one is not specified. Below patches (to both kernel and userspace) fix this, and resolve bug #461. In keeping with icmpv4, 0xFF is used to designate "any". And since I was looking at it, I fixed up a 255 -> any in icmpv4 printing. Phil Signed-off-by: Phil Oester -------------- next part -------------- --- linux-std/net/ipv6/netfilter/ip6_tables.c 2006-06-17 21:49:35.000000000 -0400 +++ linux-po/net/ipv6/netfilter/ip6_tables.c 2006-06-29 23:05:09.000000000 -0400 @@ -1308,7 +1308,7 @@ u_int8_t type, u_int8_t code, int invert) { - return (type == test_type && code >= min_code && code <= max_code) + return ((test_type == 0xFF) || (type == test_type && code >= min_code && code <= max_code)) ^ invert; } -------------- next part -------------- diff -ru ipt-orig/extensions/libip6t_icmp6.c ipt-new/extensions/libip6t_icmp6.c --- ipt-orig/extensions/libip6t_icmp6.c 2006-04-14 20:05:41.000000000 -0700 +++ ipt-new/extensions/libip6t_icmp6.c 2006-06-29 18:07:19.000000000 -0700 @@ -149,6 +149,7 @@ { struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)m->data; + icmpv6info->type = 0xFF; icmpv6info->code[1] = 0xFF; } @@ -206,7 +207,12 @@ if (invert) printf("!"); - printf("type %u", type); + /* special hack for 'any' case */ + if (type == 0xFF) + printf("type any "); + else + printf("type %u", type); + if (code_min == 0 && code_max == 0xFF) printf(" "); else if (code_min == code_max) @@ -241,7 +247,12 @@ if (icmpv6->invflags & IP6T_ICMP_INV) printf("! "); - printf("--icmpv6-type %u", icmpv6->type); + /* special hack for 'any' case */ + if (icmpv6->type == 0xFF) + printf("--icmpv6-type any "); + else + printf("--icmpv6-type %u", icmpv6->type); + if (icmpv6->code[0] != 0 || icmpv6->code[1] != 0xFF) printf("/%u", icmpv6->code[0]); printf(" "); diff -ru ipt-orig/extensions/libipt_icmp.c ipt-new/extensions/libipt_icmp.c --- ipt-orig/extensions/libipt_icmp.c 2005-02-14 05:13:04.000000000 -0800 +++ ipt-new/extensions/libipt_icmp.c 2006-06-29 17:57:47.000000000 -0700 @@ -231,7 +231,12 @@ if (invert) printf("!"); - printf("type %u", type); + /* special hack for 'any' case */ + if (type == 0xFF) + printf("type any "); + else + printf("type %u", type); + if (code_min == 0 && code_max == 0xFF) printf(" "); else if (code_min == code_max) From t.luettgert at pressestimmen.de Fri Jun 30 22:54:48 2006 From: t.luettgert at pressestimmen.de (Torsten Luettgert) Date: Fri Jun 30 23:18:21 2006 Subject: 2.6.17.1 compile error with a netfilter module In-Reply-To: <925A849792280C4E80C5461017A4B8A206F784@mail733.InfraSupportEtc.com> References: <925A849792280C4E80C5461017A4B8A206F784@mail733.InfraSupportEtc.com> Message-ID: <1151700888.2709.4.camel@murdegern.hindenburgdamm.example> On Fri, 2006-06-30 at 12:36 -0500, Greg Scott wrote: > Hmmm - > I'll try another build, this time with 2.6.17.2 and POM 20060629 using > these POM > modules: > time > ipp2p > ROUTE > sip-conntrack-nat time, ipp2p and ROUTE won't work with 2.6.17 without API patches - I posted those last saturday, but they didn't get committed yet. You can grab them from the archives. Don't know about sip-conntrack-nat, but I suspect it'll have the same problem. Regards, Torsten From kernel at linuxace.com Fri Jun 30 22:55:02 2006 From: kernel at linuxace.com (Phil Oester) Date: Fri Jun 30 23:20:53 2006 Subject: [PATCH] iptables trivial compile warning cleanup Message-ID: <20060630205502.GA9243@linuxace.com> Cleanup a few compile warnings in latest snapshot: extensions/libipt_dscp_helper.c:69: warning: 'dscp_to_name' defined but not used extensions/libipt_sctp.c: In function 'print_chunks': extensions/libipt_sctp.c:465: warning: value computed is not used extensions/libipt_sctp.c:477: warning: value computed is not used Resolves bug #457. Phil -------------- next part -------------- diff -ru ipt-orig/extensions/libipt_dscp_helper.c ipt-new/extensions/libipt_dscp_helper.c --- ipt-orig/extensions/libipt_dscp_helper.c 2002-08-26 06:09:40.000000000 -0700 +++ ipt-new/extensions/libipt_dscp_helper.c 2006-06-30 13:44:49.000000000 -0700 @@ -63,7 +63,7 @@ } - +#if 0 static const char * dscp_to_name(unsigned int dscp) { @@ -78,5 +78,5 @@ exit_error(PARAMETER_PROBLEM, "Invalid DSCP value `%d'\n", dscp); } - +#endif diff -ru ipt-orig/extensions/libipt_sctp.c ipt-new/extensions/libipt_sctp.c --- ipt-orig/extensions/libipt_sctp.c 2006-02-01 04:58:28.000000000 -0800 +++ ipt-new/extensions/libipt_sctp.c 2006-06-30 13:47:38.000000000 -0700 @@ -462,7 +462,8 @@ flag = 0; for (i = 0; i < 256; i++) { if (SCTP_CHUNKMAP_IS_SET(chunkmap, i)) { - flag && printf(","); + if (flag) + printf(","); flag = 1; print_chunk(i, numeric); for (j = 0; j < flag_count; j++) { @@ -474,7 +475,8 @@ } } - flag && printf(" "); + if (flag) + printf(" "); out: return; } From kernel at linuxace.com Fri Jun 30 23:12:48 2006 From: kernel at linuxace.com (Phil Oester) Date: Fri Jun 30 23:38:38 2006 Subject: [PATCH] libiptc symbols clash Message-ID: <20060630211248.GB9243@linuxace.com> As reported by Dmitry Levin, the TC_NUM_RULES and TC_GET_RULE exports clash. His patch below, resolving bug #456 Phil -------------- next part -------------- diff -ru ipt-orig/libiptc/libip4tc.c ipt-new/libiptc/libip4tc.c --- ipt-orig/libiptc/libip4tc.c 2005-06-23 01:51:18.000000000 -0700 +++ ipt-new/libiptc/libip4tc.c 2006-06-30 14:05:11.000000000 -0700 @@ -94,6 +94,8 @@ #define TC_FREE iptc_free #define TC_COMMIT iptc_commit #define TC_STRERROR iptc_strerror +#define TC_NUM_RULES iptc_num_rules +#define TC_GET_RULE iptc_get_rule #define TC_AF AF_INET #define TC_IPPROTO IPPROTO_IP diff -ru ipt-orig/libiptc/libip6tc.c ipt-new/libiptc/libip6tc.c --- ipt-orig/libiptc/libip6tc.c 2005-06-23 01:51:18.000000000 -0700 +++ ipt-new/libiptc/libip6tc.c 2006-06-30 14:05:30.000000000 -0700 @@ -89,6 +89,8 @@ #define TC_FREE ip6tc_free #define TC_COMMIT ip6tc_commit #define TC_STRERROR ip6tc_strerror +#define TC_NUM_RULES ip6tc_num_rules +#define TC_GET_RULE ip6tc_get_rule #define TC_AF AF_INET6 #define TC_IPPROTO IPPROTO_IPV6 From GregScott at InfraSupportEtc.com Fri Jun 30 23:51:37 2006 From: GregScott at InfraSupportEtc.com (Greg Scott) Date: Sat Jul 1 00:17:31 2006 Subject: 2.6.17.1 compile error with a netfilter module Message-ID: <925A849792280C4E80C5461017A4B8A206F785@mail733.InfraSupportEtc.com> Bummer! My kernel build went error free this time. Took about an hour on a 1Ghz system. Does anyone have an idea when the API patches will be committed? Thanks - Greg -----Original Message----- From: Torsten Luettgert [mailto:t.luettgert@pressestimmen.de] Sent: Friday, June 30, 2006 3:55 PM To: Greg Scott Cc: netfilter-devel@lists.netfilter.org Subject: RE: 2.6.17.1 compile error with a netfilter module On Fri, 2006-06-30 at 12:36 -0500, Greg Scott wrote: > Hmmm - > I'll try another build, this time with 2.6.17.2 and POM 20060629 using > these POM > modules: > time > ipp2p > ROUTE > sip-conntrack-nat time, ipp2p and ROUTE won't work with 2.6.17 without API patches - I posted those last saturday, but they didn't get committed yet. You can grab them from the archives. Don't know about sip-conntrack-nat, but I suspect it'll have the same problem. Regards, Torsten From sliddicott at dbamsystems.com Fri Jun 30 14:51:30 2006 From: sliddicott at dbamsystems.com (Sam Liddicott) Date: Wed Jul 5 14:16:58 2006 Subject: xtables Re: Hacking iptables 1.3.5 for 2.6.17 In-Reply-To: <44A51BCB.7090006@ufomechanic.net> References: <200606300948.k5U9mNot001866@toshiba.co.jp> <44A50091.7070003@ufomechanic.net> <200606301157.k5UBvJTl016149@toshiba.co.jp> <44A51BCB.7090006@ufomechanic.net> Message-ID: <44A51E52.7000006@dbamsystems.com> Amin Azez wrote: > Yasuyuki KOZAKAI wrote: > >> As you says, netfilter_ipv4.h in 2.6.17.x has unnecessary >> '#include ' outside of __KERNEL__. But it seemd to be deleted >> in recent kernel as follows. >> >> >>> commit 62c4f0a2d5a188f73a94f2cb8ea0dba3e7cf0a7f >>> Author: David Woodhouse >>> Date: Wed Apr 26 12:56:16 2006 +0100 >>> >>> Don't include linux/config.h from anywhere else in include/ >>> >>> Signed-off-by: David Woodhouse >>> >> I don't think/know that this goes to stable tree, though. >> > > Thanks; thats helpful and also solves a long-standing puzzlement for me. > (Into my quilt stack it goes) > > Next question relates to the port to xtables and friends, and what I > need to do to convert iptables targets. > > I notice a lot of things have moved to net/netfilter/xt_*.c > > Is this an absolute requirement, or is there some compatability system? > Sorry for this foolish question; I have the answer just by diffing what is left in net/ipv4/netfilter/ with earlier kernels please forgive my laziness. Sam From pierre-yves at spootnik.org Fri Jun 30 17:38:02 2006 From: pierre-yves at spootnik.org (Pierre-Yves Ritschard) Date: Wed Jul 5 14:16:59 2006 Subject: [PATCH] please kill santa-claus Message-ID: <20060630153802.GA27351@phoenix.home.spootnik.org> Hi, While running our home-brewed firewall scripts the output was broken by a weird message spewed by the libipt_iprange extension: "hoho" (sic) I wonder why that is, it seems not too many people noticed or use src-range inversion which is the feature that triggers this friendly yet surprising message. If there's a specific reason (which I haven't found in TFA or google) please let me know, otherwise please consider this one-liner: --- extensions/libipt_iprange.c.orig Fri Jun 30 17:34:05 2006 +++ extensions/libipt_iprange.c Fri Jun 30 17:34:21 2006 @@ -73,7 +73,6 @@ check_inverse(optarg, &invert, &optind, 0); if (invert) { info->flags |= IPRANGE_SRC_INV; - printf("hoho\n"); } parse_iprange(optarg, &info->src); Thanks for your time, pyr