From bunk at stusta.de Sat Apr 1 11:18:47 2006 From: bunk at stusta.de (Adrian Bunk) Date: Sat Apr 1 11:34:41 2006 Subject: netfilter: IP_NF_CONNTRACK_NETLINK=y, IP_NF_NAT=m compile error In-Reply-To: <20060331170916.GL28030@miggy.org> References: <20060328163932.GJ28030@miggy.org> <20060331170916.GL28030@miggy.org> Message-ID: <20060401091847.GC28310@stusta.de> On Fri, Mar 31, 2006 at 06:09:16PM +0100, Athanasius wrote: > On Tue, Mar 28, 2006 at 05:39:32PM +0100, Athanasius wrote: > > CC init/version.o > > LD init/built-in.o > > LD .tmp_vmlinux1 > > net/built-in.o(.text+0x7c990): In function `ctnetlink_parse_nat_proto': > > : undefined reference to `ip_nat_proto_find_get' > > net/built-in.o(.text+0x7c9b2): In function `ctnetlink_parse_nat_proto': > > : undefined reference to `ip_nat_proto_put' > > net/built-in.o(.text+0x7d695): In function `ctnetlink_change_conntrack': > > : undefined reference to `ip_nat_setup_info' > > net/built-in.o(.text+0x7da9f): In function `ctnetlink_create_conntrack': > > : undefined reference to `ip_nat_setup_info' > > make: *** [.tmp_vmlinux1] Error 1 > ... > > CONFIG_IP_NF_TARGET_TCPMSS=m > > CONFIG_IP_NF_NAT=m > > CONFIG_IP_NF_NAT_NEEDED=y > > CONFIG_IP_NF_TARGET_MASQUERADE=m > > ... > > It looks like the problem was that "CONFIG_IP_NF_NAT=m". I changed > this to 'y' and things look to be compiling fine now. >... First of all thanks for your report. More exactly, it's the combination CONFIG_IP_NF_CONNTRACK_NETLINK=y, CONFIG_IP_NF_NAT=m. Can someone who understands the netfilter dependencies please look into this bug? It's present in both 2.6.16.1 and 2.6.16-mm2. > -Ath cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From beunlovable at gmail.com Sat Apr 1 12:36:00 2006 From: beunlovable at gmail.com (David Vogt) Date: Sat Apr 1 12:51:43 2006 Subject: Regarding LIBIPQ problem In-Reply-To: <1411.10.12.25.5.1143825446.squirrel@gpo.iitb.ac.in> References: <1411.10.12.25.5.1143825446.squirrel@gpo.iitb.ac.in> Message-ID: <859616420604010236j1048f16anbe3edaa8b6967244@mail.gmail.com> 2006/3/31, Vasantha Kumar Puttappa : > Then I am setting the verdict as accept ,shown below > > status = ipq_set_verdict(h, m->packet_id,NF_ACCEPT, new_iphdr->tot_len, > (unsigned char *)packet); Shouldn't this look like this (ntohs missing?): status = ipq_set_verdict( h, m->packet_id,NF_ACCEPT, ntohs(new_iphdr->tot_len), (unsigned char *)packet ); > Problem: > Even though ipq_set_verdict is being executed successfully, the new > packets are being dropped silently without any error message. If the value is not interpreted correctly, the length value might be negative or too large and thus the packet gets dropped. Was the first thing that came to my mind. Tought I give it a shot. Regards, David From laforge at netfilter.org Sat Apr 1 21:31:38 2006 From: laforge at netfilter.org (Harald Welte) Date: Sat Apr 1 21:47:57 2006 Subject: [PATCH 4/4] first conntrack ID must be 1 not 2 In-Reply-To: <442D78A8.4050300@trash.net> References: <43F43FA9.4000906@trash.net> <43F4426D.9060807@trash.net> <43F4DBDF.9010008@trash.net> <442B9765.2020105@ufomechanic.net> <442C81A6.3040501@trash.net> <442D78A8.4050300@trash.net> Message-ID: <20060401193138.GG11031@sunbeam.de.gnumonks.org> On Fri, Mar 31, 2006 at 08:44:56PM +0200, Patrick McHardy wrote: > Me neither :) I was just pointing out the idea behind the ID, not > necessarily condoning it. After discussing it with Rusty in Sevilla, > it became clear that we can provide guarantees similar to filesystems > without it, which seems to be good enough. So I have absolutely > nothing against removing it. In fact, IIRC the last discussion > stopped after I had sent a patch to remove it. I need to dig out that > patch again :) I didn't contribute to any of these discussions anymore, since I already made my opinion on this quite clear very early on: I don't have any problem whatsoever with non-uniqueness ;) So if there's now a majority of people who want to delete the ID: Go for it :) -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060401/dfd95ac9/attachment.pgp From vasanthakumar at iitb.ac.in Sun Apr 2 13:48:28 2006 From: vasanthakumar at iitb.ac.in (Vasantha Kumar Puttappa) Date: Sun Apr 2 14:04:44 2006 Subject: Regarding LIBIPQ problem In-Reply-To: <859616420604010236j1048f16anbe3edaa8b6967244@mail.gmail.com> References: <1411.10.12.25.5.1143825446.squirrel@gpo.iitb.ac.in> <859616420604010236j1048f16anbe3edaa8b6967244@mail.gmail.com> Message-ID: <4854.10.12.25.5.1143978508.squirrel@gpo.iitb.ac.in> Hi David, Thanx for your response. Actually I did use "ntohs" in the actual code. Anyhow I tested same code in kernel-2.6.11-6mdk and it's working fine, although i am receiving multiple copies at the receiver. Do you have any idea of kernel version in which "libipq" works properly withoug any problem. ------- Vasanth > 2006/3/31, Vasantha Kumar Puttappa : >> Then I am setting the verdict as accept ,shown below >> >> status = ipq_set_verdict(h, m->packet_id,NF_ACCEPT, new_iphdr->tot_len, >> (unsigned char *)packet); > Shouldn't this look like this (ntohs missing?): > > status ipq_set_verdict( > h, m->packet_id,NF_ACCEPT, ntohs(new_iphdr->tot_len), (unsigned > char *)packet > ); > > >> Problem: >> Even though ipq_set_verdict is being executed successfully, the new >> packets are being dropped silently without any error message. > If the value is not interpreted correctly, the length value might be > negative or too large and thus the packet gets dropped. > > Was the first thing that came to my mind. Tought I give it a shot. > > Regards, > David > From kaber at trash.net Sun Apr 2 21:19:30 2006 From: kaber at trash.net (Patrick McHardy) Date: Sun Apr 2 21:35:26 2006 Subject: bridge+netfilter broken for IP fragments in 2.6.16? In-Reply-To: <20060401143011.GA28333@swan.nt.tuwien.ac.at> References: <20060401143011.GA28333@swan.nt.tuwien.ac.at> Message-ID: <443023C2.6020401@trash.net> Thomas Zeitlhofer wrote: > I have set up a bridge with two ports: > > # brctl show br0 > bridge name bridge id STP enabled interfaces > br0 8000.000021f23d58 no eth1 > tap1 > > Using 2.6.16/.1 non fragmented IP packets are passing the bridge without > problems, but fragmented IP packets do not show up on the outgoing > interface. E.g., for fragmented traffic coming in from tap1 and going > out via eth1 tcpdump shows: > > 1) on tap1: fragmented packets > 2) on br0: the defragmented packet (connection tracking) > 3) on eth1: no packet!? > > This breaks IPsec connections for example. > > > Doing the same on 2.6.15.x shows: > > 1) on tap1: fragmented packets > 2) on br0: the defragmented packet (connection tracking) > 3) on eth1: fragmented packets Are you sure this is correct? I think in 2.6.15 you should see the fragments on br0 already. Anyway, since 2.6.16 ip_conntrack doesn't do refragmentation anymore but relies on fragmentation in the IP layer. Purely bridged packets don't go through the IP layer, so the bridge netfilter code needs to take care of fragmentation itself. Please try if this patch helps. > and IPsec connections are ok. This is probably a different issue. Please describe your setup (IPsec, NAT and filtering). -------------- next part -------------- [NETFILTER]: Fix fragmentation issues with bridge netfilter The conntrack code doesn't do re-fragmentation of defragmented packets anymore but relies on fragmentation in the IP layer. Purely bridged packets don't pass through the IP layer, so the bridge netfilter code needs to take care of fragmentation itself. Signed-off-by: Patrick McHardy --- commit 1e6bb6c683e418cf4ae6f69b7005edcfe29bc882 tree 2b7e567935658cee4ec169dab56ff8fd592c2d36 parent 9a1875e60e61b563737d8d1fc3876b279710fe93 author Patrick McHardy Sun, 02 Apr 2006 21:17:14 +0200 committer Patrick McHardy Sun, 02 Apr 2006 21:17:14 +0200 include/net/ip.h | 1 + net/bridge/br_netfilter.c | 13 +++++++++++-- net/ipv4/ip_output.c | 4 +--- 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/include/net/ip.h b/include/net/ip.h index 8fe6156..3d2e5ca 100644 --- a/include/net/ip.h +++ b/include/net/ip.h @@ -95,6 +95,7 @@ extern int ip_local_deliver(struct sk_b extern int ip_mr_input(struct sk_buff *skb); extern int ip_output(struct sk_buff *skb); extern int ip_mc_output(struct sk_buff *skb); +extern int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *)); extern int ip_do_nat(struct sk_buff *skb); extern void ip_send_check(struct iphdr *ip); extern int ip_queue_xmit(struct sk_buff *skb, int ipfragok); diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c index f29450b..3da9264 100644 --- a/net/bridge/br_netfilter.c +++ b/net/bridge/br_netfilter.c @@ -765,6 +765,15 @@ out: return NF_STOLEN; } +static int br_nf_dev_queue_xmit(struct sk_buff *skb) +{ + if (skb->protocol == htons(ETH_P_IP) && + skb->len > skb->dev->mtu && + !(skb_shinfo(skb)->ufo_size || skb_shinfo(skb)->tso_size)) + return ip_fragment(skb, br_dev_queue_push_xmit); + else + return br_dev_queue_push_xmit(skb); +} /* PF_BRIDGE/POST_ROUTING ********************************************/ static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb, @@ -824,7 +833,7 @@ static unsigned int br_nf_post_routing(u realoutdev = nf_bridge->netoutdev; #endif NF_HOOK(pf, NF_IP_POST_ROUTING, skb, NULL, realoutdev, - br_dev_queue_push_xmit); + br_nf_dev_queue_xmit); return NF_STOLEN; @@ -869,7 +878,7 @@ static unsigned int ip_sabotage_out(unsi if ((out->hard_start_xmit == br_dev_xmit && okfn != br_nf_forward_finish && - okfn != br_nf_local_out_finish && okfn != br_dev_queue_push_xmit) + okfn != br_nf_local_out_finish && okfn != br_nf_dev_queue_xmit) #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) || ((out->priv_flags & IFF_802_1Q_VLAN) && VLAN_DEV_INFO(out)->real_dev->hard_start_xmit == br_dev_xmit) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index f75ff1d..af6a106 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -86,8 +86,6 @@ int sysctl_ip_default_ttl = IPDEFTTL; -static int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*)); - /* Generate a checksum for an outgoing IP datagram. */ __inline__ void ip_send_check(struct iphdr *iph) { @@ -421,7 +419,7 @@ static void ip_copy_metadata(struct sk_b * single device frame, and queue such a frame for sending. */ -static int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*)) +int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*)) { struct iphdr *iph; int raw = 0; From kaber at trash.net Mon Apr 3 01:11:46 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Apr 3 01:30:02 2006 Subject: bridge+netfilter broken for IP fragments in 2.6.16? In-Reply-To: <20060402225625.GA22612@swan.nt.tuwien.ac.at> References: <20060401143011.GA28333@swan.nt.tuwien.ac.at> <443023C2.6020401@trash.net> <20060402225625.GA22612@swan.nt.tuwien.ac.at> Message-ID: <44305A32.1010109@trash.net> Thomas Zeitlhofer wrote: > On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote: > >>>Doing the same on 2.6.15.x shows: >>> >>> 1) on tap1: fragmented packets >>> 2) on br0: the defragmented packet (connection tracking) >>> 3) on eth1: fragmented packets >> >>Are you sure this is correct? I think in 2.6.15 you should see >>the fragments on br0 already. > > > Just verified it, at least in 2.6.15.6 tcpdump shows the defragmented > packet on br0. I'm probably missing something, but that still seems stange. Are you also seeing the defragmented packet on br0 with my patch? >>Anyway, since 2.6.16 ip_conntrack doesn't do refragmentation anymore >>but relies on fragmentation in the IP layer. Purely bridged packets >>don't go through the IP layer, so the bridge netfilter code needs to >>take care of fragmentation itself. Please try if this patch helps. > > > Your patch solves the problem - tcpdump now shows the refragmented > packets on eth1. Thanks for the quick solution. > > Just a note, your patch does not work when bridge is compiled as a > module. In this case modprobe failes with "bridge: Unknown symbol > ip_fragment". Using CONFIG_BRIDGE=y works. Thanks, I missed that the Makefile adds br_netfilter.o to bridge-$(CONFIG_BRIDGE_NETFILTER), not obj-$(...). From laforge at netfilter.org Mon Apr 3 09:23:51 2006 From: laforge at netfilter.org (Harald Welte) Date: Mon Apr 3 09:40:22 2006 Subject: [ADM] netfilter.org scheduled downtime Message-ID: <20060403072351.GA19925@sunbeam.de.gnumonks.org> Hi! Starting at 10am GMT today, April 1st 2006 netfilter.org/gnumonks.org will experience a multi-hour administrative downtime. All machines ({vishnu,lakshmi,durga}.netfilter.org,ganesha.gnumonks.org} will be moved to a different rack for thermal reasons. In addition, one new machine will be placed (parvati.netfilter.org) next to them in the new rack. For www access, I suggest using one of our many mirrors, reachable under their individual www.CCTLD.netfilter.org or as a round-robin dns record mirror.netfilter.org. svn, bugzilla, mailinglists and other services will be unreachable, sorry. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060403/d8dede0d/attachment.pgp From beunlovable at gmail.com Mon Apr 3 10:42:37 2006 From: beunlovable at gmail.com (David Vogt) Date: Mon Apr 3 10:58:34 2006 Subject: Regarding LIBIPQ problem In-Reply-To: <4854.10.12.25.5.1143978508.squirrel@gpo.iitb.ac.in> References: <1411.10.12.25.5.1143825446.squirrel@gpo.iitb.ac.in> <859616420604010236j1048f16anbe3edaa8b6967244@mail.gmail.com> <4854.10.12.25.5.1143978508.squirrel@gpo.iitb.ac.in> Message-ID: <859616420604030142x4a0f0ddfh46214e4a8c448a0b@mail.gmail.com> 2006/4/2, Vasantha Kumar Puttappa : > Anyhow I tested same code in kernel-2.6.11-6mdk and it's working fine, > although i am receiving multiple copies at the receiver. Multiple copies is strange as well, isn't it? > Do you have any idea of kernel version in which "libipq" works properly > withoug any problem. Not really, I am pretty sure I ran similar stuff on 2.4 kernels. Furthermore I am currently using 2.6.12 (part of Fedora Core 3... the kernel is called 2.6.12-1.1381_FC3 there) and do not encounter any problems. David From bdschuym at pandora.be Mon Apr 3 20:12:24 2006 From: bdschuym at pandora.be (Bart De Schuymer) Date: Mon Apr 3 20:28:20 2006 Subject: [NETFILTER]: Fix fragmentation issues with bridge netfilter In-Reply-To: <44312671.3090904@trash.net> References: <44312671.3090904@trash.net> Message-ID: <1144087944.3024.5.camel@localhost.localdomain> Op ma, 03-04-2006 te 15:43 +0200, schreef Patrick McHardy: > Fix a regression from the netfilter/IPsec patches with bridging. > Bart, please review this patch, if everything is fine I think it > should also go in -stable. Looks fine to me. Thanks, Bart From kaber at trash.net Mon Apr 3 20:12:58 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Apr 3 20:29:08 2006 Subject: Patch-o-matic cleanup Message-ID: <443165AA.4030509@trash.net> Following (quite late) the decision taken at the netfilter workshop to clean up the pomng repository by removing old patches and moving some patches out of the netfilter repository, I've started by removing the obsolete ipsec* patches and the policy match. Both have been merged and were pretty outdated. If noone can name good reasons against it, I will also remove the following patches in a few days: - NETLINK: obsolete - NETMAP: in mainline for a long time - TRACE: don't recall the reason, but its on my list :) - comment: in mainline - conntrack_locking: seriously outdated, if someone wants to resurrect this patch he can use the history - dropped_table: also don't recall the reason - goto: in mainline - ipq_vmark: obsoleted by nfnetlink_queue - mport: mainline multiport supports all of its features - netfilter-docbook: outdated - owner-socketlookup: unfixable broken - pool: obsoleted by ipset - pptp-conntrack-nat: in mainline now, patches are missing critical fixes - unclean: bad idea From kaber at trash.net Mon Apr 3 15:43:13 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Apr 3 20:52:58 2006 Subject: [NETFILTER]: Fix fragmentation issues with bridge netfilter Message-ID: <44312671.3090904@trash.net> Fix a regression from the netfilter/IPsec patches with bridging. Bart, please review this patch, if everything is fine I think it should also go in -stable. -------------- next part -------------- [NETFILTER]: Fix fragmentation issues with bridge netfilter The conntrack code doesn't do re-fragmentation of defragmented packets anymore but relies on fragmentation in the IP layer. Purely bridged packets don't pass through the IP layer, so the bridge netfilter code needs to take care of fragmentation itself. Signed-off-by: Patrick McHardy --- commit 5d7b9a2f312fa867fa99adc5fd9cfb6d841f6fb6 tree 6a63c9cfe9804aa9d8050a14f8c6aed6ba1fbf84 parent 683aa4012f53b2ada0f430487e05d37b0d94e90a author Patrick McHardy Mon, 03 Apr 2006 11:58:33 +0200 committer Patrick McHardy Mon, 03 Apr 2006 11:58:33 +0200 include/net/ip.h | 1 + net/bridge/br_netfilter.c | 13 +++++++++++-- net/ipv4/ip_output.c | 6 +++--- 3 files changed, 15 insertions(+), 5 deletions(-) diff --git a/include/net/ip.h b/include/net/ip.h index 8fe6156..3d2e5ca 100644 --- a/include/net/ip.h +++ b/include/net/ip.h @@ -95,6 +95,7 @@ extern int ip_local_deliver(struct sk_b extern int ip_mr_input(struct sk_buff *skb); extern int ip_output(struct sk_buff *skb); extern int ip_mc_output(struct sk_buff *skb); +extern int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *)); extern int ip_do_nat(struct sk_buff *skb); extern void ip_send_check(struct iphdr *ip); extern int ip_queue_xmit(struct sk_buff *skb, int ipfragok); diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c index f29450b..3da9264 100644 --- a/net/bridge/br_netfilter.c +++ b/net/bridge/br_netfilter.c @@ -765,6 +765,15 @@ out: return NF_STOLEN; } +static int br_nf_dev_queue_xmit(struct sk_buff *skb) +{ + if (skb->protocol == htons(ETH_P_IP) && + skb->len > skb->dev->mtu && + !(skb_shinfo(skb)->ufo_size || skb_shinfo(skb)->tso_size)) + return ip_fragment(skb, br_dev_queue_push_xmit); + else + return br_dev_queue_push_xmit(skb); +} /* PF_BRIDGE/POST_ROUTING ********************************************/ static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb, @@ -824,7 +833,7 @@ static unsigned int br_nf_post_routing(u realoutdev = nf_bridge->netoutdev; #endif NF_HOOK(pf, NF_IP_POST_ROUTING, skb, NULL, realoutdev, - br_dev_queue_push_xmit); + br_nf_dev_queue_xmit); return NF_STOLEN; @@ -869,7 +878,7 @@ static unsigned int ip_sabotage_out(unsi if ((out->hard_start_xmit == br_dev_xmit && okfn != br_nf_forward_finish && - okfn != br_nf_local_out_finish && okfn != br_dev_queue_push_xmit) + okfn != br_nf_local_out_finish && okfn != br_nf_dev_queue_xmit) #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) || ((out->priv_flags & IFF_802_1Q_VLAN) && VLAN_DEV_INFO(out)->real_dev->hard_start_xmit == br_dev_xmit) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index f75ff1d..8dcba38 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -86,8 +86,6 @@ int sysctl_ip_default_ttl = IPDEFTTL; -static int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*)); - /* Generate a checksum for an outgoing IP datagram. */ __inline__ void ip_send_check(struct iphdr *iph) { @@ -421,7 +419,7 @@ static void ip_copy_metadata(struct sk_b * single device frame, and queue such a frame for sending. */ -static int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*)) +int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff*)) { struct iphdr *iph; int raw = 0; @@ -673,6 +671,8 @@ fail: return err; } +EXPORT_SYMBOL(ip_fragment); + int ip_generic_getfrag(void *from, char *to, int offset, int len, int odd, struct sk_buff *skb) { From hivemynd at hivemynd.net Tue Apr 4 08:26:16 2006 From: hivemynd at hivemynd.net (Stephen Jones) Date: Tue Apr 4 08:42:30 2006 Subject: Patch-o-matic cleanup In-Reply-To: <443165AA.4030509@trash.net> References: <443165AA.4030509@trash.net> Message-ID: <44321188.30902@hivemynd.net> Patrick McHardy wrote: > Following (quite late) the decision taken at the netfilter workshop to > clean up the pomng repository by removing old patches and moving some > patches out of the netfilter repository, I've started by removing the > obsolete ipsec* patches and the policy match. Both have been merged > and were pretty outdated. > > If noone can name good reasons against it, I will also remove the > following patches in a few days: > < snip > > - pptp-conntrack-nat: in mainline now, patches are missing critical > fixes Hi Patrick, Is pptp-conntrack-nat functionality going to be included in the 2.4.x mainline also? Otherwise, the patches still appear to be necessary for 2.4.x kernels. Thanks for all of your hard work! SJ > - unclean: bad idea > > > From olenf at ans.pl Tue Apr 4 10:04:47 2006 From: olenf at ans.pl (Krzysztof Oledzki) Date: Tue Apr 4 10:20:59 2006 Subject: Patch-o-matic cleanup In-Reply-To: <443165AA.4030509@trash.net> References: <443165AA.4030509@trash.net> Message-ID: On Mon, 3 Apr 2006, Patrick McHardy wrote: > Following (quite late) the decision taken at the netfilter workshop to > clean up the pomng repository by removing old patches and moving some > patches out of the netfilter repository, I've started by removing the > obsolete ipsec* patches and the policy match. Both have been merged > and were pretty outdated. > > If noone can name good reasons against it, I will also remove the > following patches in a few days: > - goto: in mainline Not in 2.4 and version from pom-ng is 2.4-only. Best regards, Krzysztof Ol?dzki From eric at inl.fr Tue Apr 4 10:33:39 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Apr 4 10:49:44 2006 Subject: [PATCH 0/3] [RFC] fixed duration connection Message-ID: <1144139619.5186.24.camel@localhost.localdomain> Hi, While working on NuFW development branch, we have had to implement policy just as : * connection to server is authorised from 08h to 18h and connection must be switched off at 18h. Such features are frequently asked by customers or netfilter addicts but even with current conntrack related code, it can not be done cleanly. Thus, we've added the notion of fixed duration before expiration to connection in the conntrack. (See extended information on bottom for details) The following set of patches is against kernel (linus git tree), libnetfilter_conntrack, and conntrack tool. -- Extended -- When trying to implement this feature with current connection tracking code, we have faced some issues : 1. userspace code has to duplicate conntrack entries, thus it's complex and uses memory 2. there is no hope to have it done by a simple command line (because of 1.) 3. if replication of conntrack in userspace is needed there will be many synchronisation problems : stop and start of an hypothetical "expiration" daemon would cause conntrack duplication and/or loss of information ... For this reason, we've worked on a simple kernel level implementation. This is done via a second "struct timer" that is added in connection structure. Activation of the timer, is for now done via userspace by using libnetfilter_conntrack or by using new option -T of the conntrack tool. This kernel implementation could easily lead to a new iptables target in the future. This is a resend of patch : http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3289 It adds support for nf_conntrack. Best regards, -- Eric Leblond for the NuFW Core Team NuFW : http://www.nufw.org/ -------------- 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/20060404/f5655a70/attachment.pgp From eric at inl.fr Tue Apr 4 10:36:26 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Apr 4 10:52:32 2006 Subject: [PATCH 1/3] fixed duration connection In-Reply-To: <1144139619.5186.24.camel@localhost.localdomain> References: <1144139619.5186.24.camel@localhost.localdomain> Message-ID: <1144139786.5186.28.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/20060404/e6336787/attachment.pgp From kaber at trash.net Tue Apr 4 10:38:04 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Apr 4 10:56:36 2006 Subject: Patch-o-matic cleanup In-Reply-To: <44321188.30902@hivemynd.net> References: <443165AA.4030509@trash.net> <44321188.30902@hivemynd.net> Message-ID: <4432306C.10106@trash.net> Stephen Jones wrote: > Patrick McHardy wrote: > >> - pptp-conntrack-nat: in mainline now, patches are missing critical >> fixes > > Hi Patrick, > > Is pptp-conntrack-nat functionality going to be included in the 2.4.x > mainline also? Otherwise, the patches still appear to be necessary for > 2.4.x kernels. No, 2.4 is in absolute stable mode. The pptp patches for 2.4 are missing a number of important bugfixes, I wouldn't recommend using them in their present form. We don't have the time to maintain old versions forever, which is why we decided to remove this old stuff. From eric at inl.fr Tue Apr 4 10:43:03 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Apr 4 10:59:09 2006 Subject: [PATCH 2/3] fixed duration connection In-Reply-To: <1144139619.5186.24.camel@localhost.localdomain> References: <1144139619.5186.24.camel@localhost.localdomain> Message-ID: <1144140183.5186.36.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/20060404/bab8c9c2/attachment-0001.pgp From eric at inl.fr Tue Apr 4 10:43:26 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Apr 4 10:59:31 2006 Subject: [PATCH 3/3] [RFC] fixed duration connection In-Reply-To: <1144139619.5186.24.camel@localhost.localdomain> References: <1144139619.5186.24.camel@localhost.localdomain> Message-ID: <1144140206.5186.38.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/20060404/c87d02e5/attachment.pgp From samueldg at arcoscom.com Tue Apr 4 10:54:43 2006 From: samueldg at arcoscom.com (Samuel =?iso-8859-1?Q?D=EDaz_Garc=EDa?=) Date: Tue Apr 4 11:10:47 2006 Subject: Patch-o-matic cleanup In-Reply-To: <443165AA.4030509@trash.net> References: <443165AA.4030509@trash.net> Message-ID: <40106.195.55.244.106.1144140883.squirrel@www.arcoscom.com> Patrick, after the last "cleanup" (18/9/2005?), many patches were removed and 2.4/2.6 compatibility broken, for example the "condition" match over 2.6 or CONNMARK over 2.4. I think, that if devteam are going to invert time to "cleanup" pomng, would be fantastic that old ussefull and broken patches (or teorically merged into kernel main base) must be reviewed. For example, you put pptp_conntrack to be deleted, but I used it into 2.4 kernel versions, where it isn't into mainline. That are the ticks I think you will need to take care of. Good work, regards. -- Samuel D?az Garc?a ArcosCom Wireless, S.L.L. CIF: B11828068 c/ Romero Gago, 19 Arcos de la Frontera 11630 - Cadiz http://www.arcoscom.com mailto:samueldg@arcoscom.com msn: samueldg@arcoscom.com Tlfn.: 956 70 13 15 Fax: 956 70 34 83 El Lun, 3 de Abril de 2006, 20:12, Patrick McHardy escribi?: > Following (quite late) the decision taken at the netfilter workshop to > clean up the pomng repository by removing old patches and moving some > patches out of the netfilter repository, I've started by removing the > obsolete ipsec* patches and the policy match. Both have been merged > and were pretty outdated. > > If noone can name good reasons against it, I will also remove the > following patches in a few days: > > - NETLINK: obsolete > - NETMAP: in mainline for a long time > - TRACE: don't recall the reason, but its on my list :) > - comment: in mainline > - conntrack_locking: seriously outdated, if someone wants to resurrect > this patch he can use the history > - dropped_table: also don't recall the reason > - goto: in mainline > - ipq_vmark: obsoleted by nfnetlink_queue > - mport: mainline multiport supports all of its features > - netfilter-docbook: outdated > - owner-socketlookup: unfixable broken > - pool: obsoleted by ipset > - pptp-conntrack-nat: in mainline now, patches are missing critical > fixes > - unclean: bad idea > > From c-d.hailfinger.devel.2006 at gmx.net Tue Apr 4 11:19:27 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue Apr 4 11:35:30 2006 Subject: Patch-o-matic cleanup In-Reply-To: <443165AA.4030509@trash.net> References: <443165AA.4030509@trash.net> Message-ID: <44323A1F.3010803@gmx.net> Hi, Patrick McHardy schrieb: > If noone can name good reasons against it, I will also remove the > following patches in a few days: > > - unclean: bad idea Please leave that one in. I know it's a bad idea, but in non-production setups LOGging all packets matched by unclean gives interesting insights into network traffic. So it's a valuable educational tool. Regards, Carl-Daniel -- http://www.hailfinger.org/ From ncunningham at cyclades.com Sat Apr 1 14:24:23 2006 From: ncunningham at cyclades.com (Nigel Cunningham) Date: Tue Apr 4 14:28:48 2006 Subject: Compilation warnings in the current git tree. Message-ID: <200604012224.29745.ncunningham@cyclades.com> Hi all. Previous comment not-withstanding, there are some issues I found with current git. Apologies to anyone wrongly cc'd :) Hope this helps. Regards, Nigel WARNING: vmlinux: 'strlen' exported twice. Previous export was in vmlinux WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x2449) and 'acpi_processor_power_exit' WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x0) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x8) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x10) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x18) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x20) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x28) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x30) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x38) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x40) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x48) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x50) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x58) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x60) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x68) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x70) WARNING: drivers/scsi/sd_mod.o - Section mismatch: reference to .exit.text: from .rodata after '' (at offset 0x78) WARNING: net/ipv4/netfilter/ip_conntrack.o - Section mismatch: reference to .init.text:ip_conntrack_init from .text between 'init_or_cleanup' (at offset 0x6ad) and '__hash_conntrack' -------------- 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/20060401/08b83cd7/attachment-0001.pgp From quaker at pandora.barbara.ds.polsl.gliwice.pl Sat Apr 1 18:53:47 2006 From: quaker at pandora.barbara.ds.polsl.gliwice.pl (Piotr Gasidlo) Date: Tue Apr 4 14:28:48 2006 Subject: ipt_account match update Message-ID: <20060401165347.GA4848@barbara.eu.org> 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: Digital signature Url : /pipermail/netfilter-devel/attachments/20060401/4baff879/attachment-0001.pgp From thomas.zeitlhofer at nt.tuwien.ac.at Mon Apr 3 00:56:25 2006 From: thomas.zeitlhofer at nt.tuwien.ac.at (Thomas Zeitlhofer) Date: Tue Apr 4 14:28:49 2006 Subject: bridge+netfilter broken for IP fragments in 2.6.16? In-Reply-To: <443023C2.6020401@trash.net> References: <20060401143011.GA28333@swan.nt.tuwien.ac.at> <443023C2.6020401@trash.net> Message-ID: <20060402225625.GA22612@swan.nt.tuwien.ac.at> On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote: > Thomas Zeitlhofer wrote: > > I have set up a bridge with two ports: > > > > # brctl show br0 > > bridge name bridge id STP enabled interfaces > > br0 8000.000021f23d58 no eth1 > > tap1 > > > > Using 2.6.16/.1 non fragmented IP packets are passing the bridge without > > problems, but fragmented IP packets do not show up on the outgoing > > interface. E.g., for fragmented traffic coming in from tap1 and going > > out via eth1 tcpdump shows: > > > > 1) on tap1: fragmented packets > > 2) on br0: the defragmented packet (connection tracking) > > 3) on eth1: no packet!? > > > > This breaks IPsec connections for example. > > > > > > Doing the same on 2.6.15.x shows: > > > > 1) on tap1: fragmented packets > > 2) on br0: the defragmented packet (connection tracking) > > 3) on eth1: fragmented packets > > Are you sure this is correct? I think in 2.6.15 you should see > the fragments on br0 already. Just verified it, at least in 2.6.15.6 tcpdump shows the defragmented packet on br0. > Anyway, since 2.6.16 ip_conntrack doesn't do refragmentation anymore > but relies on fragmentation in the IP layer. Purely bridged packets > don't go through the IP layer, so the bridge netfilter code needs to > take care of fragmentation itself. Please try if this patch helps. Your patch solves the problem - tcpdump now shows the refragmented packets on eth1. Thanks for the quick solution. Just a note, your patch does not work when bridge is compiled as a module. In this case modprobe failes with "bridge: Unknown symbol ip_fragment". Using CONFIG_BRIDGE=y works. > > and IPsec connections are ok. > > This is probably a different issue. I don't think so, with your patch IPsec connection can be established again. The problem was that racoon generates UDP packets of length 2600 during isakmp phase 1 which did not pass the bridge. > Please describe your setup (IPsec, NAT and filtering). The setup here is UML behind tap1 where br0 is used to bridge the physical interface (eth1) to the UML's eth0 (=> tap1). The IPsec connection is going from the UML to the outside world over the bridge. NAT is not used and at the moment filtering is just used for accounting. So nothing special, only two rules in the FORWARD chain that accept all traffic in both directions. -- Thomas From thomas.zeitlhofer at nt.tuwien.ac.at Mon Apr 3 01:36:53 2006 From: thomas.zeitlhofer at nt.tuwien.ac.at (Thomas Zeitlhofer) Date: Tue Apr 4 14:28:50 2006 Subject: bridge+netfilter broken for IP fragments in 2.6.16? In-Reply-To: <44305A32.1010109@trash.net> References: <20060401143011.GA28333@swan.nt.tuwien.ac.at> <443023C2.6020401@trash.net> <20060402225625.GA22612@swan.nt.tuwien.ac.at> <44305A32.1010109@trash.net> Message-ID: <20060402233653.GA30271@swan.nt.tuwien.ac.at> On Mon, Apr 03, 2006 at 01:11:46AM +0200, Patrick McHardy wrote: > Thomas Zeitlhofer wrote: > > On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote: > > > >>>Doing the same on 2.6.15.x shows: > >>> > >>> 1) on tap1: fragmented packets > >>> 2) on br0: the defragmented packet (connection tracking) > >>> 3) on eth1: fragmented packets > >> > >>Are you sure this is correct? I think in 2.6.15 you should see > >>the fragments on br0 already. > > > > > > Just verified it, at least in 2.6.15.6 tcpdump shows the defragmented > > packet on br0. > > I'm probably missing something, but that still seems stange. > Are you also seeing the defragmented packet on br0 with my > patch? Yes, here is the tcpdump output on all interfaces: 1) on tap1 23:22:51.830046 IP (tos 0x0, ttl 64, id 21174, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.10.1.500 > 192.168.20.1.500: isakmp 1.0 msgid : phase 1 I ident[E]: [encrypted id] (len mismatch: isakmp 2572/ip 1472) 23:22:51.830084 IP (tos 0x0, ttl 64, id 21174, offset 1480, flags [none], proto: UDP (17), length: 1120) 192.168.10.1 > 192.168.20.1: udp 2) on br0 23:22:51.830084 IP (tos 0x0, ttl 64, id 21174, offset 0, flags [none], proto: UDP (17), length: 2600) 192.168.10.1.500 > 192.168.20.1.500: isakmp 1.0 msgid : phase 1 I ident[E]: [encrypted id] 3) on eth1 23:22:51.830120 IP (tos 0x0, ttl 64, id 21174, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.10.1.500 > 192.168.20.1.500: isakmp 1.0 msgid : phase 1 I ident[E]: [encrypted id] (len mismatch: isakmp 2572/ip 1472) 23:22:51.830133 IP (tos 0x0, ttl 64, id 21174, offset 1480, flags [none], proto: UDP (17), length: 1120) 192.168.10.1 > 192.168.20.1: udp -- Thomas From Grzegorz at Janoszka.pl Tue Apr 4 00:09:52 2006 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Tue Apr 4 14:28:50 2006 Subject: Trivial connlimit and IPMARK patch for 2.6.16 Message-ID: Hello, Due to move of some targets from iptables to xtables, some patches turned to "not applyable", becouse their Makefile.ladd files tried to add iptables entries just after a target, that had been moved from iptables to xtables. Attached patch solves this problem, it only modifies Makefile.ladd files of connlimit and IPMARK. The patch is to patch-o-matic-ng-20060401 but it should apply clearly on any latest pom-ng. Please apply it. -- Grzegorz Janoszka -------------- next part -------------- diff -urN patch-o-matic-ng-20060401-old/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd patch-o-matic-ng-20060401/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd --- patch-o-matic-ng-20060401-old/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd 2004-05-06 14:52:37.000000000 +0200 +++ patch-o-matic-ng-20060401/patchlets/connlimit/linux-2.6.11/net/ipv4/netfilter/Makefile.ladd 2006-04-03 23:14:20.000000000 +0200 @@ -1,2 +1,2 @@ -obj-$(CONFIG_IP_NF_MATCH_STATE) += ipt_state.o +obj-$(CONFIG_IP_NF_MATCH_TOS) += ipt_tos.o obj-$(CONFIG_IP_NF_MATCH_CONNLIMIT) += ipt_connlimit.o diff -urN patch-o-matic-ng-20060401-old/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd patch-o-matic-ng-20060401/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd --- patch-o-matic-ng-20060401-old/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd 2004-05-06 14:23:54.000000000 +0200 +++ patch-o-matic-ng-20060401/patchlets/IPMARK/linux-2.6/net/ipv4/netfilter/Makefile.ladd 2006-04-03 23:11:57.000000000 +0200 @@ -1,2 +1,2 @@ -obj-$(CONFIG_IP_NF_TARGET_MARK) += ipt_MARK.o +obj-$(CONFIG_IP_NF_TARGET_TTL) += ipt_TTL.o obj-$(CONFIG_IP_NF_TARGET_IPMARK) += ipt_IPMARK.o From zhaojingmin at hotmail.com Tue Apr 4 05:55:25 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Tue Apr 4 14:28:51 2006 Subject: H.323 conntrack/NAT helper update for 2.6.17-rc1 Message-ID: Hi, Patrick, This update is to update 2.6.17-rc1 to the latest state. It includes following changes that are not in 2.6.17-rc1: 1. Add new parameter 'default_rrq_ttl'. 2. Change get_h245_addr to static 3. Change to use EXPORT_SYMBOL_GPL 4. Move some extern function prototypes from ip_nat_helper_h323.c to ip_conntrack_h323.h. 5. Move ip_conntrack_helper_h323_asn1.h and ip_conntrack_helper_h323_types.h from net/ipv4/netfilter/ to include/linux/netfilter_ipv4/. Please have a look at it and apply it. Thanks a lot! Jing Min Zhao Signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-2.6.17-rc1-nath323-0.7 Type: application/octet-stream Size: 90345 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060404/4b69c816/patch-2.6.17-rc1-nath323-0-0001.obj From eleblond at inl.fr Tue Apr 4 10:38:48 2006 From: eleblond at inl.fr (Eric Leblond) Date: Tue Apr 4 14:28:51 2006 Subject: [PATCH 2/3] fixed duration connection In-Reply-To: <1144139619.5186.24.camel@localhost.localdomain> References: <1144139619.5186.24.camel@localhost.localdomain> Message-ID: <1144139928.5186.31.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/20060404/91c5b451/attachment.pgp From eleblond at inl.fr Tue Apr 4 10:41:15 2006 From: eleblond at inl.fr (Eric Leblond) Date: Tue Apr 4 14:28:52 2006 Subject: [PATCH 3/3] [RFC] fixed duration connection In-Reply-To: <1144139619.5186.24.camel@localhost.localdomain> References: <1144139619.5186.24.camel@localhost.localdomain> Message-ID: <1144140075.5186.35.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/20060404/f19465f0/attachment.pgp From beunlovable at gmail.com Tue Apr 4 15:55:11 2006 From: beunlovable at gmail.com (David Vogt) Date: Tue Apr 4 16:11:17 2006 Subject: Multiple programs for QUEUE target Message-ID: <859616420604040655h6312ac86g3c8661c29bf4c7e5@mail.gmail.com> Dear all, as far as I understand libipq it is not possible to register more than one program that handles packets that are queued (using -j QUEUE), since only one pid can be registered at /proc/net/ip_queue. Is that right? Now I have two questions: 1) Does libnetfilter_queue solve that problem 2) Will packets be processed by both applications? The problem is that I use a closed source program here as well, that employs libipq. Altough I could rewrite my own application to use libnetfiter_queue I would highly appreciate a solution that uses libipq. I am sure I read something about a "dispachter"-like program, but I can't find it. Thanks, David From beunlovable at gmail.com Tue Apr 4 16:02:41 2006 From: beunlovable at gmail.com (David Vogt) Date: Tue Apr 4 16:18:45 2006 Subject: Multiple programs for QUEUE target In-Reply-To: <859616420604040655h6312ac86g3c8661c29bf4c7e5@mail.gmail.com> References: <859616420604040655h6312ac86g3c8661c29bf4c7e5@mail.gmail.com> Message-ID: <859616420604040702g1e74bcacr2115fb36e0e7298e@mail.gmail.com> 2006/4/4, David Vogt : > I am sure I read something about a "dispachter"-like program, > but I can't find it. Of course I found it right after posting to the list. ipqmpd it is called, however, it requires rewriting the program to some extend. Since this is not possible for the closed source program, any advice on how a solution to that problem might look like are highly appreciated. David From hivemynd at hivemynd.net Tue Apr 4 16:39:50 2006 From: hivemynd at hivemynd.net (Stephen Jones) Date: Tue Apr 4 16:56:00 2006 Subject: Patch-o-matic cleanup In-Reply-To: <4432306C.10106@trash.net> References: <443165AA.4030509@trash.net> <44321188.30902@hivemynd.net> <4432306C.10106@trash.net> Message-ID: <44328536.6070902@hivemynd.net> Patrick McHardy wrote: > Stephen Jones wrote: > >>Patrick McHardy wrote: >> >> >>>- pptp-conntrack-nat: in mainline now, patches are missing critical >>> fixes >> >>Hi Patrick, >> >>Is pptp-conntrack-nat functionality going to be included in the 2.4.x >>mainline also? Otherwise, the patches still appear to be necessary for >>2.4.x kernels. > > > No, 2.4 is in absolute stable mode. The pptp patches for 2.4 are missing > a number of important bugfixes, I wouldn't recommend using them in their > present form. We don't have the time to maintain old versions forever, > which is why we decided to remove this old stuff. > > Ok, good enough, and completely understandable. Unfortunately, for me, there are still quite a few items (not netfilter related) that work on 2.4.x that do not yet work on 2.6.x series kernels that force me into a holding pattern on the 2.4.3x kernels for now. I'll keep an archive of the last known working iptables + pom-ng snapshot if I need to recompile again in the future. The pptp conntrack functionality has been "mostly" working for us for several years now. The problems with it are rare and tend to occur when the linux firewall is managing many concurrent tunnels, otherwise it appears to work just fine. Thank you for your reply. SJ From shemminger at osdl.org Tue Apr 4 20:32:33 2006 From: shemminger at osdl.org (Stephen Hemminger) Date: Tue Apr 4 20:48:49 2006 Subject: [PATCH] ip_conntrack section mismatch warning fix Message-ID: <20060404113233.4de507d3@dxpl.pdx.osdl.net> This is a bit of a hack. It eliminates the section mismatch warning from latest linker. What happens is the init_or_cleanup code gets called from cleanup() hook and the linker thinks it will reference __initdata because of it's limited static analysis. By asking compiler to inline, it can eliminate that dead code. It does the __init text section to grow, but then the space can be reclaimed. Signed-off-by: Stephen Hemminger --- test-2.6.orig/net/ipv4/netfilter/ip_conntrack_standalone.c +++ test-2.6/net/ipv4/netfilter/ip_conntrack_standalone.c @@ -783,7 +783,7 @@ static ctl_table ip_ct_net_table[] = { EXPORT_SYMBOL(ip_ct_log_invalid); #endif /* CONFIG_SYSCTL */ -static int init_or_cleanup(int init) +static inline int init_or_cleanup(int init) { #ifdef CONFIG_PROC_FS struct proc_dir_entry *proc, *proc_exp, *proc_stat; From samueldg at arcoscom.com Tue Apr 4 21:57:49 2006 From: samueldg at arcoscom.com (=?ISO-8859-15?Q?Samuel_D=EDaz_Garc=EDa?=) Date: Tue Apr 4 22:14:02 2006 Subject: Patch-o-matic cleanup In-Reply-To: <443165AA.4030509@trash.net> References: <443165AA.4030509@trash.net> Message-ID: <4432CFBD.5020900@arcoscom.com> Patrick, after the last "cleanup" (18/9/2005?), many patches were removed and 2.4/2.6 compatibility broken, for example the "condition" match over 2.6 or CONNMARK over 2.4. I think, that if devteam are going to invert time to "cleanup" pomng, would be fantastic that old ussefull and broken patches (or teorically merged into kernel main base) must be reviewed. For example, you put pptp_conntrack to be deleted, but I used it into 2.4 kernel versions, where it isn't into mainline. That are the ticks I think you will need to take care of. Good work, regards. Patrick McHardy escribi?: > Following (quite late) the decision taken at the netfilter workshop to > clean up the pomng repository by removing old patches and moving some > patches out of the netfilter repository, I've started by removing the > obsolete ipsec* patches and the policy match. Both have been merged > and were pretty outdated. > > If noone can name good reasons against it, I will also remove the > following patches in a few days: > > - NETLINK: obsolete > - NETMAP: in mainline for a long time > - TRACE: don't recall the reason, but its on my list :) > - comment: in mainline > - conntrack_locking: seriously outdated, if someone wants to resurrect > this patch he can use the history > - dropped_table: also don't recall the reason > - goto: in mainline > - ipq_vmark: obsoleted by nfnetlink_queue > - mport: mainline multiport supports all of its features > - netfilter-docbook: outdated > - owner-socketlookup: unfixable broken > - pool: obsoleted by ipset > - pptp-conntrack-nat: in mainline now, patches are missing critical > fixes > - unclean: bad idea > > > -- Samuel D?az Garc?a Director Gerente ArcosCom Wireless, S.L.L. CIF: B11828068 c/ Romero Gago, 19 Arcos de la Frontera 11630 - Cadiz http://www.arcoscom.com mailto:samueldg@arcoscom.com msn: samueldg@arcoscom.com M?vil: 651 93 72 48 Tlfn.: 956 70 13 15 Fax: 956 70 34 83 From davem at davemloft.net Tue Apr 4 22:42:55 2006 From: davem at davemloft.net (David S. Miller) Date: Tue Apr 4 22:59:00 2006 Subject: [NETFILTER]: Fix fragmentation issues with bridge netfilter In-Reply-To: <44312671.3090904@trash.net> References: <44312671.3090904@trash.net> Message-ID: <20060404.134255.108672274.davem@davemloft.net> From: Patrick McHardy Date: Mon, 03 Apr 2006 15:43:13 +0200 > Fix a regression from the netfilter/IPsec patches with bridging. > Bart, please review this patch, if everything is fine I think it > should also go in -stable. Applied, thanks Patrick. Please submit this to -stable. From max at rfc2324.org Wed Apr 5 01:37:45 2006 From: max at rfc2324.org (Maximilian Wilhelm) Date: Wed Apr 5 01:57:00 2006 Subject: ct_sync-multigroup (was: Re: Made ct_sync running with 2.6.15.4...) In-Reply-To: <200603192258.27950@krak> References: <20060311033122.GA23805@galois.math.uni-paderborn.de> <200603192258.27950@krak> Message-ID: <20060404233745.GA26006@rfc2324.org> Am Sonntag, den 19. M?rz hub KOVACS Krisztian folgendes in die Tasten: Hi! [...] > However, merging these changes to SVN would still need some more work. > As the number of people working on ct_sync is very close to zero at the > moment, I think that all effort should be concentrated on a single branch > of the code. Because Harald has already put significant effort into > providing support for active-active setups I think that we should try and > get the linux-2.6-multigroup branch working first. Holger Eitzenberger > was also doing some tests using that version and provided multiple fixes > for problems he had found. > So I don't think we should put significant amount of work into updating > the old 2.6.10 branch. Instead, please give the -multigroup branch a try > and provide feedback. I wanted to give it a shot and updated most of the patches to fit to 2.6.17-rc1 (as in the git version of linus kernel from some hours ago). A diff against the svn.netfilter.org version can be found at [42]. I'm experiencing some lack of "knowledge" about the newest *tables -> x_tables chances and want to ask if someone allready has put some effort into updating the patches/code. If someone did, I would love to get/test/use the updates :) If not, I will try to fix this myself these days, but I don't know if I will be able to do so even though git makes things easier. > Of course if you think you have the time to prepare > an easily-committable patch for the linux-2.6 branch of ct_sync I'll be > more than happy to update the SVN repository. I'm just unwilling to spend > a significant amount of time updating that old branch. At [42] there are still working patches for the "plain" ct_sync branch :) (I splitted the patch in -fix and -cleanup) [42] http://vvv.barbarossa.name/files/ct_sync/ Ciao Max -- Follow the white penguin. From zhaojingmin at hotmail.com Wed Apr 5 02:29:57 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Wed Apr 5 02:46:15 2006 Subject: H.323 conntrack/NAT helper update for 2.6.17-rc1 Message-ID: Hi, Patrick, This patch is to update 2.6.17-rc1 to the latest state. It includes following changes that are not in 2.6.17-rc1: 1. Add new parameter 'default_rrq_ttl'. 2. Change get_h245_addr to static 3. Change to use EXPORT_SYMBOL_GPL 4. Move some extern function prototypes from ip_nat_helper_h323.c to ip_conntrack_h323.h. 5. Move ip_conntrack_helper_h323_asn1.h and ip_conntrack_helper_h323_types.h from net/ipv4/netfilter/ to include/linux/netfilter_ipv4/. Please have a look at it and apply it. Thanks a lot! Jing Min Zhao Signed-off-by: Jing Min Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-2.6.17-rc1-nath323-0.7.bz2 Type: application/octet-stream Size: 10327 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060405/a1abbc2a/patch-2.6.17-rc1-nath323-0.7.obj From kaber at trash.net Wed Apr 5 11:31:12 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 11:49:54 2006 Subject: [NETFILTER]: Fix fragmentation issues with bridge netfilter In-Reply-To: <20060404.134255.108672274.davem@davemloft.net> References: <44312671.3090904@trash.net> <20060404.134255.108672274.davem@davemloft.net> Message-ID: <44338E60.60704@trash.net> David S. Miller wrote: > From: Patrick McHardy > Date: Mon, 03 Apr 2006 15:43:13 +0200 > > >>Fix a regression from the netfilter/IPsec patches with bridging. >>Bart, please review this patch, if everything is fine I think it >>should also go in -stable. > > > Applied, thanks Patrick. Please submit this to -stable. Done. From kaber at trash.net Wed Apr 5 15:27:57 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 15:44:33 2006 Subject: Patch-o-matic cleanup In-Reply-To: <40106.195.55.244.106.1144140883.squirrel@www.arcoscom.com> References: <443165AA.4030509@trash.net> <40106.195.55.244.106.1144140883.squirrel@www.arcoscom.com> Message-ID: <4433C5DD.10903@trash.net> Samuel D?az Garc?a wrote: > Patrick, after the last "cleanup" (18/9/2005?), many patches were removed > and 2.4/2.6 compatibility broken, for example the "condition" match over > 2.6 or CONNMARK over 2.4. > > I think, that if devteam are going to invert time to "cleanup" pomng, > would be fantastic that old ussefull and broken patches (or teorically > merged into kernel main base) must be reviewed. Yes, that was the idea, most useful patches will be merged, a few useful but obscure will be kept and all others will be deleted. There will also be a new feature to download patches from external sources when using patch-o-matic, so if anyone wants to keep maintaining a specific patch, we can just include a line in the sources.list. > For example, you put pptp_conntrack to be deleted, but I used it into 2.4 > kernel versions, where it isn't into mainline. > > That are the ticks I think you will need to take care of. Most effort goes into 2.6 these days, and nobody seems to have the time to maintain old versions. The PPtP-helper in pom is missing important bugfixes, so as long as noone fixes those, it is better to remove it than to distribute versions known to have critical bugs IMO. This is the time for users to step up :) From kaber at trash.net Wed Apr 5 15:47:33 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 16:03:47 2006 Subject: Update: Patch-o-matic cleanup In-Reply-To: <443165AA.4030509@trash.net> References: <443165AA.4030509@trash.net> Message-ID: <4433CA75.9040607@trash.net> Patrick McHardy wrote: > Following (quite late) the decision taken at the netfilter workshop to > clean up the pomng repository by removing old patches and moving some > patches out of the netfilter repository, I've started by removing the > obsolete ipsec* patches and the policy match. Both have been merged > and were pretty outdated. > > If noone can name good reasons against it, I will also remove the > following patches in a few days: > [...] After receiving multiple "please keep this patch" mails, it seems I started the wrong way. Removing old patches is part of a greater plan to reduce the content of pom to only those things the netfilter team has an interest in maintaining, and most of these things will be merged in not too long time. _All_ other patches will be removed and the "runme" tool will be enhanced by an apt-get like mechanism to download patches from external sources, so people interested in keeping patches around can maintain them themselves and publish them somewhere for others to use. This should benefit both us and the authors since they usually maintain their own versions of the patches anyway and periodically send us updates to include in pom, which unnecessarily cost time for everyone involved. This is the full list of patches to be removed. Instructions how to set up a pomng repository are at the end of this mail, I'll commit the code soon. - ACCOUNT - IPMARK - NETLINK - NETMAP - TARPIT - TCPLAG - TRACE - XOR - account - comment - connlimit - connrate - conntrack_locking - cuseeme-nat - dropped-table - expire - fuzzy - geoip - goto - ip_queue_vwmark - ipp2p - mport - nat-reservations - netfilter-docbook - osf - owner-socketlookup - pool - pptp-conntrack-nat - psd - time - tproxy The patches will be removed in 30 days, authors or other people that want to maintain them in an external repository are welcome to send the URL to be included in the distrubuted sources.list. How to set up a repository: The repository must be accessible in a way supported by curl (HTTP or FTP for example). The name of each patchlet is listed in a file named "index". Each patchlet must be contained in a .tar.gz file, which contains a directory named like the patchlet itself. The directories contents are similar to those in patchlets/ today, but the Repository specified in the info file must be "external". So to create a repository from one of the patches currently in pom: - cd patchlets - edit $patch/info, change repository to "external" - tar cz $patch > /wwwroot/pom-repo/$patch.tar.gz - echo $patch >> /wwwroot/pom-repo/index As I said above, I'll commit the code for this soon. From kaber at trash.net Wed Apr 5 15:57:19 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 16:13:30 2006 Subject: [PATCH 0/3] [RFC] fixed duration connection In-Reply-To: <1144139619.5186.24.camel@localhost.localdomain> References: <1144139619.5186.24.camel@localhost.localdomain> Message-ID: <4433CCBF.6060103@trash.net> Eric Leblond wrote: > Hi, > > While working on NuFW development branch, we have had to > implement policy just as : > * connection to server is authorised from 08h to 18h and > connection must be switched off at 18h. > > Such features are frequently asked by customers or netfilter addicts but > even with current conntrack related code, it can not be done cleanly. > > Thus, we've added the notion of fixed duration before expiration to > connection in the conntrack. (See extended information on bottom for > details) > > The following set of patches is against kernel (linus git tree), > libnetfilter_conntrack, and conntrack tool. > > -- Extended -- > > When trying to implement this feature with current connection tracking > code, we have faced some issues : > 1. userspace code has to duplicate conntrack entries, thus it's > complex and uses memory > 2. there is no hope to have it done by a simple command line > (because of 1.) > 3. if replication of conntrack in userspace is needed there will be > many synchronisation problems : stop and start of an > hypothetical "expiration" daemon would cause conntrack > duplication and/or loss of information ... > > For this reason, we've worked on a simple kernel level implementation. > This is done via a second "struct timer" that is added in connection > structure. Activation of the timer, is for now done via userspace by > using libnetfilter_conntrack or by using new option -T of the conntrack > tool. If I understand you correctly, a fixed timeout is just a timeout that isn't refreshed, right? Why can't we just use the regular timers etc. and add a flag that it should not be touched by ip_ct_refresh? This would also eliminate the need for any ctnetlink changes since the timeout value can already be specified. From kaber at trash.net Wed Apr 5 16:30:46 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 16:49:22 2006 Subject: [PATCH] ip_conntrack section mismatch warning fix In-Reply-To: <20060404113233.4de507d3@dxpl.pdx.osdl.net> References: <20060404113233.4de507d3@dxpl.pdx.osdl.net> Message-ID: <4433D496.2090706@trash.net> Stephen Hemminger wrote: > This is a bit of a hack. It eliminates the section mismatch warning from > latest linker. What happens is the init_or_cleanup code gets called > from cleanup() hook and the linker thinks it will reference __initdata > because of it's limited static analysis. By asking compiler to > inline, it can eliminate that dead code. It does the __init text > section to grow, but then the space can be reclaimed. I think this might still fail without forced inlining. Our init functions look like crap anyway, and the reason mostly seems to be mass-registration of hooks, so I guess I'll clean that up with a small helper function and then just split them. From eric at inl.fr Wed Apr 5 16:41:49 2006 From: eric at inl.fr (Eric Leblond) Date: Wed Apr 5 17:01:27 2006 Subject: [PATCH 0/3] [RFC] fixed duration connection In-Reply-To: <4433CCBF.6060103@trash.net> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> Message-ID: <1144248110.4406.8.camel@localhost.localdomain> Le mercredi 05 avril 2006 ? 15:57 +0200, Patrick McHardy a ?crit : > Eric Leblond wrote: > > Hi, > > > > While working on NuFW development branch, we have had to > > implement policy just as : > > * connection to server is authorised from 08h to 18h and > > connection must be switched off at 18h. > > For this reason, we've worked on a simple kernel level implementation. > > This is done via a second "struct timer" that is added in connection > > structure. Activation of the timer, is for now done via userspace by > > using libnetfilter_conntrack or by using new option -T of the conntrack > > tool. > > If I understand you correctly, a fixed timeout is just a timeout that > isn't refreshed, right? Yes, exactly. > Why can't we just use the regular timers etc. > and add a flag that it should not be touched by ip_ct_refresh? This > would also eliminate the need for any ctnetlink changes since the > timeout value can already be specified. This was my first attempt and this may be the good one. In fact I switch to a second timer because we may have a fixed timeout that exceeds the protocol timeout. Thus, connection may be removed far too long after what's needed. For example, we could have an UDP connection with fixed timeout of a couple day which is more than protool timeout. In fact, this approach can introduces an overload of conntrack but the second timer approach may cost more in term of timer handling. BR, -- Eric Leblond NuFW : http://www.nufw.org -------------- 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/20060405/cf74c8c2/attachment.pgp From c-d.hailfinger.devel.2006 at gmx.net Wed Apr 5 17:20:21 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed Apr 5 17:36:34 2006 Subject: Update: Patch-o-matic cleanup In-Reply-To: <4433CA75.9040607@trash.net> References: <443165AA.4030509@trash.net> <4433CA75.9040607@trash.net> Message-ID: <4433E035.2010504@gmx.net> Hi Patrick, Patrick McHardy schrieb: > > After receiving multiple "please keep this patch" mails, it seems I > started the wrong way. > > Removing old patches is part of a greater plan to reduce the content of > pom to only those things the netfilter team has an interest in > maintaining, and most of these things will be merged in not too long > time. _All_ other patches will be removed and the "runme" tool will > be enhanced by an apt-get like mechanism to download patches from > external sources[...] But why keep a few patches in pom and throw out the rest? Wouldn't it make sense to reduce pom to a simple script and throw out all patches? The few patches maintained by the netfilter team could be moved to a separate pom-hotfix package and be automatically downloaded by the pom script. OTOH, having a pom-ng that can be applied without a network connection was very helpful for me in the past. So if you are really going to discontinue pom-ng as is, I offer to take over maintenance. Fetching the different packages from locations in a list and assembling them into one pom-full package automatically can't be that difficult. Regards, Carl-Daniel -- http://www.hailfinger.org/ From laforge at netfilter.org Wed Apr 5 17:21:12 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 5 17:37:25 2006 Subject: H.323 conntrack/NAT helper update for 2.6.17-rc1 In-Reply-To: References: Message-ID: <20060405152112.GF20558@sunbeam.de.gnumonks.org> On Tue, Apr 04, 2006 at 08:29:57PM -0400, Jing Min Zhao wrote: > Hi, Patrick, > > This patch is to update 2.6.17-rc1 to the latest state. It includes following changes that are not in > 2.6.17-rc1: just as a minor note: Please attach patches in plaintext, so people can read them in their mail readers rather than having to save, extract, read, delete them (which is time consuming). Thanks! -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060405/58835933/attachment.pgp From laforge at netfilter.org Wed Apr 5 17:23:06 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 5 17:39:18 2006 Subject: [PATCH] ip_conntrack section mismatch warning fix In-Reply-To: <4433D496.2090706@trash.net> References: <20060404113233.4de507d3@dxpl.pdx.osdl.net> <4433D496.2090706@trash.net> Message-ID: <20060405152306.GG20558@sunbeam.de.gnumonks.org> On Wed, Apr 05, 2006 at 04:30:46PM +0200, Patrick McHardy wrote: > Stephen Hemminger wrote: > > This is a bit of a hack. It eliminates the section mismatch warning from > > latest linker. What happens is the init_or_cleanup code gets called > > from cleanup() hook and the linker thinks it will reference __initdata > > because of it's limited static analysis. By asking compiler to > > inline, it can eliminate that dead code. It does the __init text > > section to grow, but then the space can be reclaimed. > > I think this might still fail without forced inlining. Our init > functions look like crap anyway, and the reason mostly seems to > be mass-registration of hooks, so I guess I'll clean that up > with a small helper function and then just split them. still I actually think of the shared init/cleanup functions as a big feature rather than something that needs to be 'cleaned up'. I'm obviously not opposing something like nf_register_hook_array(), but that's a different issue. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060405/f6ab153c/attachment.pgp From laforge at netfilter.org Wed Apr 5 17:24:09 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 5 17:40:24 2006 Subject: Multiple programs for QUEUE target In-Reply-To: <859616420604040702g1e74bcacr2115fb36e0e7298e@mail.gmail.com> References: <859616420604040655h6312ac86g3c8661c29bf4c7e5@mail.gmail.com> <859616420604040702g1e74bcacr2115fb36e0e7298e@mail.gmail.com> Message-ID: <20060405152409.GH20558@sunbeam.de.gnumonks.org> On Tue, Apr 04, 2006 at 04:02:41PM +0200, David Vogt wrote: > 2006/4/4, David Vogt : > > I am sure I read something about a "dispachter"-like program, > > but I can't find it. > > Of course I found it right after posting to the list. ipqmpd it is > called, however, it requires rewriting the program to some extend. > Since this is not possible for the closed source program, any advice > on how a solution to that problem might look like are highly > appreciated. Please don't use any of that old 'crap' (I'm the author, so I can call it that). These days, you use NFQUEUE, nf_queue, nfnetlink_queue, libnetfilter_queue, and you get up to 65535 distinct queues for different userespace processes. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060405/cdeb4aee/attachment.pgp From laforge at netfilter.org Wed Apr 5 17:26:28 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 5 17:42:39 2006 Subject: Trivial connlimit and IPMARK patch for 2.6.16 In-Reply-To: References: Message-ID: <20060405152628.GI20558@sunbeam.de.gnumonks.org> On Tue, Apr 04, 2006 at 12:09:52AM +0200, Grzegorz Janoszka wrote: > > Hello, > > Due to move of some targets from iptables to xtables, some patches turned to "not applyable", becouse > their Makefile.ladd files > tried to add iptables entries just after a target, that had been moved from iptables to xtables. > > Attached patch solves this problem, it only modifies Makefile.ladd files of connlimit and IPMARK. The > patch is to patch-o-matic-ng-20060401 but it should apply clearly on any latest pom-ng. I'm not really in the mood of manually adding such patches to svn. I'm not really sure on the future of patch-o-matic as a whole. At least I haven't really used any of the patches from there or updated anything or tested whether it applies for at least half a year. So unless somebody actually wants to become patch-o-matic maintainer (yes, we once had somebody for that job), I think it's going to die. Patrick, any news on that 'patch o matic remote repositories' idea? -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060405/62858a2a/attachment.pgp From laforge at netfilter.org Wed Apr 5 17:29:27 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 5 17:45:39 2006 Subject: Update: Patch-o-matic cleanup In-Reply-To: <4433CA75.9040607@trash.net> References: <443165AA.4030509@trash.net> <4433CA75.9040607@trash.net> Message-ID: <20060405152927.GJ20558@sunbeam.de.gnumonks.org> Thanks Patrick, for taking care of this long-over-due issue. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060405/f8de1656/attachment-0001.pgp From kaber at trash.net Wed Apr 5 17:28:24 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 17:47:02 2006 Subject: [PATCH] ip_conntrack section mismatch warning fix In-Reply-To: <20060405152306.GG20558@sunbeam.de.gnumonks.org> References: <20060404113233.4de507d3@dxpl.pdx.osdl.net> <4433D496.2090706@trash.net> <20060405152306.GG20558@sunbeam.de.gnumonks.org> Message-ID: <4433E218.3060100@trash.net> Harald Welte wrote: > On Wed, Apr 05, 2006 at 04:30:46PM +0200, Patrick McHardy wrote: > >>I think this might still fail without forced inlining. Our init >>functions look like crap anyway, and the reason mostly seems to >>be mass-registration of hooks, so I guess I'll clean that up >>with a small helper function and then just split them. > > > still I actually think of the shared init/cleanup functions as a big > feature rather than something that needs to be 'cleaned up'. I think they make the cleanup code quite unreadable because the heavy mix with labels. I'm already half way through and the seperated cleanup functions really are a lot more readable. Besides that the split also allows to throw the init part away after initializing, so it makes the binary smaller. From laforge at netfilter.org Wed Apr 5 17:31:16 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 5 17:47:28 2006 Subject: Regarding LIBIPQ problem In-Reply-To: <4854.10.12.25.5.1143978508.squirrel@gpo.iitb.ac.in> References: <1411.10.12.25.5.1143825446.squirrel@gpo.iitb.ac.in> <859616420604010236j1048f16anbe3edaa8b6967244@mail.gmail.com> <4854.10.12.25.5.1143978508.squirrel@gpo.iitb.ac.in> Message-ID: <20060405153116.GK20558@sunbeam.de.gnumonks.org> On Sun, Apr 02, 2006 at 05:18:28PM +0530, Vasantha Kumar Puttappa wrote: > Hi David, > Thanx for your response. > Actually I did use "ntohs" in the actual code. > Anyhow I tested same code in kernel-2.6.11-6mdk and it's working fine, > although i am receiving multiple copies at the receiver. > > Do you have any idea of kernel version in which "libipq" works properly > withoug any problem. I'm not aware of any libipq/kernel versions that have problems. Also, try using libnetfilter_queue / nf_queue for new code, rather than ip_queue, which has already been in feature-removal-schedule for quite some time. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060405/7241e643/attachment.pgp From zhaojingmin at hotmail.com Wed Apr 5 17:32:35 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Wed Apr 5 17:49:21 2006 Subject: H.323 conntrack/NAT helper update for 2.6.17-rc1 References: <20060405152112.GF20558@sunbeam.de.gnumonks.org> Message-ID: I sent it first in plain text the day before yesterday, but it didn't show up. I thought it was too big to be processed, so I sent it compressed again. Now it seems just because it was slow. I'm sorry I didn't know this. ----- Original Message ----- From: "Harald Welte" To: Sent: Wednesday, April 05, 2006 11:21 AM Subject: Re: H.323 conntrack/NAT helper update for 2.6.17-rc1 From kaber at trash.net Wed Apr 5 17:37:46 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 17:56:24 2006 Subject: Update: Patch-o-matic cleanup In-Reply-To: <4433E035.2010504@gmx.net> References: <443165AA.4030509@trash.net> <4433CA75.9040607@trash.net> <4433E035.2010504@gmx.net> Message-ID: <4433E44A.3000503@trash.net> Carl-Daniel Hailfinger wrote: > Hi Patrick, > > Patrick McHardy schrieb: > >>After receiving multiple "please keep this patch" mails, it seems I >>started the wrong way. >> >>Removing old patches is part of a greater plan to reduce the content of >>pom to only those things the netfilter team has an interest in >>maintaining, and most of these things will be merged in not too long >>time. _All_ other patches will be removed and the "runme" tool will >>be enhanced by an apt-get like mechanism to download patches from >>external sources[...] > > > But why keep a few patches in pom and throw out the rest? Wouldn't it > make sense to reduce pom to a simple script and throw out all patches? > The few patches maintained by the netfilter team could be moved to a > separate pom-hotfix package and be automatically downloaded by the > pom script. We could do that, but currently we want to keep a few patches while minimizing our effort, the easiest way to do that is to just keep them where they are. > OTOH, having a pom-ng that can be applied without a network connection > was very helpful for me in the past. So if you are really going to > discontinue pom-ng as is, I offer to take over maintenance. Fetching > the different packages from locations in a list and assembling them > into one pom-full package automatically can't be that difficult. I'm not sure if we want to discontinue official pom-releases entirely, but you are of course free to maintain and release version which include external patches. From kaber at trash.net Wed Apr 5 19:10:23 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 5 19:29:01 2006 Subject: H.323 conntrack/NAT helper update for 2.6.17-rc1 In-Reply-To: References: Message-ID: <4433F9FF.6050709@trash.net> Jing Min Zhao wrote: > Hi, Patrick, > > This patch is to update 2.6.17-rc1 to the latest state. It includes > following changes that are not in 2.6.17-rc1: > > 1. Add new parameter 'default_rrq_ttl'. > 2. Change get_h245_addr to static > 3. Change to use EXPORT_SYMBOL_GPL > 4. Move some extern function prototypes from ip_nat_helper_h323.c to > ip_conntrack_h323.h. > 5. Move ip_conntrack_helper_h323_asn1.h and > ip_conntrack_helper_h323_types.h from net/ipv4/netfilter/ to > include/linux/netfilter_ipv4/. > > Please have a look at it and apply it. Applied, thanks. A couple of comments though: - I've split your patches into the logical changes, this is prefered to "version-updates". Ideally you just send one patch per change. - whitespace changes: - /* ip_nat_mangle_udp_packet uses skb_make_writable() to copy - * or pull everything in a linear buffer, so we can safely + /* ip_nat_mangle_udp_packet uses skb_make_writable() to copy + * or pull everything in a linear buffer, so we can safely Please try to avoid such things, except for seperated patches that _remove_ whitespace :) - I've changed default_rrq_timeout to unsigned because it is assigned to an unsigned member. - Changelogs in the source-code: its your choice, but I personally prefer to avoid changelogs in the source files, they tend to grow pretty fast and you are mostly not interested in them. If you are, you can use the git history. Thanks again. From zhaojingmin at hotmail.com Wed Apr 5 19:40:35 2006 From: zhaojingmin at hotmail.com (Jing Min Zhao) Date: Wed Apr 5 19:56:55 2006 Subject: H.323 conntrack/NAT helper update for 2.6.17-rc1 References: <4433F9FF.6050709@trash.net> Message-ID: ----- Original Message ----- From: "Patrick McHardy" To: "Jing Min Zhao" Cc: Sent: Wednesday, April 05, 2006 1:10 PM Subject: Re: H.323 conntrack/NAT helper update for 2.6.17-rc1 > > Applied, thanks. A couple of comments though: > > - I've split your patches into the logical changes, this is prefered > to "version-updates". Ideally you just send one patch per change. > OK, I will. > - whitespace changes: > > - /* ip_nat_mangle_udp_packet uses skb_make_writable() to copy > - * or pull everything in a linear buffer, so we can safely > + /* ip_nat_mangle_udp_packet uses skb_make_writable() to > copy > + * or pull everything in a linear buffer, so we can safely > > Please try to avoid such things, except for seperated patches that > _remove_ whitespace :) > I did check trailing spaces by checking the diff file. But I still missed something :( > - I've changed default_rrq_timeout to unsigned because it is assigned > to an unsigned member. > Thank you. According to the ASN file, it should be unsigned. I knew this but just simply forgot it. Forgive my carelessness. > - Changelogs in the source-code: its your choice, but I personally > prefer to avoid changelogs in the source files, they tend to > grow pretty fast and you are mostly not interested in them. If > you are, you can use the git history. > I'll try. > Thanks again. > > I'm sorry it wasted you so much time on these careless mistakes. Thank you for your great work and your time! Best regards, Jing Min Zhao From kaber at trash.net Thu Apr 6 00:00:04 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 00:16:20 2006 Subject: fix kbuild warning in iptable_nat.o In-Reply-To: <1143719875.8469.14.camel@localhost.localdomain> References: <1143719875.8469.14.camel@localhost.localdomain> Message-ID: <44343DE4.70500@trash.net> Darren Jenkins\ wrote: > G'day list > > There are a couple of Kbuild warnings in net/ipv4/netfilter/ that would > be nice to get rid of. > > WARNING: net/ipv4/netfilter/ip_conntrack.o - Section mismatch: reference > to .init.text:ip_conntrack_init from .text between 'init_or_cleanup' (at > offset 0x7ea) and '__hash_conntrack' > WARNING: net/ipv4/netfilter/iptable_nat.o - Section mismatch: reference > to .init.text:ip_nat_rule_init from .text between 'init_or_cleanup' (at > offset 0x455) and 'nat_decode_session' > > I have a patch for the 'iptable_nat.o' warning below, and I was just > wanting to check in and see if any of you netfilter guys had a problem > with this patch, or with me doing a similar patch for the > 'ip_canntrack.o' warning. > > > Any input would be welcome, thanks in advance :). I have a patch queued that just splits the init/cleanup parts. From laforge at netfilter.org Thu Apr 6 09:29:27 2006 From: laforge at netfilter.org (Harald Welte) Date: Thu Apr 6 09:45:44 2006 Subject: H.323 conntrack/NAT helper update for 2.6.17-rc1 In-Reply-To: References: <20060405152112.GF20558@sunbeam.de.gnumonks.org> Message-ID: <20060406072927.GD6887@sunbeam.de.gnumonks.org> On Wed, Apr 05, 2006 at 11:32:35AM -0400, Jing Min Zhao wrote: > I sent it first in plain text the day before yesterday, but it didn't show up. > I thought it was too big to be processed, so I sent it compressed again. Now it > seems just because it was slow. I'm sorry I didn't know this. No problem at all. The delay was due to administrative downtime of the mailinglist server. I was merely recommending you to send it as plain text in the future, so no offence taken, no harm done ;) -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060406/eefce23c/attachment.pgp From laforge at netfilter.org Thu Apr 6 09:35:14 2006 From: laforge at netfilter.org (Harald Welte) Date: Thu Apr 6 09:51:30 2006 Subject: The future of patch-o-matic-ng In-Reply-To: References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> Message-ID: <20060406073514.GE6887@sunbeam.de.gnumonks.org> On Wed, Apr 05, 2006 at 09:52:48PM +0200, Grzegorz Janoszka wrote: > On Wed, 5 Apr 2006, Harald Welte wrote: > > >So unless somebody actually wants to become patch-o-matic maintainer > >(yes, we once had somebody for that job), I think it's going to die. > > I can try. Well, as it seems I should have read netfilter-devel in chronological order rather than backwards. Patrick has already posted on how to proceed with patch-o-matic-ng a couple of days ago: Have the original authors (or other people who want to maintain patchlets) host their own repositories. Patch-o-matic-ng would then mostly only contain a list of URL's to such remote repositories. This way there is no need for the netfilter developers themselves to maintain patchsets. > Pom is used by many people, please don't let it die. If you have > nobody to take care of it, give it to me. As indicated in Patricks mail, there's a 30 day grace period. Until then the original authors (if they care) or other people can take maintenance for individual patchlets and send us URL's to those repositories. We will add them to our list file, and distribute a 'runme' script which downloads those repositories off the net. If you want to help, I suggest to wait for those patchlets that nobody takes care of, and run a repository for them. Also, I assume that there is a lot that can be done to improve that patchlet-handling script, i.e. add suport for GPG signature checking and the like. I suggest you coordinate with Patrick on this. If any of the 'patchlet maintainers' require a place where they can put repositories online via http/ftp, please let me know, we have people.netfilter.org accounts exactly for this purpose. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060406/53f50c1f/attachment-0001.pgp From kaber at trash.net Thu Apr 6 10:22:23 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 10:41:11 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <20060406073514.GE6887@sunbeam.de.gnumonks.org> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> Message-ID: <4434CFBF.7030208@trash.net> Harald Welte wrote: > As indicated in Patricks mail, there's a 30 day grace period. Until > then the original authors (if they care) or other people can take > maintenance for individual patchlets and send us URL's to those > repositories. We will add them to our list file, and distribute a > 'runme' script which downloads those repositories off the net. > > If you want to help, I suggest to wait for those patchlets that nobody > takes care of, and run a repository for them. As a side-note: anyone who decides to take maintanance for some patchlet, please drop me a short note, so I can keep a list of unmaintained patches. > Also, I assume that there is a lot that can be done to improve that > patchlet-handling script, i.e. add suport for GPG signature checking and > the like. I suggest you coordinate with Patrick on this. Definitely. The code is very basic, it only makes sure a patchlet 1) doesn't overwrite anything outside of its patchlet directory 2) can only overwrite "Repository: external" patchlets But doensn't do any signature verification. I'll add it today, patches are welcome. From kaber at trash.net Thu Apr 6 12:04:53 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:10 2006 Subject: [NETFILTER 01/12]: Add helper functions for mass hook registration/unregistration In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100453.17409.47998.sendpatchset@localhost.localdomain> [NETFILTER]: Add helper functions for mass hook registration/unregistration Signed-off-by: Patrick McHardy --- commit 3bf0d209e539917efcc5286b8f1cab2856ebdd49 tree 4c5840cf32ee69cc6138534d24c4d43a23fad557 parent 32a976a8703b098e898a9a13f9ddcabbf654e7d8 author Patrick McHardy Thu, 06 Apr 2006 11:32:05 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:32:05 +0200 include/linux/netfilter.h | 2 ++ net/netfilter/core.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 0 deletions(-) diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h index 412e52c..5aa9316 100644 --- a/include/linux/netfilter.h +++ b/include/linux/netfilter.h @@ -110,6 +110,8 @@ struct nf_info /* Function to register/unregister hook points. */ int nf_register_hook(struct nf_hook_ops *reg); void nf_unregister_hook(struct nf_hook_ops *reg); +int nf_register_hooks(struct nf_hook_ops *reg, unsigned int n); +void nf_unregister_hooks(struct nf_hook_ops *reg, unsigned int n); /* Functions to register get/setsockopt ranges (non-inclusive). You need to check permissions yourself! */ diff --git a/net/netfilter/core.c b/net/netfilter/core.c index 1ceb1a6..5c7143e 100644 --- a/net/netfilter/core.c +++ b/net/netfilter/core.c @@ -63,6 +63,34 @@ void nf_unregister_hook(struct nf_hook_o } EXPORT_SYMBOL(nf_unregister_hook); +int nf_register_hooks(struct nf_hook_ops *reg, unsigned int n) +{ + unsigned int i; + int err = 0; + + for (i = 0; i < n; i++) { + err = nf_register_hook(®[i]); + if (err) + goto err; + } + return err; + +err: + if (i > 0) + nf_unregister_hooks(reg, i - i); + return err; +} +EXPORT_SYMBOL(nf_register_hooks); + +void nf_unregister_hooks(struct nf_hook_ops *reg, unsigned int n) +{ + unsigned int i; + + for (i = 0; i < n; i++) + nf_unregister_hook(®[i]); +} +EXPORT_SYMBOL(nf_unregister_hooks); + unsigned int nf_iterate(struct list_head *head, struct sk_buff **skb, int hook, From kaber at trash.net Thu Apr 6 12:04:56 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:15 2006 Subject: [NETFILTER 03/12]: Fix section mismatch warnings In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100456.17409.89515.sendpatchset@localhost.localdomain> [NETFILTER]: Fix section mismatch warnings Fix section mismatch warnings caused by netfilter's init_or_cleanup functions used in many places by splitting the init from the cleanup parts. Signed-off-by: Patrick McHardy --- commit 7e7dcfedeec88f2da01af1261c4ecc5a27a9686f tree 19c9844dce001903774a04a943c61c967a4a9a5f parent 2f8e62d3a554aee067771c5146a1e29feecd2758 author Patrick McHardy Thu, 06 Apr 2006 11:35:58 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:35:58 +0200 net/ipv4/netfilter/ip_conntrack_standalone.c | 90 +++++++++---------- net/ipv4/netfilter/ip_nat_standalone.c | 18 +--- net/ipv4/netfilter/ip_queue.c | 31 +++--- net/ipv4/netfilter/ipt_CLUSTERIP.c | 40 +++----- net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 38 ++++---- net/ipv6/netfilter/ip6_queue.c | 31 +++--- net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 38 ++++---- net/netfilter/nf_conntrack_standalone.c | 115 ++++++++++++------------ net/netfilter/nfnetlink_log.c | 25 ++--- net/netfilter/nfnetlink_queue.c | 27 ++---- 10 files changed, 204 insertions(+), 249 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_standalone.c b/net/ipv4/netfilter/ip_conntrack_standalone.c index adc1a0f..f785529 100644 --- a/net/ipv4/netfilter/ip_conntrack_standalone.c +++ b/net/ipv4/netfilter/ip_conntrack_standalone.c @@ -776,18 +776,46 @@ static ctl_table ip_ct_net_table[] = { EXPORT_SYMBOL(ip_ct_log_invalid); #endif /* CONFIG_SYSCTL */ -static int init_or_cleanup(int init) +/* FIXME: Allow NULL functions and sub in pointers to generic for + them. --RR */ +int ip_conntrack_protocol_register(struct ip_conntrack_protocol *proto) +{ + int ret = 0; + + write_lock_bh(&ip_conntrack_lock); + if (ip_ct_protos[proto->proto] != &ip_conntrack_generic_protocol) { + ret = -EBUSY; + goto out; + } + ip_ct_protos[proto->proto] = proto; + out: + write_unlock_bh(&ip_conntrack_lock); + return ret; +} + +void ip_conntrack_protocol_unregister(struct ip_conntrack_protocol *proto) +{ + write_lock_bh(&ip_conntrack_lock); + ip_ct_protos[proto->proto] = &ip_conntrack_generic_protocol; + write_unlock_bh(&ip_conntrack_lock); + + /* Somebody could be still looking at the proto in bh. */ + synchronize_net(); + + /* Remove all contrack entries for this protocol */ + ip_ct_iterate_cleanup(kill_proto, &proto->proto); +} + +static int __init ip_conntrack_standalone_init(void) { #ifdef CONFIG_PROC_FS struct proc_dir_entry *proc, *proc_exp, *proc_stat; #endif int ret = 0; - if (!init) goto cleanup; - ret = ip_conntrack_init(); if (ret < 0) - goto cleanup_nothing; + return ret; #ifdef CONFIG_PROC_FS ret = -ENOMEM; @@ -819,16 +847,12 @@ static int init_or_cleanup(int init) goto cleanup_hooks; } #endif - return ret; - cleanup: - synchronize_net(); #ifdef CONFIG_SYSCTL - unregister_sysctl_table(ip_ct_sysctl_header); cleanup_hooks: -#endif nf_unregister_hooks(ip_conntrack_ops, ARRAY_SIZE(ip_conntrack_ops)); +#endif cleanup_proc_stat: #ifdef CONFIG_PROC_FS remove_proc_entry("ip_conntrack", proc_net_stat); @@ -839,48 +863,22 @@ static int init_or_cleanup(int init) cleanup_init: #endif /* CONFIG_PROC_FS */ ip_conntrack_cleanup(); - cleanup_nothing: - return ret; -} - -/* FIXME: Allow NULL functions and sub in pointers to generic for - them. --RR */ -int ip_conntrack_protocol_register(struct ip_conntrack_protocol *proto) -{ - int ret = 0; - - write_lock_bh(&ip_conntrack_lock); - if (ip_ct_protos[proto->proto] != &ip_conntrack_generic_protocol) { - ret = -EBUSY; - goto out; - } - ip_ct_protos[proto->proto] = proto; - out: - write_unlock_bh(&ip_conntrack_lock); return ret; } -void ip_conntrack_protocol_unregister(struct ip_conntrack_protocol *proto) -{ - write_lock_bh(&ip_conntrack_lock); - ip_ct_protos[proto->proto] = &ip_conntrack_generic_protocol; - write_unlock_bh(&ip_conntrack_lock); - - /* Somebody could be still looking at the proto in bh. */ - synchronize_net(); - - /* Remove all contrack entries for this protocol */ - ip_ct_iterate_cleanup(kill_proto, &proto->proto); -} - -static int __init ip_conntrack_standalone_init(void) -{ - return init_or_cleanup(1); -} - static void __exit ip_conntrack_standalone_fini(void) { - init_or_cleanup(0); + synchronize_net(); +#ifdef CONFIG_SYSCTL + unregister_sysctl_table(ip_ct_sysctl_header); +#endif + nf_unregister_hooks(ip_conntrack_ops, ARRAY_SIZE(ip_conntrack_ops)); +#ifdef CONFIG_PROC_FS + remove_proc_entry("ip_conntrack", proc_net_stat); + proc_net_remove("ip_conntrack_expect"); + proc_net_remove("ip_conntrack"); +#endif /* CONFIG_PROC_FS */ + ip_conntrack_cleanup(); } module_init(ip_conntrack_standalone_init); diff --git a/net/ipv4/netfilter/ip_nat_standalone.c b/net/ipv4/netfilter/ip_nat_standalone.c index 5f02f43..8f760b2 100644 --- a/net/ipv4/netfilter/ip_nat_standalone.c +++ b/net/ipv4/netfilter/ip_nat_standalone.c @@ -350,14 +350,12 @@ static struct nf_hook_ops ip_nat_ops[] = }, }; -static int init_or_cleanup(int init) +static int __init ip_nat_standalone_init(void) { int ret = 0; need_conntrack(); - if (!init) goto cleanup; - #ifdef CONFIG_XFRM BUG_ON(ip_nat_decode_session != NULL); ip_nat_decode_session = nat_decode_session; @@ -374,8 +372,6 @@ static int init_or_cleanup(int init) } return ret; - cleanup: - nf_unregister_hooks(ip_nat_ops, ARRAY_SIZE(ip_nat_ops)); cleanup_rule_init: ip_nat_rule_cleanup(); cleanup_decode_session: @@ -386,14 +382,14 @@ static int init_or_cleanup(int init) return ret; } -static int __init ip_nat_standalone_init(void) -{ - return init_or_cleanup(1); -} - static void __exit ip_nat_standalone_fini(void) { - init_or_cleanup(0); + nf_unregister_hooks(ip_nat_ops, ARRAY_SIZE(ip_nat_ops)); + ip_nat_rule_cleanup(); +#ifdef CONFIG_XFRM + ip_nat_decode_session = NULL; + synchronize_net(); +#endif } module_init(ip_nat_standalone_init); diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c index 896a244..4bcc842 100644 --- a/net/ipv4/netfilter/ip_queue.c +++ b/net/ipv4/netfilter/ip_queue.c @@ -662,15 +662,11 @@ static struct nf_queue_handler nfqh = { .outfn = &ipq_enqueue_packet, }; -static int -init_or_cleanup(int init) +static int __init ip_queue_init(void) { int status = -ENOMEM; struct proc_dir_entry *proc; - if (!init) - goto cleanup; - netlink_register_notifier(&ipq_nl_notifier); ipqnl = netlink_kernel_create(NETLINK_FIREWALL, 0, ipq_rcv_sk, THIS_MODULE); @@ -697,11 +693,6 @@ init_or_cleanup(int init) } return status; -cleanup: - nf_unregister_queue_handlers(&nfqh); - synchronize_net(); - ipq_flush(NF_DROP); - cleanup_sysctl: unregister_sysctl_table(ipq_sysctl_header); unregister_netdevice_notifier(&ipq_dev_notifier); @@ -717,15 +708,21 @@ cleanup_netlink_notifier: return status; } -static int __init ip_queue_init(void) -{ - - return init_or_cleanup(1); -} - static void __exit ip_queue_fini(void) { - init_or_cleanup(0); + nf_unregister_queue_handlers(&nfqh); + synchronize_net(); + ipq_flush(NF_DROP); + + unregister_sysctl_table(ipq_sysctl_header); + unregister_netdevice_notifier(&ipq_dev_notifier); + proc_net_remove(IPQ_PROC_FS_NAME); + + sock_release(ipqnl->sk_socket); + mutex_lock(&ipqnl_mutex); + mutex_unlock(&ipqnl_mutex); + + netlink_unregister_notifier(&ipq_nl_notifier); } MODULE_DESCRIPTION("IPv4 packet queue handler"); diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c index e4768a3..aad9d28 100644 --- a/net/ipv4/netfilter/ipt_CLUSTERIP.c +++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c @@ -725,22 +725,17 @@ static struct file_operations clusterip_ #endif /* CONFIG_PROC_FS */ -static int init_or_cleanup(int fini) +static int __init ipt_clusterip_init(void) { int ret; - if (fini) - goto cleanup; - - if (ipt_register_target(&clusterip_tgt)) { - ret = -EINVAL; - goto cleanup_none; - } + ret = ipt_register_target(&clusterip_tgt); + if (ret < 0) + return ret; - if (nf_register_hook(&cip_arp_ops) < 0) { - ret = -EINVAL; + ret = nf_register_hook(&cip_arp_ops); + if (ret < 0) goto cleanup_target; - } #ifdef CONFIG_PROC_FS clusterip_procdir = proc_mkdir("ipt_CLUSTERIP", proc_net); @@ -753,31 +748,24 @@ static int init_or_cleanup(int fini) printk(KERN_NOTICE "ClusterIP Version %s loaded successfully\n", CLUSTERIP_VERSION); - return 0; -cleanup: - printk(KERN_NOTICE "ClusterIP Version %s unloading\n", - CLUSTERIP_VERSION); -#ifdef CONFIG_PROC_FS - remove_proc_entry(clusterip_procdir->name, clusterip_procdir->parent); -#endif cleanup_hook: nf_unregister_hook(&cip_arp_ops); cleanup_target: ipt_unregister_target(&clusterip_tgt); -cleanup_none: - return -EINVAL; -} - -static int __init ipt_clusterip_init(void) -{ - return init_or_cleanup(0); + return ret; } static void __exit ipt_clusterip_fini(void) { - init_or_cleanup(1); + printk(KERN_NOTICE "ClusterIP Version %s unloading\n", + CLUSTERIP_VERSION); +#ifdef CONFIG_PROC_FS + remove_proc_entry(clusterip_procdir->name, clusterip_procdir->parent); +#endif + nf_unregister_hook(&cip_arp_ops); + ipt_unregister_target(&clusterip_tgt); } module_init(ipt_clusterip_init); diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c index 3fadacc..15ebdb6 100644 --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c @@ -432,16 +432,20 @@ struct nf_conntrack_l3proto nf_conntrack extern struct nf_conntrack_protocol nf_conntrack_protocol_tcp4; extern struct nf_conntrack_protocol nf_conntrack_protocol_udp4; extern struct nf_conntrack_protocol nf_conntrack_protocol_icmp; -static int init_or_cleanup(int init) + +MODULE_ALIAS("nf_conntrack-" __stringify(AF_INET)); +MODULE_LICENSE("GPL"); + +static int __init nf_conntrack_l3proto_ipv4_init(void) { int ret = 0; - - if (!init) goto cleanup; + + need_conntrack(); ret = nf_register_sockopt(&so_getorigdst); if (ret < 0) { printk(KERN_ERR "Unable to register netfilter socket option\n"); - goto cleanup_nothing; + return ret; } ret = nf_conntrack_protocol_register(&nf_conntrack_protocol_tcp4); @@ -484,13 +488,10 @@ static int init_or_cleanup(int init) #endif return ret; - cleanup: - synchronize_net(); #ifdef CONFIG_SYSCTL - unregister_sysctl_table(nf_ct_ipv4_sysctl_header); cleanup_hooks: -#endif nf_unregister_hooks(ipv4_conntrack_ops, ARRAY_SIZE(ipv4_conntrack_ops)); +#endif cleanup_ipv4: nf_conntrack_l3proto_unregister(&nf_conntrack_l3proto_ipv4); cleanup_icmp: @@ -501,22 +502,21 @@ static int init_or_cleanup(int init) nf_conntrack_protocol_unregister(&nf_conntrack_protocol_tcp4); cleanup_sockopt: nf_unregister_sockopt(&so_getorigdst); - cleanup_nothing: return ret; } -MODULE_ALIAS("nf_conntrack-" __stringify(AF_INET)); -MODULE_LICENSE("GPL"); - -static int __init nf_conntrack_l3proto_ipv4_init(void) -{ - need_conntrack(); - return init_or_cleanup(1); -} - static void __exit nf_conntrack_l3proto_ipv4_fini(void) { - init_or_cleanup(0); + synchronize_net(); +#ifdef CONFIG_SYSCTL + unregister_sysctl_table(nf_ct_ipv4_sysctl_header); +#endif + nf_unregister_hooks(ipv4_conntrack_ops, ARRAY_SIZE(ipv4_conntrack_ops)); + nf_conntrack_l3proto_unregister(&nf_conntrack_l3proto_ipv4); + nf_conntrack_protocol_unregister(&nf_conntrack_protocol_icmp); + nf_conntrack_protocol_unregister(&nf_conntrack_protocol_udp4); + nf_conntrack_protocol_unregister(&nf_conntrack_protocol_tcp4); + nf_unregister_sockopt(&so_getorigdst); } module_init(nf_conntrack_l3proto_ipv4_init); diff --git a/net/ipv6/netfilter/ip6_queue.c b/net/ipv6/netfilter/ip6_queue.c index e81c6a9..fa23ffe 100644 --- a/net/ipv6/netfilter/ip6_queue.c +++ b/net/ipv6/netfilter/ip6_queue.c @@ -658,15 +658,11 @@ static struct nf_queue_handler nfqh = { .outfn = &ipq_enqueue_packet, }; -static int -init_or_cleanup(int init) +static int __init ip6_queue_init(void) { int status = -ENOMEM; struct proc_dir_entry *proc; - if (!init) - goto cleanup; - netlink_register_notifier(&ipq_nl_notifier); ipqnl = netlink_kernel_create(NETLINK_IP6_FW, 0, ipq_rcv_sk, THIS_MODULE); @@ -693,11 +689,6 @@ init_or_cleanup(int init) } return status; -cleanup: - nf_unregister_queue_handlers(&nfqh); - synchronize_net(); - ipq_flush(NF_DROP); - cleanup_sysctl: unregister_sysctl_table(ipq_sysctl_header); unregister_netdevice_notifier(&ipq_dev_notifier); @@ -713,15 +704,21 @@ cleanup_netlink_notifier: return status; } -static int __init ip6_queue_init(void) -{ - - return init_or_cleanup(1); -} - static void __exit ip6_queue_fini(void) { - init_or_cleanup(0); + nf_unregister_queue_handlers(&nfqh); + synchronize_net(); + ipq_flush(NF_DROP); + + unregister_sysctl_table(ipq_sysctl_header); + unregister_netdevice_notifier(&ipq_dev_notifier); + proc_net_remove(IPQ_PROC_FS_NAME); + + sock_release(ipqnl->sk_socket); + mutex_lock(&ipqnl_mutex); + mutex_unlock(&ipqnl_mutex); + + netlink_unregister_notifier(&ipq_nl_notifier); } MODULE_DESCRIPTION("IPv6 packet queue handler"); diff --git a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c index 0426ed0..93bae36 100644 --- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c +++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c @@ -464,16 +464,21 @@ extern struct nf_conntrack_protocol nf_c extern struct nf_conntrack_protocol nf_conntrack_protocol_icmpv6; extern int nf_ct_frag6_init(void); extern void nf_ct_frag6_cleanup(void); -static int init_or_cleanup(int init) + +MODULE_ALIAS("nf_conntrack-" __stringify(AF_INET6)); +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Yasuyuki KOZAKAI @USAGI "); + +static int __init nf_conntrack_l3proto_ipv6_init(void) { int ret = 0; - if (!init) goto cleanup; + need_conntrack(); ret = nf_ct_frag6_init(); if (ret < 0) { printk("nf_conntrack_ipv6: can't initialize frag6.\n"); - goto cleanup_nothing; + return ret; } ret = nf_conntrack_protocol_register(&nf_conntrack_protocol_tcp6); if (ret < 0) { @@ -516,13 +521,10 @@ static int init_or_cleanup(int init) #endif return ret; - cleanup: - synchronize_net(); #ifdef CONFIG_SYSCTL - unregister_sysctl_table(nf_ct_ipv6_sysctl_header); cleanup_hooks: -#endif nf_unregister_hooks(ipv6_conntrack_ops, ARRAY_SIZE(ipv6_conntrack_ops)); +#endif cleanup_ipv6: nf_conntrack_l3proto_unregister(&nf_conntrack_l3proto_ipv6); cleanup_icmpv6: @@ -533,23 +535,21 @@ static int init_or_cleanup(int init) nf_conntrack_protocol_unregister(&nf_conntrack_protocol_tcp6); cleanup_frag6: nf_ct_frag6_cleanup(); - cleanup_nothing: return ret; } -MODULE_ALIAS("nf_conntrack-" __stringify(AF_INET6)); -MODULE_LICENSE("GPL"); -MODULE_AUTHOR("Yasuyuki KOZAKAI @USAGI "); - -static int __init nf_conntrack_l3proto_ipv6_init(void) -{ - need_conntrack(); - return init_or_cleanup(1); -} - static void __exit nf_conntrack_l3proto_ipv6_fini(void) { - init_or_cleanup(0); + synchronize_net(); +#ifdef CONFIG_SYSCTL + unregister_sysctl_table(nf_ct_ipv6_sysctl_header); +#endif + nf_unregister_hooks(ipv6_conntrack_ops, ARRAY_SIZE(ipv6_conntrack_ops)); + nf_conntrack_l3proto_unregister(&nf_conntrack_l3proto_ipv6); + nf_conntrack_protocol_unregister(&nf_conntrack_protocol_icmpv6); + nf_conntrack_protocol_unregister(&nf_conntrack_protocol_udp6); + nf_conntrack_protocol_unregister(&nf_conntrack_protocol_tcp6); + nf_ct_frag6_cleanup(); } module_init(nf_conntrack_l3proto_ipv6_init); diff --git a/net/netfilter/nf_conntrack_standalone.c b/net/netfilter/nf_conntrack_standalone.c index c72aa3c..408960c 100644 --- a/net/netfilter/nf_conntrack_standalone.c +++ b/net/netfilter/nf_conntrack_standalone.c @@ -649,63 +649,6 @@ static ctl_table nf_ct_net_table[] = { EXPORT_SYMBOL(nf_ct_log_invalid); #endif /* CONFIG_SYSCTL */ -static int init_or_cleanup(int init) -{ -#ifdef CONFIG_PROC_FS - struct proc_dir_entry *proc, *proc_exp, *proc_stat; -#endif - int ret = 0; - - if (!init) goto cleanup; - - ret = nf_conntrack_init(); - if (ret < 0) - goto cleanup_nothing; - -#ifdef CONFIG_PROC_FS - proc = proc_net_fops_create("nf_conntrack", 0440, &ct_file_ops); - if (!proc) goto cleanup_init; - - proc_exp = proc_net_fops_create("nf_conntrack_expect", 0440, - &exp_file_ops); - if (!proc_exp) goto cleanup_proc; - - proc_stat = create_proc_entry("nf_conntrack", S_IRUGO, proc_net_stat); - if (!proc_stat) - goto cleanup_proc_exp; - - proc_stat->proc_fops = &ct_cpu_seq_fops; - proc_stat->owner = THIS_MODULE; -#endif -#ifdef CONFIG_SYSCTL - nf_ct_sysctl_header = register_sysctl_table(nf_ct_net_table, 0); - if (nf_ct_sysctl_header == NULL) { - printk("nf_conntrack: can't register to sysctl.\n"); - ret = -ENOMEM; - goto cleanup_proc_stat; - } -#endif - - return ret; - - cleanup: -#ifdef CONFIG_SYSCTL - unregister_sysctl_table(nf_ct_sysctl_header); - cleanup_proc_stat: -#endif -#ifdef CONFIG_PROC_FS - remove_proc_entry("nf_conntrack", proc_net_stat); - cleanup_proc_exp: - proc_net_remove("nf_conntrack_expect"); - cleanup_proc: - proc_net_remove("nf_conntrack"); - cleanup_init: -#endif /* CNFIG_PROC_FS */ - nf_conntrack_cleanup(); - cleanup_nothing: - return ret; -} - int nf_conntrack_l3proto_register(struct nf_conntrack_l3proto *proto) { int ret = 0; @@ -808,12 +751,66 @@ void nf_conntrack_protocol_unregister(st static int __init nf_conntrack_standalone_init(void) { - return init_or_cleanup(1); +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *proc, *proc_exp, *proc_stat; +#endif + int ret = 0; + + ret = nf_conntrack_init(); + if (ret < 0) + return ret; + +#ifdef CONFIG_PROC_FS + proc = proc_net_fops_create("nf_conntrack", 0440, &ct_file_ops); + if (!proc) goto cleanup_init; + + proc_exp = proc_net_fops_create("nf_conntrack_expect", 0440, + &exp_file_ops); + if (!proc_exp) goto cleanup_proc; + + proc_stat = create_proc_entry("nf_conntrack", S_IRUGO, proc_net_stat); + if (!proc_stat) + goto cleanup_proc_exp; + + proc_stat->proc_fops = &ct_cpu_seq_fops; + proc_stat->owner = THIS_MODULE; +#endif +#ifdef CONFIG_SYSCTL + nf_ct_sysctl_header = register_sysctl_table(nf_ct_net_table, 0); + if (nf_ct_sysctl_header == NULL) { + printk("nf_conntrack: can't register to sysctl.\n"); + ret = -ENOMEM; + goto cleanup_proc_stat; + } +#endif + return ret; + +#ifdef CONFIG_SYSCTL + cleanup_proc_stat: +#endif +#ifdef CONFIG_PROC_FS + remove_proc_entry("nf_conntrack", proc_net_stat); + cleanup_proc_exp: + proc_net_remove("nf_conntrack_expect"); + cleanup_proc: + proc_net_remove("nf_conntrack"); + cleanup_init: +#endif /* CNFIG_PROC_FS */ + nf_conntrack_cleanup(); + return ret; } static void __exit nf_conntrack_standalone_fini(void) { - init_or_cleanup(0); +#ifdef CONFIG_SYSCTL + unregister_sysctl_table(nf_ct_sysctl_header); +#endif +#ifdef CONFIG_PROC_FS + remove_proc_entry("nf_conntrack", proc_net_stat); + proc_net_remove("nf_conntrack_expect"); + proc_net_remove("nf_conntrack"); +#endif /* CNFIG_PROC_FS */ + nf_conntrack_cleanup(); } module_init(nf_conntrack_standalone_init); diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c index 3e3f544..c60273c 100644 --- a/net/netfilter/nfnetlink_log.c +++ b/net/netfilter/nfnetlink_log.c @@ -1033,17 +1033,13 @@ static struct file_operations nful_file_ #endif /* PROC_FS */ -static int -init_or_cleanup(int init) +static int __init nfnetlink_log_init(void) { int i, status = -ENOMEM; #ifdef CONFIG_PROC_FS struct proc_dir_entry *proc_nful; #endif - if (!init) - goto cleanup; - for (i = 0; i < INSTANCE_BUCKETS; i++) INIT_HLIST_HEAD(&instance_table[i]); @@ -1066,30 +1062,25 @@ init_or_cleanup(int init) goto cleanup_subsys; proc_nful->proc_fops = &nful_file_ops; #endif - return status; -cleanup: - nf_log_unregister_logger(&nfulnl_logger); #ifdef CONFIG_PROC_FS - remove_proc_entry("nfnetlink_log", proc_net_netfilter); cleanup_subsys: -#endif nfnetlink_subsys_unregister(&nfulnl_subsys); +#endif cleanup_netlink_notifier: netlink_unregister_notifier(&nfulnl_rtnl_notifier); return status; } -static int __init nfnetlink_log_init(void) -{ - - return init_or_cleanup(1); -} - static void __exit nfnetlink_log_fini(void) { - init_or_cleanup(0); + nf_log_unregister_logger(&nfulnl_logger); +#ifdef CONFIG_PROC_FS + remove_proc_entry("nfnetlink_log", proc_net_netfilter); +#endif + nfnetlink_subsys_unregister(&nfulnl_subsys); + netlink_unregister_notifier(&nfulnl_rtnl_notifier); } MODULE_DESCRIPTION("netfilter userspace logging"); diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c index d0e62f6..b93bcd3 100644 --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -1071,17 +1071,13 @@ static struct file_operations nfqnl_file #endif /* PROC_FS */ -static int -init_or_cleanup(int init) +static int __init nfnetlink_queue_init(void) { int i, status = -ENOMEM; #ifdef CONFIG_PROC_FS struct proc_dir_entry *proc_nfqueue; #endif - if (!init) - goto cleanup; - for (i = 0; i < INSTANCE_BUCKETS; i++) INIT_HLIST_HEAD(&instance_table[i]); @@ -1101,31 +1097,26 @@ init_or_cleanup(int init) #endif register_netdevice_notifier(&nfqnl_dev_notifier); - return status; -cleanup: - nf_unregister_queue_handlers(&nfqh); - unregister_netdevice_notifier(&nfqnl_dev_notifier); #ifdef CONFIG_PROC_FS - remove_proc_entry("nfnetlink_queue", proc_net_netfilter); cleanup_subsys: -#endif nfnetlink_subsys_unregister(&nfqnl_subsys); +#endif cleanup_netlink_notifier: netlink_unregister_notifier(&nfqnl_rtnl_notifier); return status; } -static int __init nfnetlink_queue_init(void) -{ - - return init_or_cleanup(1); -} - static void __exit nfnetlink_queue_fini(void) { - init_or_cleanup(0); + nf_unregister_queue_handlers(&nfqh); + unregister_netdevice_notifier(&nfqnl_dev_notifier); +#ifdef CONFIG_PROC_FS + remove_proc_entry("nfnetlink_queue", proc_net_netfilter); +#endif + nfnetlink_subsys_unregister(&nfqnl_subsys); + netlink_unregister_notifier(&nfqnl_rtnl_notifier); } MODULE_DESCRIPTION("netfilter packet queue handler"); From kaber at trash.net Thu Apr 6 12:04:55 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:20 2006 Subject: [NETFILTER 02/12]: Clean up hook registration In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100455.17409.91188.sendpatchset@localhost.localdomain> [NETFILTER]: Clean up hook registration Clean up hook registration by makeing use of the new mass registration and unregistration helpers. Signed-off-by: Patrick McHardy --- commit 2f8e62d3a554aee067771c5146a1e29feecd2758 tree ea5cdb8d6c319c334007c87c1e859ae0ed41f3f5 parent 3bf0d209e539917efcc5286b8f1cab2856ebdd49 author Patrick McHardy Thu, 06 Apr 2006 11:34:13 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:34:13 +0200 net/ipv4/netfilter/arptable_filter.c | 19 +- net/ipv4/netfilter/ip_conntrack_standalone.c | 180 ++++++++--------------- net/ipv4/netfilter/ip_nat_standalone.c | 143 +++++++----------- net/ipv4/netfilter/iptable_filter.c | 21 --- net/ipv4/netfilter/iptable_mangle.c | 33 ---- net/ipv4/netfilter/iptable_raw.c | 35 ++-- net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 189 ++++++++---------------- net/ipv6/netfilter/ip6table_filter.c | 21 --- net/ipv6/netfilter/ip6table_mangle.c | 33 ---- net/ipv6/netfilter/ip6table_raw.c | 15 -- net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 143 ++++++------------ 11 files changed, 253 insertions(+), 579 deletions(-) diff --git a/net/ipv4/netfilter/arptable_filter.c b/net/ipv4/netfilter/arptable_filter.c index d0d379c..d7c472f 100644 --- a/net/ipv4/netfilter/arptable_filter.c +++ b/net/ipv4/netfilter/arptable_filter.c @@ -181,33 +181,26 @@ static struct nf_hook_ops arpt_ops[] = { static int __init arptable_filter_init(void) { - int ret, i; + int ret; /* Register table */ ret = arpt_register_table(&packet_filter, &initial_table.repl); if (ret < 0) return ret; - for (i = 0; i < ARRAY_SIZE(arpt_ops); i++) - if ((ret = nf_register_hook(&arpt_ops[i])) < 0) - goto cleanup_hooks; + ret = nf_register_hooks(arpt_ops, ARRAY_SIZE(arpt_ops)); + if (ret < 0) + goto cleanup_table; return ret; -cleanup_hooks: - while (--i >= 0) - nf_unregister_hook(&arpt_ops[i]); - +cleanup_table: arpt_unregister_table(&packet_filter); return ret; } static void __exit arptable_filter_fini(void) { - unsigned int i; - - for (i = 0; i < ARRAY_SIZE(arpt_ops); i++) - nf_unregister_hook(&arpt_ops[i]); - + nf_unregister_hooks(arpt_ops, ARRAY_SIZE(arpt_ops)); arpt_unregister_table(&packet_filter); } diff --git a/net/ipv4/netfilter/ip_conntrack_standalone.c b/net/ipv4/netfilter/ip_conntrack_standalone.c index 5207602..adc1a0f 100644 --- a/net/ipv4/netfilter/ip_conntrack_standalone.c +++ b/net/ipv4/netfilter/ip_conntrack_standalone.c @@ -469,70 +469,63 @@ static unsigned int ip_conntrack_local(u /* Connection tracking may drop packets, but never alters them, so make it the first hook. */ -static struct nf_hook_ops ip_conntrack_defrag_ops = { - .hook = ip_conntrack_defrag, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_PRE_ROUTING, - .priority = NF_IP_PRI_CONNTRACK_DEFRAG, -}; - -static struct nf_hook_ops ip_conntrack_in_ops = { - .hook = ip_conntrack_in, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_PRE_ROUTING, - .priority = NF_IP_PRI_CONNTRACK, -}; - -static struct nf_hook_ops ip_conntrack_defrag_local_out_ops = { - .hook = ip_conntrack_defrag, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_OUT, - .priority = NF_IP_PRI_CONNTRACK_DEFRAG, -}; - -static struct nf_hook_ops ip_conntrack_local_out_ops = { - .hook = ip_conntrack_local, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_OUT, - .priority = NF_IP_PRI_CONNTRACK, -}; - -/* helpers */ -static struct nf_hook_ops ip_conntrack_helper_out_ops = { - .hook = ip_conntrack_help, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_POST_ROUTING, - .priority = NF_IP_PRI_CONNTRACK_HELPER, -}; - -static struct nf_hook_ops ip_conntrack_helper_in_ops = { - .hook = ip_conntrack_help, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_IN, - .priority = NF_IP_PRI_CONNTRACK_HELPER, -}; - -/* Refragmenter; last chance. */ -static struct nf_hook_ops ip_conntrack_out_ops = { - .hook = ip_confirm, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_POST_ROUTING, - .priority = NF_IP_PRI_CONNTRACK_CONFIRM, -}; - -static struct nf_hook_ops ip_conntrack_local_in_ops = { - .hook = ip_confirm, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_IN, - .priority = NF_IP_PRI_CONNTRACK_CONFIRM, +static struct nf_hook_ops ip_conntrack_ops[] = { + { + .hook = ip_conntrack_defrag, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_PRE_ROUTING, + .priority = NF_IP_PRI_CONNTRACK_DEFRAG, + }, + { + .hook = ip_conntrack_in, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_PRE_ROUTING, + .priority = NF_IP_PRI_CONNTRACK, + }, + { + .hook = ip_conntrack_defrag, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_OUT, + .priority = NF_IP_PRI_CONNTRACK_DEFRAG, + }, + { + .hook = ip_conntrack_local, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_OUT, + .priority = NF_IP_PRI_CONNTRACK, + }, + { + .hook = ip_conntrack_help, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_CONNTRACK_HELPER, + }, + { + .hook = ip_conntrack_help, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_IN, + .priority = NF_IP_PRI_CONNTRACK_HELPER, + }, + { + .hook = ip_confirm, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_CONNTRACK_CONFIRM, + }, + { + .hook = ip_confirm, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_IN, + .priority = NF_IP_PRI_CONNTRACK_CONFIRM, + }, }; /* Sysctl support */ @@ -813,52 +806,17 @@ static int init_or_cleanup(int init) proc_stat->owner = THIS_MODULE; #endif - ret = nf_register_hook(&ip_conntrack_defrag_ops); + ret = nf_register_hooks(ip_conntrack_ops, ARRAY_SIZE(ip_conntrack_ops)); if (ret < 0) { - printk("ip_conntrack: can't register pre-routing defrag hook.\n"); + printk("ip_conntrack: can't register hooks.\n"); goto cleanup_proc_stat; } - ret = nf_register_hook(&ip_conntrack_defrag_local_out_ops); - if (ret < 0) { - printk("ip_conntrack: can't register local_out defrag hook.\n"); - goto cleanup_defragops; - } - ret = nf_register_hook(&ip_conntrack_in_ops); - if (ret < 0) { - printk("ip_conntrack: can't register pre-routing hook.\n"); - goto cleanup_defraglocalops; - } - ret = nf_register_hook(&ip_conntrack_local_out_ops); - if (ret < 0) { - printk("ip_conntrack: can't register local out hook.\n"); - goto cleanup_inops; - } - ret = nf_register_hook(&ip_conntrack_helper_in_ops); - if (ret < 0) { - printk("ip_conntrack: can't register local in helper hook.\n"); - goto cleanup_inandlocalops; - } - ret = nf_register_hook(&ip_conntrack_helper_out_ops); - if (ret < 0) { - printk("ip_conntrack: can't register postrouting helper hook.\n"); - goto cleanup_helperinops; - } - ret = nf_register_hook(&ip_conntrack_out_ops); - if (ret < 0) { - printk("ip_conntrack: can't register post-routing hook.\n"); - goto cleanup_helperoutops; - } - ret = nf_register_hook(&ip_conntrack_local_in_ops); - if (ret < 0) { - printk("ip_conntrack: can't register local in hook.\n"); - goto cleanup_inoutandlocalops; - } #ifdef CONFIG_SYSCTL ip_ct_sysctl_header = register_sysctl_table(ip_ct_net_table, 0); if (ip_ct_sysctl_header == NULL) { printk("ip_conntrack: can't register to sysctl.\n"); ret = -ENOMEM; - goto cleanup_localinops; + goto cleanup_hooks; } #endif @@ -868,23 +826,9 @@ static int init_or_cleanup(int init) synchronize_net(); #ifdef CONFIG_SYSCTL unregister_sysctl_table(ip_ct_sysctl_header); - cleanup_localinops: + cleanup_hooks: #endif - nf_unregister_hook(&ip_conntrack_local_in_ops); - cleanup_inoutandlocalops: - nf_unregister_hook(&ip_conntrack_out_ops); - cleanup_helperoutops: - nf_unregister_hook(&ip_conntrack_helper_out_ops); - cleanup_helperinops: - nf_unregister_hook(&ip_conntrack_helper_in_ops); - cleanup_inandlocalops: - nf_unregister_hook(&ip_conntrack_local_out_ops); - cleanup_inops: - nf_unregister_hook(&ip_conntrack_in_ops); - cleanup_defraglocalops: - nf_unregister_hook(&ip_conntrack_defrag_local_out_ops); - cleanup_defragops: - nf_unregister_hook(&ip_conntrack_defrag_ops); + nf_unregister_hooks(ip_conntrack_ops, ARRAY_SIZE(ip_conntrack_ops)); cleanup_proc_stat: #ifdef CONFIG_PROC_FS remove_proc_entry("ip_conntrack", proc_net_stat); diff --git a/net/ipv4/netfilter/ip_nat_standalone.c b/net/ipv4/netfilter/ip_nat_standalone.c index 3505b0d..5f02f43 100644 --- a/net/ipv4/netfilter/ip_nat_standalone.c +++ b/net/ipv4/netfilter/ip_nat_standalone.c @@ -299,61 +299,57 @@ ip_nat_adjust(unsigned int hooknum, /* We must be after connection tracking and before packet filtering. */ -/* Before packet filtering, change destination */ -static struct nf_hook_ops ip_nat_in_ops = { - .hook = ip_nat_in, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_PRE_ROUTING, - .priority = NF_IP_PRI_NAT_DST, +static struct nf_hook_ops ip_nat_ops[] = { + /* Before packet filtering, change destination */ + { + .hook = ip_nat_in, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_PRE_ROUTING, + .priority = NF_IP_PRI_NAT_DST, + }, + /* After packet filtering, change source */ + { + .hook = ip_nat_out, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_NAT_SRC, + }, + /* After conntrack, adjust sequence number */ + { + .hook = ip_nat_adjust, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_NAT_SEQ_ADJUST, + }, + /* Before packet filtering, change destination */ + { + .hook = ip_nat_local_fn, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_OUT, + .priority = NF_IP_PRI_NAT_DST, + }, + /* After packet filtering, change source */ + { + .hook = ip_nat_fn, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_IN, + .priority = NF_IP_PRI_NAT_SRC, + }, + /* After conntrack, adjust sequence number */ + { + .hook = ip_nat_adjust, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_IN, + .priority = NF_IP_PRI_NAT_SEQ_ADJUST, + }, }; -/* After packet filtering, change source */ -static struct nf_hook_ops ip_nat_out_ops = { - .hook = ip_nat_out, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_POST_ROUTING, - .priority = NF_IP_PRI_NAT_SRC, -}; - -/* After conntrack, adjust sequence number */ -static struct nf_hook_ops ip_nat_adjust_out_ops = { - .hook = ip_nat_adjust, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_POST_ROUTING, - .priority = NF_IP_PRI_NAT_SEQ_ADJUST, -}; - -/* Before packet filtering, change destination */ -static struct nf_hook_ops ip_nat_local_out_ops = { - .hook = ip_nat_local_fn, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_OUT, - .priority = NF_IP_PRI_NAT_DST, -}; - -/* After packet filtering, change source for reply packets of LOCAL_OUT DNAT */ -static struct nf_hook_ops ip_nat_local_in_ops = { - .hook = ip_nat_fn, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_IN, - .priority = NF_IP_PRI_NAT_SRC, -}; - -/* After conntrack, adjust sequence number */ -static struct nf_hook_ops ip_nat_adjust_in_ops = { - .hook = ip_nat_adjust, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_IN, - .priority = NF_IP_PRI_NAT_SEQ_ADJUST, -}; - - static int init_or_cleanup(int init) { int ret = 0; @@ -371,50 +367,15 @@ static int init_or_cleanup(int init) printk("ip_nat_init: can't setup rules.\n"); goto cleanup_decode_session; } - ret = nf_register_hook(&ip_nat_in_ops); + ret = nf_register_hooks(ip_nat_ops, ARRAY_SIZE(ip_nat_ops)); if (ret < 0) { - printk("ip_nat_init: can't register in hook.\n"); + printk("ip_nat_init: can't register hooks.\n"); goto cleanup_rule_init; } - ret = nf_register_hook(&ip_nat_out_ops); - if (ret < 0) { - printk("ip_nat_init: can't register out hook.\n"); - goto cleanup_inops; - } - ret = nf_register_hook(&ip_nat_adjust_in_ops); - if (ret < 0) { - printk("ip_nat_init: can't register adjust in hook.\n"); - goto cleanup_outops; - } - ret = nf_register_hook(&ip_nat_adjust_out_ops); - if (ret < 0) { - printk("ip_nat_init: can't register adjust out hook.\n"); - goto cleanup_adjustin_ops; - } - ret = nf_register_hook(&ip_nat_local_out_ops); - if (ret < 0) { - printk("ip_nat_init: can't register local out hook.\n"); - goto cleanup_adjustout_ops; - } - ret = nf_register_hook(&ip_nat_local_in_ops); - if (ret < 0) { - printk("ip_nat_init: can't register local in hook.\n"); - goto cleanup_localoutops; - } return ret; cleanup: - nf_unregister_hook(&ip_nat_local_in_ops); - cleanup_localoutops: - nf_unregister_hook(&ip_nat_local_out_ops); - cleanup_adjustout_ops: - nf_unregister_hook(&ip_nat_adjust_out_ops); - cleanup_adjustin_ops: - nf_unregister_hook(&ip_nat_adjust_in_ops); - cleanup_outops: - nf_unregister_hook(&ip_nat_out_ops); - cleanup_inops: - nf_unregister_hook(&ip_nat_in_ops); + nf_unregister_hooks(ip_nat_ops, ARRAY_SIZE(ip_nat_ops)); cleanup_rule_init: ip_nat_rule_cleanup(); cleanup_decode_session: diff --git a/net/ipv4/netfilter/iptable_filter.c b/net/ipv4/netfilter/iptable_filter.c index 3d80aef..7f41748 100644 --- a/net/ipv4/netfilter/iptable_filter.c +++ b/net/ipv4/netfilter/iptable_filter.c @@ -157,37 +157,20 @@ static int __init iptable_filter_init(vo return ret; /* Register hooks */ - ret = nf_register_hook(&ipt_ops[0]); + ret = nf_register_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); if (ret < 0) goto cleanup_table; - ret = nf_register_hook(&ipt_ops[1]); - if (ret < 0) - goto cleanup_hook0; - - ret = nf_register_hook(&ipt_ops[2]); - if (ret < 0) - goto cleanup_hook1; - return ret; - cleanup_hook1: - nf_unregister_hook(&ipt_ops[1]); - cleanup_hook0: - nf_unregister_hook(&ipt_ops[0]); cleanup_table: ipt_unregister_table(&packet_filter); - return ret; } static void __exit iptable_filter_fini(void) { - unsigned int i; - - for (i = 0; i < sizeof(ipt_ops)/sizeof(struct nf_hook_ops); i++) - nf_unregister_hook(&ipt_ops[i]); - + nf_unregister_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); ipt_unregister_table(&packet_filter); } diff --git a/net/ipv4/netfilter/iptable_mangle.c b/net/ipv4/netfilter/iptable_mangle.c index 412fc96..397b95c 100644 --- a/net/ipv4/netfilter/iptable_mangle.c +++ b/net/ipv4/netfilter/iptable_mangle.c @@ -211,49 +211,20 @@ static int __init iptable_mangle_init(vo return ret; /* Register hooks */ - ret = nf_register_hook(&ipt_ops[0]); + ret = nf_register_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); if (ret < 0) goto cleanup_table; - ret = nf_register_hook(&ipt_ops[1]); - if (ret < 0) - goto cleanup_hook0; - - ret = nf_register_hook(&ipt_ops[2]); - if (ret < 0) - goto cleanup_hook1; - - ret = nf_register_hook(&ipt_ops[3]); - if (ret < 0) - goto cleanup_hook2; - - ret = nf_register_hook(&ipt_ops[4]); - if (ret < 0) - goto cleanup_hook3; - return ret; - cleanup_hook3: - nf_unregister_hook(&ipt_ops[3]); - cleanup_hook2: - nf_unregister_hook(&ipt_ops[2]); - cleanup_hook1: - nf_unregister_hook(&ipt_ops[1]); - cleanup_hook0: - nf_unregister_hook(&ipt_ops[0]); cleanup_table: ipt_unregister_table(&packet_mangler); - return ret; } static void __exit iptable_mangle_fini(void) { - unsigned int i; - - for (i = 0; i < sizeof(ipt_ops)/sizeof(struct nf_hook_ops); i++) - nf_unregister_hook(&ipt_ops[i]); - + nf_unregister_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); ipt_unregister_table(&packet_mangler); } diff --git a/net/ipv4/netfilter/iptable_raw.c b/net/ipv4/netfilter/iptable_raw.c index 03cc79a..be43dfb 100644 --- a/net/ipv4/netfilter/iptable_raw.c +++ b/net/ipv4/netfilter/iptable_raw.c @@ -101,18 +101,18 @@ ipt_hook(unsigned int hook, /* 'raw' is the very first table. */ static struct nf_hook_ops ipt_ops[] = { { - .hook = ipt_hook, - .pf = PF_INET, - .hooknum = NF_IP_PRE_ROUTING, - .priority = NF_IP_PRI_RAW, - .owner = THIS_MODULE, + .hook = ipt_hook, + .pf = PF_INET, + .hooknum = NF_IP_PRE_ROUTING, + .priority = NF_IP_PRI_RAW, + .owner = THIS_MODULE, }, { - .hook = ipt_hook, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_OUT, - .priority = NF_IP_PRI_RAW, - .owner = THIS_MODULE, + .hook = ipt_hook, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_OUT, + .priority = NF_IP_PRI_RAW, + .owner = THIS_MODULE, }, }; @@ -126,31 +126,20 @@ static int __init iptable_raw_init(void) return ret; /* Register hooks */ - ret = nf_register_hook(&ipt_ops[0]); + ret = nf_register_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); if (ret < 0) goto cleanup_table; - ret = nf_register_hook(&ipt_ops[1]); - if (ret < 0) - goto cleanup_hook0; - return ret; - cleanup_hook0: - nf_unregister_hook(&ipt_ops[0]); cleanup_table: ipt_unregister_table(&packet_raw); - return ret; } static void __exit iptable_raw_fini(void) { - unsigned int i; - - for (i = 0; i < sizeof(ipt_ops)/sizeof(struct nf_hook_ops); i++) - nf_unregister_hook(&ipt_ops[i]); - + nf_unregister_hooks(ipt_ops, ARRAY_SIZE(ipt_ops)); ipt_unregister_table(&packet_raw); } diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c index 4afbc69..3fadacc 100644 --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c @@ -210,71 +210,63 @@ static unsigned int ipv4_conntrack_local /* Connection tracking may drop packets, but never alters them, so make it the first hook. */ -static struct nf_hook_ops ipv4_conntrack_defrag_ops = { - .hook = ipv4_conntrack_defrag, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_PRE_ROUTING, - .priority = NF_IP_PRI_CONNTRACK_DEFRAG, -}; - -static struct nf_hook_ops ipv4_conntrack_in_ops = { - .hook = ipv4_conntrack_in, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_PRE_ROUTING, - .priority = NF_IP_PRI_CONNTRACK, -}; - -static struct nf_hook_ops ipv4_conntrack_defrag_local_out_ops = { - .hook = ipv4_conntrack_defrag, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_OUT, - .priority = NF_IP_PRI_CONNTRACK_DEFRAG, -}; - -static struct nf_hook_ops ipv4_conntrack_local_out_ops = { - .hook = ipv4_conntrack_local, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_OUT, - .priority = NF_IP_PRI_CONNTRACK, -}; - -/* helpers */ -static struct nf_hook_ops ipv4_conntrack_helper_out_ops = { - .hook = ipv4_conntrack_help, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_POST_ROUTING, - .priority = NF_IP_PRI_CONNTRACK_HELPER, -}; - -static struct nf_hook_ops ipv4_conntrack_helper_in_ops = { - .hook = ipv4_conntrack_help, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_IN, - .priority = NF_IP_PRI_CONNTRACK_HELPER, -}; - - -/* Refragmenter; last chance. */ -static struct nf_hook_ops ipv4_conntrack_out_ops = { - .hook = ipv4_confirm, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_POST_ROUTING, - .priority = NF_IP_PRI_CONNTRACK_CONFIRM, -}; - -static struct nf_hook_ops ipv4_conntrack_local_in_ops = { - .hook = ipv4_confirm, - .owner = THIS_MODULE, - .pf = PF_INET, - .hooknum = NF_IP_LOCAL_IN, - .priority = NF_IP_PRI_CONNTRACK_CONFIRM, +static struct nf_hook_ops ipv4_conntrack_ops[] = { + { + .hook = ipv4_conntrack_defrag, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_PRE_ROUTING, + .priority = NF_IP_PRI_CONNTRACK_DEFRAG, + }, + { + .hook = ipv4_conntrack_in, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_PRE_ROUTING, + .priority = NF_IP_PRI_CONNTRACK, + }, + { + .hook = ipv4_conntrack_defrag, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_OUT, + .priority = NF_IP_PRI_CONNTRACK_DEFRAG, + }, + { + .hook = ipv4_conntrack_local, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_OUT, + .priority = NF_IP_PRI_CONNTRACK, + }, + { + .hook = ipv4_conntrack_help, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_CONNTRACK_HELPER, + }, + { + .hook = ipv4_conntrack_help, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_IN, + .priority = NF_IP_PRI_CONNTRACK_HELPER, + }, + { + .hook = ipv4_confirm, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_CONNTRACK_CONFIRM, + }, + { + .hook = ipv4_confirm, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_LOCAL_IN, + .priority = NF_IP_PRI_CONNTRACK_CONFIRM, + }, }; #ifdef CONFIG_SYSCTL @@ -476,59 +468,18 @@ static int init_or_cleanup(int init) goto cleanup_icmp; } - ret = nf_register_hook(&ipv4_conntrack_defrag_ops); + ret = nf_register_hooks(ipv4_conntrack_ops, + ARRAY_SIZE(ipv4_conntrack_ops)); if (ret < 0) { - printk("nf_conntrack_ipv4: can't register pre-routing defrag hook.\n"); + printk("nf_conntrack_ipv4: can't register hooks.\n"); goto cleanup_ipv4; } - ret = nf_register_hook(&ipv4_conntrack_defrag_local_out_ops); - if (ret < 0) { - printk("nf_conntrack_ipv4: can't register local_out defrag hook.\n"); - goto cleanup_defragops; - } - - ret = nf_register_hook(&ipv4_conntrack_in_ops); - if (ret < 0) { - printk("nf_conntrack_ipv4: can't register pre-routing hook.\n"); - goto cleanup_defraglocalops; - } - - ret = nf_register_hook(&ipv4_conntrack_local_out_ops); - if (ret < 0) { - printk("nf_conntrack_ipv4: can't register local out hook.\n"); - goto cleanup_inops; - } - - ret = nf_register_hook(&ipv4_conntrack_helper_in_ops); - if (ret < 0) { - printk("nf_conntrack_ipv4: can't register local helper hook.\n"); - goto cleanup_inandlocalops; - } - - ret = nf_register_hook(&ipv4_conntrack_helper_out_ops); - if (ret < 0) { - printk("nf_conntrack_ipv4: can't register postrouting helper hook.\n"); - goto cleanup_helperinops; - } - - ret = nf_register_hook(&ipv4_conntrack_out_ops); - if (ret < 0) { - printk("nf_conntrack_ipv4: can't register post-routing hook.\n"); - goto cleanup_helperoutops; - } - - ret = nf_register_hook(&ipv4_conntrack_local_in_ops); - if (ret < 0) { - printk("nf_conntrack_ipv4: can't register local in hook.\n"); - goto cleanup_inoutandlocalops; - } - #ifdef CONFIG_SYSCTL nf_ct_ipv4_sysctl_header = register_sysctl_table(nf_ct_net_table, 0); if (nf_ct_ipv4_sysctl_header == NULL) { printk("nf_conntrack: can't register to sysctl.\n"); ret = -ENOMEM; - goto cleanup_localinops; + goto cleanup_hooks; } #endif return ret; @@ -537,23 +488,9 @@ static int init_or_cleanup(int init) synchronize_net(); #ifdef CONFIG_SYSCTL unregister_sysctl_table(nf_ct_ipv4_sysctl_header); - cleanup_localinops: + cleanup_hooks: #endif - nf_unregister_hook(&ipv4_conntrack_local_in_ops); - cleanup_inoutandlocalops: - nf_unregister_hook(&ipv4_conntrack_out_ops); - cleanup_helperoutops: - nf_unregister_hook(&ipv4_conntrack_helper_out_ops); - cleanup_helperinops: - nf_unregister_hook(&ipv4_conntrack_helper_in_ops); - cleanup_inandlocalops: - nf_unregister_hook(&ipv4_conntrack_local_out_ops); - cleanup_inops: - nf_unregister_hook(&ipv4_conntrack_in_ops); - cleanup_defraglocalops: - nf_unregister_hook(&ipv4_conntrack_defrag_local_out_ops); - cleanup_defragops: - nf_unregister_hook(&ipv4_conntrack_defrag_ops); + nf_unregister_hooks(ipv4_conntrack_ops, ARRAY_SIZE(ipv4_conntrack_ops)); cleanup_ipv4: nf_conntrack_l3proto_unregister(&nf_conntrack_l3proto_ipv4); cleanup_icmp: diff --git a/net/ipv6/netfilter/ip6table_filter.c b/net/ipv6/netfilter/ip6table_filter.c index e5e724d..60976c0 100644 --- a/net/ipv6/netfilter/ip6table_filter.c +++ b/net/ipv6/netfilter/ip6table_filter.c @@ -177,37 +177,20 @@ static int __init ip6table_filter_init(v return ret; /* Register hooks */ - ret = nf_register_hook(&ip6t_ops[0]); + ret = nf_register_hooks(ip6t_ops, ARRAY_SIZE(ip6t_ops)); if (ret < 0) goto cleanup_table; - ret = nf_register_hook(&ip6t_ops[1]); - if (ret < 0) - goto cleanup_hook0; - - ret = nf_register_hook(&ip6t_ops[2]); - if (ret < 0) - goto cleanup_hook1; - return ret; - cleanup_hook1: - nf_unregister_hook(&ip6t_ops[1]); - cleanup_hook0: - nf_unregister_hook(&ip6t_ops[0]); cleanup_table: ip6t_unregister_table(&packet_filter); - return ret; } static void __exit ip6table_filter_fini(void) { - unsigned int i; - - for (i = 0; i < sizeof(ip6t_ops)/sizeof(struct nf_hook_ops); i++) - nf_unregister_hook(&ip6t_ops[i]); - + nf_unregister_hooks(ip6t_ops, ARRAY_SIZE(ip6t_ops)); ip6t_unregister_table(&packet_filter); } diff --git a/net/ipv6/netfilter/ip6table_mangle.c b/net/ipv6/netfilter/ip6table_mangle.c index e1f0f6a..03a13ea 100644 --- a/net/ipv6/netfilter/ip6table_mangle.c +++ b/net/ipv6/netfilter/ip6table_mangle.c @@ -238,49 +238,20 @@ static int __init ip6table_mangle_init(v return ret; /* Register hooks */ - ret = nf_register_hook(&ip6t_ops[0]); + ret = nf_register_hooks(ip6t_ops, ARRAY_SIZE(ip6t_ops)); if (ret < 0) goto cleanup_table; - ret = nf_register_hook(&ip6t_ops[1]); - if (ret < 0) - goto cleanup_hook0; - - ret = nf_register_hook(&ip6t_ops[2]); - if (ret < 0) - goto cleanup_hook1; - - ret = nf_register_hook(&ip6t_ops[3]); - if (ret < 0) - goto cleanup_hook2; - - ret = nf_register_hook(&ip6t_ops[4]); - if (ret < 0) - goto cleanup_hook3; - return ret; - cleanup_hook3: - nf_unregister_hook(&ip6t_ops[3]); - cleanup_hook2: - nf_unregister_hook(&ip6t_ops[2]); - cleanup_hook1: - nf_unregister_hook(&ip6t_ops[1]); - cleanup_hook0: - nf_unregister_hook(&ip6t_ops[0]); cleanup_table: ip6t_unregister_table(&packet_mangler); - return ret; } static void __exit ip6table_mangle_fini(void) { - unsigned int i; - - for (i = 0; i < sizeof(ip6t_ops)/sizeof(struct nf_hook_ops); i++) - nf_unregister_hook(&ip6t_ops[i]); - + nf_unregister_hooks(ip6t_ops, ARRAY_SIZE(ip6t_ops)); ip6t_unregister_table(&packet_mangler); } diff --git a/net/ipv6/netfilter/ip6table_raw.c b/net/ipv6/netfilter/ip6table_raw.c index 54d1fff..61a7c58 100644 --- a/net/ipv6/netfilter/ip6table_raw.c +++ b/net/ipv6/netfilter/ip6table_raw.c @@ -152,31 +152,20 @@ static int __init ip6table_raw_init(void return ret; /* Register hooks */ - ret = nf_register_hook(&ip6t_ops[0]); + ret = nf_register_hooks(ip6t_ops, ARRAY_SIZE(ip6t_ops)); if (ret < 0) goto cleanup_table; - ret = nf_register_hook(&ip6t_ops[1]); - if (ret < 0) - goto cleanup_hook0; - return ret; - cleanup_hook0: - nf_unregister_hook(&ip6t_ops[0]); cleanup_table: ip6t_unregister_table(&packet_raw); - return ret; } static void __exit ip6table_raw_fini(void) { - unsigned int i; - - for (i = 0; i < sizeof(ip6t_ops)/sizeof(struct nf_hook_ops); i++) - nf_unregister_hook(&ip6t_ops[i]); - + nf_unregister_hooks(ip6t_ops, ARRAY_SIZE(ip6t_ops)); ip6t_unregister_table(&packet_raw); } diff --git a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c index c8b5a96..0426ed0 100644 --- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c +++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c @@ -286,55 +286,49 @@ static unsigned int ipv6_conntrack_local return ipv6_conntrack_in(hooknum, pskb, in, out, okfn); } -/* Connection tracking may drop packets, but never alters them, so - make it the first hook. */ -static struct nf_hook_ops ipv6_conntrack_defrag_ops = { - .hook = ipv6_defrag, - .owner = THIS_MODULE, - .pf = PF_INET6, - .hooknum = NF_IP6_PRE_ROUTING, - .priority = NF_IP6_PRI_CONNTRACK_DEFRAG, -}; - -static struct nf_hook_ops ipv6_conntrack_in_ops = { - .hook = ipv6_conntrack_in, - .owner = THIS_MODULE, - .pf = PF_INET6, - .hooknum = NF_IP6_PRE_ROUTING, - .priority = NF_IP6_PRI_CONNTRACK, -}; - -static struct nf_hook_ops ipv6_conntrack_local_out_ops = { - .hook = ipv6_conntrack_local, - .owner = THIS_MODULE, - .pf = PF_INET6, - .hooknum = NF_IP6_LOCAL_OUT, - .priority = NF_IP6_PRI_CONNTRACK, -}; - -static struct nf_hook_ops ipv6_conntrack_defrag_local_out_ops = { - .hook = ipv6_defrag, - .owner = THIS_MODULE, - .pf = PF_INET6, - .hooknum = NF_IP6_LOCAL_OUT, - .priority = NF_IP6_PRI_CONNTRACK_DEFRAG, -}; - -/* Refragmenter; last chance. */ -static struct nf_hook_ops ipv6_conntrack_out_ops = { - .hook = ipv6_confirm, - .owner = THIS_MODULE, - .pf = PF_INET6, - .hooknum = NF_IP6_POST_ROUTING, - .priority = NF_IP6_PRI_LAST, -}; - -static struct nf_hook_ops ipv6_conntrack_local_in_ops = { - .hook = ipv6_confirm, - .owner = THIS_MODULE, - .pf = PF_INET6, - .hooknum = NF_IP6_LOCAL_IN, - .priority = NF_IP6_PRI_LAST-1, +static struct nf_hook_ops ipv6_conntrack_ops[] = { + { + .hook = ipv6_defrag, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_PRE_ROUTING, + .priority = NF_IP6_PRI_CONNTRACK_DEFRAG, + }, + { + .hook = ipv6_conntrack_in, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_PRE_ROUTING, + .priority = NF_IP6_PRI_CONNTRACK, + }, + { + .hook = ipv6_conntrack_local, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_LOCAL_OUT, + .priority = NF_IP6_PRI_CONNTRACK, + }, + { + .hook = ipv6_defrag, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_LOCAL_OUT, + .priority = NF_IP6_PRI_CONNTRACK_DEFRAG, + }, + { + .hook = ipv6_confirm, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_POST_ROUTING, + .priority = NF_IP6_PRI_LAST, + }, + { + .hook = ipv6_confirm, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_LOCAL_IN, + .priority = NF_IP6_PRI_LAST-1, + }, }; #ifdef CONFIG_SYSCTL @@ -505,50 +499,19 @@ static int init_or_cleanup(int init) goto cleanup_icmpv6; } - ret = nf_register_hook(&ipv6_conntrack_defrag_ops); + ret = nf_register_hooks(ipv6_conntrack_ops, + ARRAY_SIZE(ipv6_conntrack_ops)); if (ret < 0) { printk("nf_conntrack_ipv6: can't register pre-routing defrag " "hook.\n"); goto cleanup_ipv6; } - - ret = nf_register_hook(&ipv6_conntrack_defrag_local_out_ops); - if (ret < 0) { - printk("nf_conntrack_ipv6: can't register local_out defrag " - "hook.\n"); - goto cleanup_defragops; - } - - ret = nf_register_hook(&ipv6_conntrack_in_ops); - if (ret < 0) { - printk("nf_conntrack_ipv6: can't register pre-routing hook.\n"); - goto cleanup_defraglocalops; - } - - ret = nf_register_hook(&ipv6_conntrack_local_out_ops); - if (ret < 0) { - printk("nf_conntrack_ipv6: can't register local out hook.\n"); - goto cleanup_inops; - } - - ret = nf_register_hook(&ipv6_conntrack_out_ops); - if (ret < 0) { - printk("nf_conntrack_ipv6: can't register post-routing hook.\n"); - goto cleanup_inandlocalops; - } - - ret = nf_register_hook(&ipv6_conntrack_local_in_ops); - if (ret < 0) { - printk("nf_conntrack_ipv6: can't register local in hook.\n"); - goto cleanup_inoutandlocalops; - } - #ifdef CONFIG_SYSCTL nf_ct_ipv6_sysctl_header = register_sysctl_table(nf_ct_net_table, 0); if (nf_ct_ipv6_sysctl_header == NULL) { printk("nf_conntrack: can't register to sysctl.\n"); ret = -ENOMEM; - goto cleanup_localinops; + goto cleanup_hooks; } #endif return ret; @@ -557,19 +520,9 @@ static int init_or_cleanup(int init) synchronize_net(); #ifdef CONFIG_SYSCTL unregister_sysctl_table(nf_ct_ipv6_sysctl_header); - cleanup_localinops: + cleanup_hooks: #endif - nf_unregister_hook(&ipv6_conntrack_local_in_ops); - cleanup_inoutandlocalops: - nf_unregister_hook(&ipv6_conntrack_out_ops); - cleanup_inandlocalops: - nf_unregister_hook(&ipv6_conntrack_local_out_ops); - cleanup_inops: - nf_unregister_hook(&ipv6_conntrack_in_ops); - cleanup_defraglocalops: - nf_unregister_hook(&ipv6_conntrack_defrag_local_out_ops); - cleanup_defragops: - nf_unregister_hook(&ipv6_conntrack_defrag_ops); + nf_unregister_hooks(ipv6_conntrack_ops, ARRAY_SIZE(ipv6_conntrack_ops)); cleanup_ipv6: nf_conntrack_l3proto_unregister(&nf_conntrack_l3proto_ipv6); cleanup_icmpv6: From kaber at trash.net Thu Apr 6 12:05:00 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:28 2006 Subject: [NETFILTER 05/12]: H.323 helper: change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100500.17409.42955.sendpatchset@localhost.localdomain> [NETFILTER]: H.323 helper: change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit 3c1284349cc00613a738dbd582e6096236c4a44e tree d62e9e0c5af6c4efa448c7650642182cbb5a6418 parent 02fe897a46c3da14bab9fafeaa99692da6ae7fc1 author Jing Min Zhao Thu, 06 Apr 2006 11:41:27 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:41:27 +0200 net/ipv4/netfilter/ip_conntrack_helper_h323.c | 23 +++++++++++------------ 1 files changed, 11 insertions(+), 12 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c index fc817fd..83140d2 100644 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c @@ -1711,18 +1711,17 @@ static int __init init(void) module_init(init); module_exit(fini); -EXPORT_SYMBOL(get_h245_addr); -EXPORT_SYMBOL(get_h225_addr); -EXPORT_SYMBOL(ip_conntrack_h245_expect); -EXPORT_SYMBOL(ip_conntrack_q931_expect); -EXPORT_SYMBOL(set_h245_addr_hook); -EXPORT_SYMBOL(set_h225_addr_hook); -EXPORT_SYMBOL(set_sig_addr_hook); -EXPORT_SYMBOL(set_ras_addr_hook); -EXPORT_SYMBOL(nat_rtp_rtcp_hook); -EXPORT_SYMBOL(nat_t120_hook); -EXPORT_SYMBOL(nat_h245_hook); -EXPORT_SYMBOL(nat_q931_hook); +EXPORT_SYMBOL_GPL(get_h225_addr); +EXPORT_SYMBOL_GPL(ip_conntrack_h245_expect); +EXPORT_SYMBOL_GPL(ip_conntrack_q931_expect); +EXPORT_SYMBOL_GPL(set_h245_addr_hook); +EXPORT_SYMBOL_GPL(set_h225_addr_hook); +EXPORT_SYMBOL_GPL(set_sig_addr_hook); +EXPORT_SYMBOL_GPL(set_ras_addr_hook); +EXPORT_SYMBOL_GPL(nat_rtp_rtcp_hook); +EXPORT_SYMBOL_GPL(nat_t120_hook); +EXPORT_SYMBOL_GPL(nat_h245_hook); +EXPORT_SYMBOL_GPL(nat_q931_hook); MODULE_AUTHOR("Jing Min Zhao "); MODULE_DESCRIPTION("H.323 connection tracking helper"); From kaber at trash.net Thu Apr 6 12:04:52 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:29 2006 Subject: [NETFILTER 00/12]: Netfilter Update Message-ID: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Hi Dave, following are a couple of netfilter fixes and enhancements: a couple of patches to fix the section mismatch warnings and clean up the netfilter hook registration, checksumming consolidation with better HW checksum error handling and some cleanup patches for the H.323 helper. The diffstat is a bit misleading, there is a lot of noise from the renaming of two large H.323 header files and a lot of reindentation of netfilter structures, its not as bad as it looks :) If you think its too large for -rc1 I can hold on to the checksumming patches, the others should go in as they actually fix stuff. Thanks. include/linux/netfilter.h | 42 include/linux/netfilter_ipv4.h | 2 include/linux/netfilter_ipv4/ip_conntrack_h323.h | 52 include/linux/netfilter_ipv4/ip_conntrack_helper_h323_asn1.h | 98 + include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h | 938 ++++++++++ include/linux/netfilter_ipv6.h | 3 net/ipv4/netfilter.c | 50 net/ipv4/netfilter/Kconfig | 1 net/ipv4/netfilter/arptable_filter.c | 19 net/ipv4/netfilter/ip_conntrack_helper_h323.c | 50 net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.c | 2 net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.h | 98 - net/ipv4/netfilter/ip_conntrack_helper_h323_types.h | 938 ---------- net/ipv4/netfilter/ip_conntrack_proto_icmp.c | 23 net/ipv4/netfilter/ip_conntrack_proto_tcp.c | 7 net/ipv4/netfilter/ip_conntrack_proto_udp.c | 7 net/ipv4/netfilter/ip_conntrack_standalone.c | 270 +- net/ipv4/netfilter/ip_nat_helper_h323.c | 58 net/ipv4/netfilter/ip_nat_standalone.c | 161 - net/ipv4/netfilter/ip_queue.c | 31 net/ipv4/netfilter/ipt_CLUSTERIP.c | 40 net/ipv4/netfilter/ipt_REJECT.c | 9 net/ipv4/netfilter/iptable_filter.c | 21 net/ipv4/netfilter/iptable_mangle.c | 33 net/ipv4/netfilter/iptable_raw.c | 35 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 227 -- net/ipv4/netfilter/nf_conntrack_proto_icmp.c | 20 net/ipv6/netfilter.c | 51 net/ipv6/netfilter/ip6_queue.c | 31 net/ipv6/netfilter/ip6table_filter.c | 21 net/ipv6/netfilter/ip6table_mangle.c | 33 net/ipv6/netfilter/ip6table_raw.c | 15 net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 181 - net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c | 12 net/netfilter/core.c | 51 net/netfilter/nf_conntrack_proto_tcp.c | 50 net/netfilter/nf_conntrack_proto_udp.c | 50 net/netfilter/nf_conntrack_standalone.c | 115 - net/netfilter/nf_queue.c | 49 net/netfilter/nfnetlink_log.c | 25 net/netfilter/nfnetlink_queue.c | 27 41 files changed, 1799 insertions(+), 2147 deletions(-) Jing Min Zhao: [NETFILTER]: H.323 helper: move some function prototypes to ip_conntrack_h323.h [NETFILTER]: H.323 helper: change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL [NETFILTER]: H.323 helper: make get_h245_addr() static [NETFILTER]: H.323 helper: add parameter 'default_rrq_ttl' [NETFILTER]: H.323 helper: update Changelog Patrick McHardy: [NETFILTER]: Add helper functions for mass hook registration/unregistration [NETFILTER]: Clean up hook registration [NETFILTER]: Fix section mismatch warnings [NETFILTER]: Fix IP_NF_CONNTRACK_NETLINK dependency [NETFILTER]: Introduce infrastructure for address family specific operations [NETFILTER]: Add address family specific checksum helpers [NETFILTER]: Convert conntrack/ipt_REJECT to new checksumming functions From kaber at trash.net Thu Apr 6 12:05:01 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:30 2006 Subject: [NETFILTER 06/12]: H.323 helper: make get_h245_addr() static In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100501.17409.55970.sendpatchset@localhost.localdomain> [NETFILTER]: H.323 helper: make get_h245_addr() static Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit a429b7ed024240e1334b78447e208f71959add62 tree d63e6e4658079356856f7b4bfd6a38529e39ac8e parent 3c1284349cc00613a738dbd582e6096236c4a44e author Jing Min Zhao Thu, 06 Apr 2006 11:42:04 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:42:04 +0200 net/ipv4/netfilter/ip_conntrack_helper_h323.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c index 83140d2..11c652f 100644 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c @@ -220,8 +220,8 @@ static int get_tpkt_data(struct sk_buff } /****************************************************************************/ -int get_h245_addr(unsigned char *data, H245_TransportAddress * addr, - u_int32_t * ip, u_int16_t * port) +static int get_h245_addr(unsigned char *data, H245_TransportAddress * addr, + u_int32_t * ip, u_int16_t * port) { unsigned char *p; From kaber at trash.net Thu Apr 6 12:05:04 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:32 2006 Subject: [NETFILTER 08/12]: H.323 helper: update Changelog In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100504.17409.80683.sendpatchset@localhost.localdomain> [NETFILTER]: H.323 helper: update Changelog Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit 4c164120eecc4d67e0eb6392bbb9f81351c18387 tree 9e710e2bce7e141f181daf1a61be3a989f57f653 parent 58e6febec3e259470b331d97cfe085242d2421c5 author Jing Min Zhao Thu, 06 Apr 2006 11:43:21 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:43:21 +0200 net/ipv4/netfilter/ip_conntrack_helper_h323.c | 15 +++++++++++++++ net/ipv4/netfilter/ip_nat_helper_h323.c | 5 +++++ 2 files changed, 20 insertions(+), 0 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c index dccc6c3..5221685 100644 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c @@ -40,6 +40,21 @@ * 4. Sort ASN.1 data to avoid forwarding declarations (suggested by * Patrick McHardy) * 5. Reset next TPKT data length in get_tpkt_data() + * + * 2006-03-20 - version 0.5 + * 1. Change gkrouted_only default to 1 (Patrick McHardy) + * 2. Remove #ifndef offsetof in ASN.1 parser (Patrick McHardy) + * 3. Initialize datalen to 0 in ras_help to silence an incorrect gcc + * warning (Patrick McHardy) + * + * 2006-03-22 - version 0.6 + * 1. get_h225_addr incorrectly defined as 'static' (found by + * Andrew Morton) + * + * 2006-03-25 - version 0.7 + * 1. Added new parameter 'default_rrq_ttl'. + * 2. Made get_h245_addr static (suggested by Adrian Bunk) + * 3. Changed to use EXPORT_SYMBOL_GPL (suggested by Adrian Bunk) */ #include diff --git a/net/ipv4/netfilter/ip_nat_helper_h323.c b/net/ipv4/netfilter/ip_nat_helper_h323.c index 6f19c20..c96f15f 100644 --- a/net/ipv4/netfilter/ip_nat_helper_h323.c +++ b/net/ipv4/netfilter/ip_nat_helper_h323.c @@ -25,6 +25,11 @@ * 2006-03-15 - version 0.4 * 1. Added support for T.120 channels * 2. Added parameter gkrouted_only (suggested by Patrick McHardy) + * + * 2006-03-25 - version 0.7 + * 1. Made get_h245_addr static (suggested by Adrian Bunk) + * 2. Move some extern function prototypes to ip_conntrack_h323.h + * (suggested by Adrian Bunk) */ #include From kaber at trash.net Thu Apr 6 12:05:05 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:34 2006 Subject: [NETFILTER 09/12]: Fix IP_NF_CONNTRACK_NETLINK dependency In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100505.17409.24939.sendpatchset@localhost.localdomain> [NETFILTER]: Fix IP_NF_CONNTRACK_NETLINK dependency When NAT is built as a module, ip_conntrack_netlink can not be linked statically. Signed-off-by: Patrick McHardy --- commit c9cb4249431b37ed45e69f20a5faa2735933feeb tree 7321ed9625f9163b6b8a3dd921510197c89681fe parent 4c164120eecc4d67e0eb6392bbb9f81351c18387 author Patrick McHardy Thu, 06 Apr 2006 11:43:35 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:43:35 +0200 net/ipv4/netfilter/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig index 77855cc..c60fd5c 100644 --- a/net/ipv4/netfilter/Kconfig +++ b/net/ipv4/netfilter/Kconfig @@ -69,6 +69,7 @@ config IP_NF_CONNTRACK_NETLINK tristate 'Connection tracking netlink interface (EXPERIMENTAL)' depends on EXPERIMENTAL && IP_NF_CONNTRACK && NETFILTER_NETLINK depends on IP_NF_CONNTRACK!=y || NETFILTER_NETLINK!=m + depends on IP_NF_NAT=n || IP_NF_NAT help This option enables support for a netlink-based userspace interface From kaber at trash.net Thu Apr 6 12:05:03 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:35 2006 Subject: [NETFILTER 07/12]: H.323 helper: add parameter 'default_rrq_ttl' In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100502.17409.1181.sendpatchset@localhost.localdomain> [NETFILTER]: H.323 helper: add parameter 'default_rrq_ttl' default_rrq_ttl is used when no TTL is included in the RRQ. Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit 58e6febec3e259470b331d97cfe085242d2421c5 tree a4d5bd9755e4cfbe35cadac9ade4246a857be278 parent a429b7ed024240e1334b78447e208f71959add62 author Jing Min Zhao Thu, 06 Apr 2006 11:43:00 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:43:00 +0200 net/ipv4/netfilter/ip_conntrack_helper_h323.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c index 11c652f..dccc6c3 100644 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c @@ -61,6 +61,10 @@ #endif /* Parameters */ +static unsigned int default_rrq_ttl = 300; +module_param(default_rrq_ttl, uint, 0600); +MODULE_PARM_DESC(default_rrq_ttl, "use this TTL if it's missing in RRQ"); + static int gkrouted_only = 1; module_param(gkrouted_only, int, 0600); MODULE_PARM_DESC(gkrouted_only, "only accept calls from gatekeeper"); @@ -1300,7 +1304,7 @@ static int process_rrq(struct sk_buff ** DEBUGP("ip_ct_ras: RRQ TTL = %u seconds\n", rrq->timeToLive); info->timeout = rrq->timeToLive; } else - info->timeout = 0; + info->timeout = default_rrq_ttl; return 0; } From kaber at trash.net Thu Apr 6 12:05:08 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:37 2006 Subject: [NETFILTER 11/12]: Add address family specific checksum helpers In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100508.17409.68682.sendpatchset@localhost.localdomain> [NETFILTER]: Add address family specific checksum helpers Add checksum operation which takes care of verifying the checksum and dealing with HW checksum errors and avoids multiple checksum operations by setting ip_summed to CHECKSUM_UNNECESSARY after successful verification. Signed-off-by: Patrick McHardy --- commit b204de98f3e9d2f9d47141c6a1036a2a27729329 tree baf5ff3876cccf6b875f2c5d794d6fe9becd17b3 parent 6a870bcf3e2ee0394ee23cb1ca32de2195edf86d author Patrick McHardy Thu, 06 Apr 2006 11:43:58 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:43:58 +0200 include/linux/netfilter.h | 17 +++++++++++++++++ include/linux/netfilter_ipv4.h | 2 ++ include/linux/netfilter_ipv6.h | 3 +++ net/ipv4/netfilter.c | 33 +++++++++++++++++++++++++++++++++ net/ipv6/netfilter.c | 34 ++++++++++++++++++++++++++++++++++ 5 files changed, 89 insertions(+), 0 deletions(-) diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h index 6ee168c..b31a9bc 100644 --- a/include/linux/netfilter.h +++ b/include/linux/netfilter.h @@ -285,6 +285,8 @@ extern int skb_make_writable(struct sk_b struct nf_afinfo { unsigned short family; + unsigned int (*checksum)(struct sk_buff *skb, unsigned int hook, + unsigned int dataoff, u_int8_t protocol); void (*saveroute)(const struct sk_buff *skb, struct nf_info *info); int (*reroute)(struct sk_buff **skb, @@ -298,6 +300,21 @@ static inline struct nf_afinfo *nf_get_a return rcu_dereference(nf_afinfo[family]); } +static inline unsigned int +nf_checksum(struct sk_buff *skb, unsigned int hook, unsigned int dataoff, + u_int8_t protocol, unsigned short family) +{ + struct nf_afinfo *afinfo; + unsigned int csum = 0; + + rcu_read_lock(); + afinfo = nf_get_afinfo(family); + if (afinfo) + csum = afinfo->checksum(skb, hook, dataoff, protocol); + rcu_read_unlock(); + return csum; +} + extern int nf_register_afinfo(struct nf_afinfo *afinfo); extern void nf_unregister_afinfo(struct nf_afinfo *afinfo); diff --git a/include/linux/netfilter_ipv4.h b/include/linux/netfilter_ipv4.h index 43c09d7..85301c5 100644 --- a/include/linux/netfilter_ipv4.h +++ b/include/linux/netfilter_ipv4.h @@ -80,6 +80,8 @@ enum nf_ip_hook_priorities { #ifdef __KERNEL__ extern int ip_route_me_harder(struct sk_buff **pskb); extern int ip_xfrm_me_harder(struct sk_buff **pskb); +extern unsigned int nf_ip_checksum(struct sk_buff *skb, unsigned int hook, + unsigned int dataoff, u_int8_t protocol); #endif /*__KERNEL__*/ #endif /*__LINUX_IP_NETFILTER_H*/ diff --git a/include/linux/netfilter_ipv6.h b/include/linux/netfilter_ipv6.h index 14f2bd0..52a7b9e 100644 --- a/include/linux/netfilter_ipv6.h +++ b/include/linux/netfilter_ipv6.h @@ -73,6 +73,9 @@ enum nf_ip6_hook_priorities { }; #ifdef CONFIG_NETFILTER +extern unsigned int nf_ip6_checksum(struct sk_buff *skb, unsigned int hook, + unsigned int dataoff, u_int8_t protocol); + extern int ipv6_netfilter_init(void); extern void ipv6_netfilter_fini(void); #else /* CONFIG_NETFILTER */ diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c index b25339c..6a9e34b 100644 --- a/net/ipv4/netfilter.c +++ b/net/ipv4/netfilter.c @@ -161,8 +161,41 @@ static int nf_ip_reroute(struct sk_buff return 0; } +unsigned int nf_ip_checksum(struct sk_buff *skb, unsigned int hook, + unsigned int dataoff, u_int8_t protocol) +{ + struct iphdr *iph = skb->nh.iph; + unsigned int csum = 0; + + switch (skb->ip_summed) { + case CHECKSUM_HW: + if (hook != NF_IP_PRE_ROUTING && hook != NF_IP_LOCAL_IN) + break; + if ((protocol == 0 && !(u16)csum_fold(skb->csum)) || + !csum_tcpudp_magic(iph->saddr, iph->daddr, + skb->len - dataoff, protocol, + skb->csum)) { + skb->ip_summed = CHECKSUM_UNNECESSARY; + break; + } + /* fall through */ + case CHECKSUM_NONE: + if (protocol == 0) + skb->csum = 0; + else + skb->csum = csum_tcpudp_nofold(iph->saddr, iph->daddr, + skb->len - dataoff, + protocol, 0); + csum = __skb_checksum_complete(skb); + } + return csum; +} + +EXPORT_SYMBOL(nf_ip_checksum); + static struct nf_afinfo nf_ip_afinfo = { .family = AF_INET, + .checksum = nf_ip_checksum, .saveroute = nf_ip_saveroute, .reroute = nf_ip_reroute, .route_key_size = sizeof(struct ip_rt_info), diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c index f514a01..3e9ecfa 100644 --- a/net/ipv6/netfilter.c +++ b/net/ipv6/netfilter.c @@ -79,8 +79,42 @@ static int nf_ip6_reroute(struct sk_buff return 0; } +unsigned int nf_ip6_checksum(struct sk_buff *skb, unsigned int hook, + unsigned int dataoff, u_int8_t protocol) +{ + struct ipv6hdr *ip6h = skb->nh.ipv6h; + unsigned int csum = 0; + + switch (skb->ip_summed) { + case CHECKSUM_HW: + if (hook != NF_IP6_PRE_ROUTING && hook != NF_IP6_LOCAL_IN) + break; + if (!csum_ipv6_magic(&ip6h->saddr, &ip6h->daddr, + skb->len - dataoff, protocol, + csum_sub(skb->csum, + skb_checksum(skb, 0, + dataoff, 0)))) { + skb->ip_summed = CHECKSUM_UNNECESSARY; + break; + } + /* fall through */ + case CHECKSUM_NONE: + skb->csum = ~csum_ipv6_magic(&ip6h->saddr, &ip6h->daddr, + skb->len - dataoff, + protocol, + csum_sub(0, + skb_checksum(skb, 0, + dataoff, 0))); + csum = __skb_checksum_complete(skb); + } + return csum; +} + +EXPORT_SYMBOL(nf_ip6_checksum); + static struct nf_afinfo nf_ip6_afinfo = { .family = AF_INET6, + .checksum = nf_ip6_checksum, .saveroute = nf_ip6_saveroute, .reroute = nf_ip6_reroute, .route_key_size = sizeof(struct ip6_rt_info), From kaber at trash.net Thu Apr 6 12:05:07 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:37 2006 Subject: [NETFILTER 10/12]: Introduce infrastructure for address family specific operations In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100506.17409.27277.sendpatchset@localhost.localdomain> [NETFILTER]: Introduce infrastructure for address family specific operations Change the queue rerouter intrastructure to a generic usable infrastructure for address family specific operations as a base for some cleanups. Signed-off-by: Patrick McHardy --- commit 6a870bcf3e2ee0394ee23cb1ca32de2195edf86d tree a5e7a46f323f8b9e24c52d546b9d7fcc69f8273c parent c9cb4249431b37ed45e69f20a5faa2735933feeb author Patrick McHardy Thu, 06 Apr 2006 11:43:48 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:43:48 +0200 include/linux/netfilter.h | 23 +++++++++++++++------ net/ipv4/netfilter.c | 17 ++++++++-------- net/ipv6/netfilter.c | 17 ++++++++-------- net/netfilter/core.c | 23 +++++++++++++++++++++ net/netfilter/nf_queue.c | 49 ++++++++++++--------------------------------- 5 files changed, 70 insertions(+), 59 deletions(-) diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h index 5aa9316..6ee168c 100644 --- a/include/linux/netfilter.h +++ b/include/linux/netfilter.h @@ -283,16 +283,25 @@ extern void nf_invalidate_cache(int pf); Returns true or false. */ extern int skb_make_writable(struct sk_buff **pskb, unsigned int writable_len); -struct nf_queue_rerouter { - void (*save)(const struct sk_buff *skb, struct nf_info *info); - int (*reroute)(struct sk_buff **skb, const struct nf_info *info); - int rer_size; +struct nf_afinfo { + unsigned short family; + void (*saveroute)(const struct sk_buff *skb, + struct nf_info *info); + int (*reroute)(struct sk_buff **skb, + const struct nf_info *info); + int route_key_size; }; -#define nf_info_reroute(x) ((void *)x + sizeof(struct nf_info)) +extern struct nf_afinfo *nf_afinfo[]; +static inline struct nf_afinfo *nf_get_afinfo(unsigned short family) +{ + return rcu_dereference(nf_afinfo[family]); +} -extern int nf_register_queue_rerouter(int pf, struct nf_queue_rerouter *rer); -extern int nf_unregister_queue_rerouter(int pf); +extern int nf_register_afinfo(struct nf_afinfo *afinfo); +extern void nf_unregister_afinfo(struct nf_afinfo *afinfo); + +#define nf_info_reroute(x) ((void *)x + sizeof(struct nf_info)) #include extern void (*ip_nat_decode_session)(struct sk_buff *, struct flowi *); diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c index b5ad9ac..b25339c 100644 --- a/net/ipv4/netfilter.c +++ b/net/ipv4/netfilter.c @@ -133,7 +133,7 @@ struct ip_rt_info { u_int8_t tos; }; -static void queue_save(const struct sk_buff *skb, struct nf_info *info) +static void nf_ip_saveroute(const struct sk_buff *skb, struct nf_info *info) { struct ip_rt_info *rt_info = nf_info_reroute(info); @@ -146,7 +146,7 @@ static void queue_save(const struct sk_b } } -static int queue_reroute(struct sk_buff **pskb, const struct nf_info *info) +static int nf_ip_reroute(struct sk_buff **pskb, const struct nf_info *info) { const struct ip_rt_info *rt_info = nf_info_reroute(info); @@ -161,20 +161,21 @@ static int queue_reroute(struct sk_buff return 0; } -static struct nf_queue_rerouter ip_reroute = { - .rer_size = sizeof(struct ip_rt_info), - .save = queue_save, - .reroute = queue_reroute, +static struct nf_afinfo nf_ip_afinfo = { + .family = AF_INET, + .saveroute = nf_ip_saveroute, + .reroute = nf_ip_reroute, + .route_key_size = sizeof(struct ip_rt_info), }; static int ipv4_netfilter_init(void) { - return nf_register_queue_rerouter(PF_INET, &ip_reroute); + return nf_register_afinfo(&nf_ip_afinfo); } static void ipv4_netfilter_fini(void) { - nf_unregister_queue_rerouter(PF_INET); + nf_unregister_afinfo(&nf_ip_afinfo); } module_init(ipv4_netfilter_init); diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c index d750cfc..f514a01 100644 --- a/net/ipv6/netfilter.c +++ b/net/ipv6/netfilter.c @@ -54,7 +54,7 @@ struct ip6_rt_info { struct in6_addr saddr; }; -static void save(const struct sk_buff *skb, struct nf_info *info) +static void nf_ip6_saveroute(const struct sk_buff *skb, struct nf_info *info) { struct ip6_rt_info *rt_info = nf_info_reroute(info); @@ -66,7 +66,7 @@ static void save(const struct sk_buff *s } } -static int reroute(struct sk_buff **pskb, const struct nf_info *info) +static int nf_ip6_reroute(struct sk_buff **pskb, const struct nf_info *info) { struct ip6_rt_info *rt_info = nf_info_reroute(info); @@ -79,15 +79,16 @@ static int reroute(struct sk_buff **pskb return 0; } -static struct nf_queue_rerouter ip6_reroute = { - .rer_size = sizeof(struct ip6_rt_info), - .save = &save, - .reroute = &reroute, +static struct nf_afinfo nf_ip6_afinfo = { + .family = AF_INET6, + .saveroute = nf_ip6_saveroute, + .reroute = nf_ip6_reroute, + .route_key_size = sizeof(struct ip6_rt_info), }; int __init ipv6_netfilter_init(void) { - return nf_register_queue_rerouter(PF_INET6, &ip6_reroute); + return nf_register_afinfo(&nf_ip6_afinfo); } /* This can be called from inet6_init() on errors, so it cannot @@ -95,5 +96,5 @@ int __init ipv6_netfilter_init(void) */ void ipv6_netfilter_fini(void) { - nf_unregister_queue_rerouter(PF_INET6); + nf_unregister_afinfo(&nf_ip6_afinfo); } diff --git a/net/netfilter/core.c b/net/netfilter/core.c index 5c7143e..dceed88 100644 --- a/net/netfilter/core.c +++ b/net/netfilter/core.c @@ -27,6 +27,29 @@ #include "nf_internals.h" +static DEFINE_SPINLOCK(afinfo_lock); + +struct nf_afinfo *nf_afinfo[NPROTO]; +EXPORT_SYMBOL(nf_afinfo); + +int nf_register_afinfo(struct nf_afinfo *afinfo) +{ + spin_lock(&afinfo_lock); + rcu_assign_pointer(nf_afinfo[afinfo->family], afinfo); + spin_unlock(&afinfo_lock); + return 0; +} +EXPORT_SYMBOL_GPL(nf_register_afinfo); + +void nf_unregister_afinfo(struct nf_afinfo *afinfo) +{ + spin_lock(&afinfo_lock); + rcu_assign_pointer(nf_afinfo[afinfo->family], NULL); + spin_unlock(&afinfo_lock); + synchronize_rcu(); +} +EXPORT_SYMBOL_GPL(nf_unregister_afinfo); + /* In this code, we can be waiting indefinitely for userspace to * service a packet if a hook returns NF_QUEUE. We could keep a count * of skbuffs queued for userspace, and not deregister a hook unless diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c index d9f0d7e..ee8f708 100644 --- a/net/netfilter/nf_queue.c +++ b/net/netfilter/nf_queue.c @@ -17,7 +17,6 @@ * for queueing and must reinject all packets it receives, no matter what. */ static struct nf_queue_handler *queue_handler[NPROTO]; -static struct nf_queue_rerouter *queue_rerouter[NPROTO]; static DEFINE_RWLOCK(queue_handler_lock); @@ -59,32 +58,6 @@ int nf_unregister_queue_handler(int pf) } EXPORT_SYMBOL(nf_unregister_queue_handler); -int nf_register_queue_rerouter(int pf, struct nf_queue_rerouter *rer) -{ - if (pf >= NPROTO) - return -EINVAL; - - write_lock_bh(&queue_handler_lock); - rcu_assign_pointer(queue_rerouter[pf], rer); - write_unlock_bh(&queue_handler_lock); - - return 0; -} -EXPORT_SYMBOL_GPL(nf_register_queue_rerouter); - -int nf_unregister_queue_rerouter(int pf) -{ - if (pf >= NPROTO) - return -EINVAL; - - write_lock_bh(&queue_handler_lock); - rcu_assign_pointer(queue_rerouter[pf], NULL); - write_unlock_bh(&queue_handler_lock); - synchronize_rcu(); - return 0; -} -EXPORT_SYMBOL_GPL(nf_unregister_queue_rerouter); - void nf_unregister_queue_handlers(struct nf_queue_handler *qh) { int pf; @@ -116,7 +89,7 @@ int nf_queue(struct sk_buff **skb, struct net_device *physindev = NULL; struct net_device *physoutdev = NULL; #endif - struct nf_queue_rerouter *rerouter; + struct nf_afinfo *afinfo; /* QUEUE == DROP if noone is waiting, to be safe. */ read_lock(&queue_handler_lock); @@ -126,7 +99,14 @@ int nf_queue(struct sk_buff **skb, return 1; } - info = kmalloc(sizeof(*info)+queue_rerouter[pf]->rer_size, GFP_ATOMIC); + afinfo = nf_get_afinfo(pf); + if (!afinfo) { + read_unlock(&queue_handler_lock); + kfree_skb(*skb); + return 1; + } + + info = kmalloc(sizeof(*info) + afinfo->route_key_size, GFP_ATOMIC); if (!info) { if (net_ratelimit()) printk(KERN_ERR "OOM queueing packet %p\n", @@ -158,10 +138,7 @@ int nf_queue(struct sk_buff **skb, if (physoutdev) dev_hold(physoutdev); } #endif - rerouter = rcu_dereference(queue_rerouter[pf]); - if (rerouter) - rerouter->save(*skb, info); - + afinfo->saveroute(*skb, info); status = queue_handler[pf]->outfn(*skb, info, queuenum, queue_handler[pf]->data); @@ -190,7 +167,7 @@ void nf_reinject(struct sk_buff *skb, st { struct list_head *elem = &info->elem->list; struct list_head *i; - struct nf_queue_rerouter *rerouter; + struct nf_afinfo *afinfo; rcu_read_lock(); @@ -228,8 +205,8 @@ void nf_reinject(struct sk_buff *skb, st } if (verdict == NF_ACCEPT) { - rerouter = rcu_dereference(queue_rerouter[info->pf]); - if (rerouter && rerouter->reroute(&skb, info) < 0) + afinfo = nf_get_afinfo(info->pf); + if (!afinfo || afinfo->reroute(&skb, info) < 0) verdict = NF_DROP; } From kaber at trash.net Thu Apr 6 12:05:09 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:38 2006 Subject: [NETFILTER 12/12]: Convert conntrack/ipt_REJECT to new checksumming functions In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100509.17409.82693.sendpatchset@localhost.localdomain> [NETFILTER]: Convert conntrack/ipt_REJECT to new checksumming functions Besides removing lots of duplicate code, all converted users benefit from improved HW checksum error handling. Tested with and without HW checksums in almost all combinations. Signed-off-by: Patrick McHardy --- commit 841bf618050f12d9230c6fee4186c632b3bf786a tree 6af5e18f6f57ee30e011a59d689df94008775660 parent b204de98f3e9d2f9d47141c6a1036a2a27729329 author Patrick McHardy Thu, 06 Apr 2006 11:44:05 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:44:05 +0200 net/ipv4/netfilter/ip_conntrack_proto_icmp.c | 23 +++-------- net/ipv4/netfilter/ip_conntrack_proto_tcp.c | 7 +-- net/ipv4/netfilter/ip_conntrack_proto_udp.c | 7 +-- net/ipv4/netfilter/ipt_REJECT.c | 9 ---- net/ipv4/netfilter/nf_conntrack_proto_icmp.c | 20 +--------- net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c | 12 +----- net/netfilter/nf_conntrack_proto_tcp.c | 50 ++---------------------- net/netfilter/nf_conntrack_proto_udp.c | 50 ++---------------------- 8 files changed, 25 insertions(+), 153 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c index 3021af0..d8b14a9 100644 --- a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c +++ b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c @@ -224,25 +224,14 @@ icmp_error(struct sk_buff *skb, enum ip_ } /* See ip_conntrack_proto_tcp.c */ - if (hooknum != NF_IP_PRE_ROUTING) - goto checksum_skipped; - - switch (skb->ip_summed) { - case CHECKSUM_HW: - if (!(u16)csum_fold(skb->csum)) - break; - /* fall through */ - case CHECKSUM_NONE: - skb->csum = 0; - if (__skb_checksum_complete(skb)) { - if (LOG_INVALID(IPPROTO_ICMP)) - nf_log_packet(PF_INET, 0, skb, NULL, NULL, NULL, - "ip_ct_icmp: bad ICMP checksum "); - return -NF_ACCEPT; - } + if (hooknum == NF_IP_PRE_ROUTING && + nf_ip_checksum(skb, hooknum, skb->nh.iph->ihl * 4, 0)) { + if (LOG_INVALID(IPPROTO_ICMP)) + nf_log_packet(PF_INET, 0, skb, NULL, NULL, NULL, + "ip_ct_icmp: bad ICMP checksum "); + return -NF_ACCEPT; } -checksum_skipped: /* * 18 is the highest 'known' ICMP type. Anything else is a mystery * diff --git a/net/ipv4/netfilter/ip_conntrack_proto_tcp.c b/net/ipv4/netfilter/ip_conntrack_proto_tcp.c index e0dc370..062b252 100644 --- a/net/ipv4/netfilter/ip_conntrack_proto_tcp.c +++ b/net/ipv4/netfilter/ip_conntrack_proto_tcp.c @@ -870,11 +870,8 @@ static int tcp_error(struct sk_buff *skb * and moreover root might send raw packets. */ /* FIXME: Source route IP option packets --RR */ - if (hooknum == NF_IP_PRE_ROUTING - && skb->ip_summed != CHECKSUM_UNNECESSARY - && csum_tcpudp_magic(iph->saddr, iph->daddr, tcplen, IPPROTO_TCP, - skb->ip_summed == CHECKSUM_HW ? skb->csum - : skb_checksum(skb, iph->ihl*4, tcplen, 0))) { + if (hooknum == NF_IP_PRE_ROUTING && + nf_ip_checksum(skb, hooknum, iph->ihl * 4, IPPROTO_TCP)) { if (LOG_INVALID(IPPROTO_TCP)) nf_log_packet(PF_INET, 0, skb, NULL, NULL, NULL, "ip_ct_tcp: bad TCP checksum "); diff --git a/net/ipv4/netfilter/ip_conntrack_proto_udp.c b/net/ipv4/netfilter/ip_conntrack_proto_udp.c index 55b7d32..7089986 100644 --- a/net/ipv4/netfilter/ip_conntrack_proto_udp.c +++ b/net/ipv4/netfilter/ip_conntrack_proto_udp.c @@ -120,11 +120,8 @@ static int udp_error(struct sk_buff *skb * because the semantic of CHECKSUM_HW is different there * and moreover root might send raw packets. * FIXME: Source route IP option packets --RR */ - if (hooknum == NF_IP_PRE_ROUTING - && skb->ip_summed != CHECKSUM_UNNECESSARY - && csum_tcpudp_magic(iph->saddr, iph->daddr, udplen, IPPROTO_UDP, - skb->ip_summed == CHECKSUM_HW ? skb->csum - : skb_checksum(skb, iph->ihl*4, udplen, 0))) { + if (hooknum == NF_IP_PRE_ROUTING && + nf_ip_checksum(skb, hooknum, iph->ihl * 4, IPPROTO_UDP)) { if (LOG_INVALID(IPPROTO_UDP)) nf_log_packet(PF_INET, 0, skb, NULL, NULL, NULL, "ip_ct_udp: bad UDP checksum "); diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c index 4269a54..0bba3c2 100644 --- a/net/ipv4/netfilter/ipt_REJECT.c +++ b/net/ipv4/netfilter/ipt_REJECT.c @@ -106,7 +106,6 @@ static void send_reset(struct sk_buff *o struct rtable *rt; u_int16_t tmp_port; u_int32_t tmp_addr; - unsigned int tcplen; int needs_ack; int hh_len; @@ -124,13 +123,7 @@ static void send_reset(struct sk_buff *o return; /* Check checksum */ - tcplen = oldskb->len - iph->ihl * 4; - if (((hook != NF_IP_LOCAL_IN && oldskb->ip_summed != CHECKSUM_HW) || - (hook == NF_IP_LOCAL_IN && - oldskb->ip_summed != CHECKSUM_UNNECESSARY)) && - csum_tcpudp_magic(iph->saddr, iph->daddr, tcplen, IPPROTO_TCP, - oldskb->ip_summed == CHECKSUM_HW ? oldskb->csum : - skb_checksum(oldskb, iph->ihl * 4, tcplen, 0))) + if (nf_ip_checksum(oldskb, hook, iph->ihl * 4, IPPROTO_TCP)) return; if ((rt = route_reverse(oldskb, oth, hook)) == NULL) diff --git a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c index 52dc175..4b0d361 100644 --- a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c +++ b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c @@ -235,30 +235,14 @@ icmp_error(struct sk_buff *skb, unsigned } /* See ip_conntrack_proto_tcp.c */ - if (hooknum != NF_IP_PRE_ROUTING) - goto checksum_skipped; - - switch (skb->ip_summed) { - case CHECKSUM_HW: - if (!(u16)csum_fold(skb->csum)) - break; + if (hooknum == NF_IP_PRE_ROUTING && + nf_ip_checksum(skb, hooknum, dataoff, 0)) { if (LOG_INVALID(IPPROTO_ICMP)) nf_log_packet(PF_INET, 0, skb, NULL, NULL, NULL, "nf_ct_icmp: bad HW ICMP checksum "); return -NF_ACCEPT; - case CHECKSUM_NONE: - if ((u16)csum_fold(skb_checksum(skb, 0, skb->len, 0))) { - if (LOG_INVALID(IPPROTO_ICMP)) - nf_log_packet(PF_INET, 0, skb, NULL, NULL, - NULL, - "nf_ct_icmp: bad ICMP checksum "); - return -NF_ACCEPT; - } - default: - break; } -checksum_skipped: /* * 18 is the highest 'known' ICMP type. Anything else is a mystery * diff --git a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c index 09945c3..86c6703 100644 --- a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c +++ b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c @@ -233,21 +233,13 @@ icmpv6_error(struct sk_buff *skb, unsign return -NF_ACCEPT; } - if (hooknum != NF_IP6_PRE_ROUTING) - goto skipped; - - /* Ignore it if the checksum's bogus. */ - if (csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr, - skb->len - dataoff, IPPROTO_ICMPV6, - skb_checksum(skb, dataoff, - skb->len - dataoff, 0))) { + if (hooknum == NF_IP6_PRE_ROUTING && + nf_ip6_checksum(skb, hooknum, dataoff, IPPROTO_ICMPV6)) { nf_log_packet(PF_INET6, 0, skb, NULL, NULL, NULL, "nf_ct_icmpv6: ICMPv6 checksum failed\n"); return -NF_ACCEPT; } -skipped: - /* is not error message ? */ if (icmp6h->icmp6_type >= 128) return NF_ACCEPT; diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c index 6492ed6..69899f2 100644 --- a/net/netfilter/nf_conntrack_proto_tcp.c +++ b/net/netfilter/nf_conntrack_proto_tcp.c @@ -799,8 +799,7 @@ static int tcp_error(struct sk_buff *skb unsigned int dataoff, enum ip_conntrack_info *ctinfo, int pf, - unsigned int hooknum, - int(*csum)(const struct sk_buff *,unsigned int)) + unsigned int hooknum) { struct tcphdr _tcph, *th; unsigned int tcplen = skb->len - dataoff; @@ -830,9 +829,8 @@ static int tcp_error(struct sk_buff *skb */ /* FIXME: Source route IP option packets --RR */ if (((pf == PF_INET && hooknum == NF_IP_PRE_ROUTING) || - (pf == PF_INET6 && hooknum == NF_IP6_PRE_ROUTING)) - && skb->ip_summed != CHECKSUM_UNNECESSARY - && csum(skb, dataoff)) { + (pf == PF_INET6 && hooknum == NF_IP6_PRE_ROUTING)) && + nf_checksum(skb, hooknum, dataoff, IPPROTO_TCP, pf)) { if (LOG_INVALID(IPPROTO_TCP)) nf_log_packet(pf, 0, skb, NULL, NULL, NULL, "nf_ct_tcp: bad TCP checksum "); @@ -851,44 +849,6 @@ static int tcp_error(struct sk_buff *skb return NF_ACCEPT; } -static int csum4(const struct sk_buff *skb, unsigned int dataoff) -{ - return csum_tcpudp_magic(skb->nh.iph->saddr, skb->nh.iph->daddr, - skb->len - dataoff, IPPROTO_TCP, - skb->ip_summed == CHECKSUM_HW ? skb->csum - : skb_checksum(skb, dataoff, - skb->len - dataoff, 0)); -} - -static int csum6(const struct sk_buff *skb, unsigned int dataoff) -{ - return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr, - skb->len - dataoff, IPPROTO_TCP, - skb->ip_summed == CHECKSUM_HW - ? csum_sub(skb->csum, - skb_checksum(skb, 0, dataoff, 0)) - : skb_checksum(skb, dataoff, skb->len - dataoff, - 0)); -} - -static int tcp_error4(struct sk_buff *skb, - unsigned int dataoff, - enum ip_conntrack_info *ctinfo, - int pf, - unsigned int hooknum) -{ - return tcp_error(skb, dataoff, ctinfo, pf, hooknum, csum4); -} - -static int tcp_error6(struct sk_buff *skb, - unsigned int dataoff, - enum ip_conntrack_info *ctinfo, - int pf, - unsigned int hooknum) -{ - return tcp_error(skb, dataoff, ctinfo, pf, hooknum, csum6); -} - /* Returns verdict for packet, or -1 for invalid. */ static int tcp_packet(struct nf_conn *conntrack, const struct sk_buff *skb, @@ -1218,7 +1178,7 @@ struct nf_conntrack_protocol nf_conntrac .print_conntrack = tcp_print_conntrack, .packet = tcp_packet, .new = tcp_new, - .error = tcp_error4, + .error = tcp_error, #if defined(CONFIG_NF_CT_NETLINK) || \ defined(CONFIG_NF_CT_NETLINK_MODULE) .to_nfattr = tcp_to_nfattr, @@ -1239,7 +1199,7 @@ struct nf_conntrack_protocol nf_conntrac .print_conntrack = tcp_print_conntrack, .packet = tcp_packet, .new = tcp_new, - .error = tcp_error6, + .error = tcp_error, #if defined(CONFIG_NF_CT_NETLINK) || \ defined(CONFIG_NF_CT_NETLINK_MODULE) .to_nfattr = tcp_to_nfattr, diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c index 831d206..d93edbf 100644 --- a/net/netfilter/nf_conntrack_proto_udp.c +++ b/net/netfilter/nf_conntrack_proto_udp.c @@ -103,8 +103,7 @@ static int udp_new(struct nf_conn *connt static int udp_error(struct sk_buff *skb, unsigned int dataoff, enum ip_conntrack_info *ctinfo, int pf, - unsigned int hooknum, - int (*csum)(const struct sk_buff *, unsigned int)) + unsigned int hooknum) { unsigned int udplen = skb->len - dataoff; struct udphdr _hdr, *hdr; @@ -136,9 +135,8 @@ static int udp_error(struct sk_buff *skb * and moreover root might send raw packets. * FIXME: Source route IP option packets --RR */ if (((pf == PF_INET && hooknum == NF_IP_PRE_ROUTING) || - (pf == PF_INET6 && hooknum == NF_IP6_PRE_ROUTING)) - && skb->ip_summed != CHECKSUM_UNNECESSARY - && csum(skb, dataoff)) { + (pf == PF_INET6 && hooknum == NF_IP6_PRE_ROUTING)) && + nf_checksum(skb, hooknum, dataoff, IPPROTO_UDP, pf)) { if (LOG_INVALID(IPPROTO_UDP)) nf_log_packet(pf, 0, skb, NULL, NULL, NULL, "nf_ct_udp: bad UDP checksum "); @@ -148,44 +146,6 @@ static int udp_error(struct sk_buff *skb return NF_ACCEPT; } -static int csum4(const struct sk_buff *skb, unsigned int dataoff) -{ - return csum_tcpudp_magic(skb->nh.iph->saddr, skb->nh.iph->daddr, - skb->len - dataoff, IPPROTO_UDP, - skb->ip_summed == CHECKSUM_HW ? skb->csum - : skb_checksum(skb, dataoff, - skb->len - dataoff, 0)); -} - -static int csum6(const struct sk_buff *skb, unsigned int dataoff) -{ - return csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr, - skb->len - dataoff, IPPROTO_UDP, - skb->ip_summed == CHECKSUM_HW - ? csum_sub(skb->csum, - skb_checksum(skb, 0, dataoff, 0)) - : skb_checksum(skb, dataoff, skb->len - dataoff, - 0)); -} - -static int udp_error4(struct sk_buff *skb, - unsigned int dataoff, - enum ip_conntrack_info *ctinfo, - int pf, - unsigned int hooknum) -{ - return udp_error(skb, dataoff, ctinfo, pf, hooknum, csum4); -} - -static int udp_error6(struct sk_buff *skb, - unsigned int dataoff, - enum ip_conntrack_info *ctinfo, - int pf, - unsigned int hooknum) -{ - return udp_error(skb, dataoff, ctinfo, pf, hooknum, csum6); -} - struct nf_conntrack_protocol nf_conntrack_protocol_udp4 = { .l3proto = PF_INET, @@ -197,7 +157,7 @@ struct nf_conntrack_protocol nf_conntrac .print_conntrack = udp_print_conntrack, .packet = udp_packet, .new = udp_new, - .error = udp_error4, + .error = udp_error, #if defined(CONFIG_NF_CT_NETLINK) || \ defined(CONFIG_NF_CT_NETLINK_MODULE) .tuple_to_nfattr = nf_ct_port_tuple_to_nfattr, @@ -216,7 +176,7 @@ struct nf_conntrack_protocol nf_conntrac .print_conntrack = udp_print_conntrack, .packet = udp_packet, .new = udp_new, - .error = udp_error6, + .error = udp_error, #if defined(CONFIG_NF_CT_NETLINK) || \ defined(CONFIG_NF_CT_NETLINK_MODULE) .tuple_to_nfattr = nf_ct_port_tuple_to_nfattr, From kaber at trash.net Thu Apr 6 12:04:58 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:21:42 2006 Subject: [NETFILTER 04/12]: H.323 helper: move some function prototypes to ip_conntrack_h323.h In-Reply-To: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> Message-ID: <20060406100458.17409.70510.sendpatchset@localhost.localdomain> [NETFILTER]: H.323 helper: move some function prototypes to ip_conntrack_h323.h Move prototypes of NAT callbacks to ip_conntrack_h323.h. Because the use of typedefs as arguments, some header files need to be moved as well. Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit 02fe897a46c3da14bab9fafeaa99692da6ae7fc1 tree 962f387c169fb4fbb96ab7f78cabfcde4258b810 parent 7e7dcfedeec88f2da01af1261c4ecc5a27a9686f author Jing Min Zhao Thu, 06 Apr 2006 11:40:43 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:40:43 +0200 include/linux/netfilter_ipv4/ip_conntrack_h323.h | 52 + .../netfilter_ipv4/ip_conntrack_helper_h323_asn1.h | 98 ++ .../ip_conntrack_helper_h323_types.h | 938 +++++++++++++++++++++++ net/ipv4/netfilter/ip_conntrack_helper_h323.c | 2 net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.c | 2 net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.h | 98 -- .../netfilter/ip_conntrack_helper_h323_types.h | 938 ----------------------- net/ipv4/netfilter/ip_nat_helper_h323.c | 53 - 8 files changed, 1089 insertions(+), 1092 deletions(-) diff --git a/include/linux/netfilter_ipv4/ip_conntrack_h323.h b/include/linux/netfilter_ipv4/ip_conntrack_h323.h index 0987cea..eace86b 100644 --- a/include/linux/netfilter_ipv4/ip_conntrack_h323.h +++ b/include/linux/netfilter_ipv4/ip_conntrack_h323.h @@ -3,6 +3,8 @@ #ifdef __KERNEL__ +#include + #define RAS_PORT 1719 #define Q931_PORT 1720 #define H323_RTP_CHANNEL_MAX 4 /* Audio, video, FAX and other */ @@ -25,6 +27,56 @@ struct ip_ct_h323_master { }; }; +struct ip_conntrack_expect; + +extern int get_h225_addr(unsigned char *data, TransportAddress * addr, + u_int32_t * ip, u_int16_t * port); +extern void ip_conntrack_h245_expect(struct ip_conntrack *new, + struct ip_conntrack_expect *this); +extern void ip_conntrack_q931_expect(struct ip_conntrack *new, + struct ip_conntrack_expect *this); +extern int (*set_h245_addr_hook) (struct sk_buff ** pskb, + unsigned char **data, int dataoff, + H245_TransportAddress * addr, + u_int32_t ip, u_int16_t port); +extern int (*set_h225_addr_hook) (struct sk_buff ** pskb, + unsigned char **data, int dataoff, + TransportAddress * addr, + u_int32_t ip, u_int16_t port); +extern int (*set_sig_addr_hook) (struct sk_buff ** pskb, + struct ip_conntrack * ct, + enum ip_conntrack_info ctinfo, + unsigned char **data, + TransportAddress * addr, int count); +extern int (*set_ras_addr_hook) (struct sk_buff ** pskb, + struct ip_conntrack * ct, + enum ip_conntrack_info ctinfo, + unsigned char **data, + TransportAddress * addr, int count); +extern int (*nat_rtp_rtcp_hook) (struct sk_buff ** pskb, + struct ip_conntrack * ct, + enum ip_conntrack_info ctinfo, + unsigned char **data, int dataoff, + H245_TransportAddress * addr, + u_int16_t port, u_int16_t rtp_port, + struct ip_conntrack_expect * rtp_exp, + struct ip_conntrack_expect * rtcp_exp); +extern int (*nat_t120_hook) (struct sk_buff ** pskb, struct ip_conntrack * ct, + enum ip_conntrack_info ctinfo, + unsigned char **data, int dataoff, + H245_TransportAddress * addr, u_int16_t port, + struct ip_conntrack_expect * exp); +extern int (*nat_h245_hook) (struct sk_buff ** pskb, struct ip_conntrack * ct, + enum ip_conntrack_info ctinfo, + unsigned char **data, int dataoff, + TransportAddress * addr, u_int16_t port, + struct ip_conntrack_expect * exp); +extern int (*nat_q931_hook) (struct sk_buff ** pskb, struct ip_conntrack * ct, + enum ip_conntrack_info ctinfo, + unsigned char **data, TransportAddress * addr, + int idx, u_int16_t port, + struct ip_conntrack_expect * exp); + #endif #endif diff --git a/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_asn1.h b/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_asn1.h new file mode 100644 index 0000000..2556b84 --- /dev/null +++ b/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_asn1.h @@ -0,0 +1,98 @@ +/**************************************************************************** + * ip_conntrack_helper_h323_asn1.h - BER and PER decoding library for H.323 + * conntrack/NAT module. + * + * Copyright (c) 2006 by Jing Min Zhao + * + * This source code is licensed under General Public License version 2. + * + * + * This library is based on H.225 version 4, H.235 version 2 and H.245 + * version 7. It is extremely optimized to decode only the absolutely + * necessary objects in a signal for Linux kernel NAT module use, so don't + * expect it to be a full ASN.1 library. + * + * Features: + * + * 1. Small. The total size of code plus data is less than 20 KB (IA32). + * 2. Fast. Decoding Netmeeting's Setup signal 1 million times on a PIII 866 + * takes only 3.9 seconds. + * 3. No memory allocation. It uses a static object. No need to initialize or + * cleanup. + * 4. Thread safe. + * 5. Support embedded architectures that has no misaligned memory access + * support. + * + * Limitations: + * + * 1. At most 30 faststart entries. Actually this is limited by ethernet's MTU. + * If a Setup signal contains more than 30 faststart, the packet size will + * very likely exceed the MTU size, then the TPKT will be fragmented. I + * don't know how to handle this in a Netfilter module. Anybody can help? + * Although I think 30 is enough for most of the cases. + * 2. IPv4 addresses only. + * + ****************************************************************************/ + +#ifndef _IP_CONNTRACK_HELPER_H323_ASN1_H_ +#define _IP_CONNTRACK_HELPER_H323_ASN1_H_ + +/***************************************************************************** + * H.323 Types + ****************************************************************************/ +#include "ip_conntrack_helper_h323_types.h" + +typedef struct { + enum { + Q931_NationalEscape = 0x00, + Q931_Alerting = 0x01, + Q931_CallProceeding = 0x02, + Q931_Connect = 0x07, + Q931_ConnectAck = 0x0F, + Q931_Progress = 0x03, + Q931_Setup = 0x05, + Q931_SetupAck = 0x0D, + Q931_Resume = 0x26, + Q931_ResumeAck = 0x2E, + Q931_ResumeReject = 0x22, + Q931_Suspend = 0x25, + Q931_SuspendAck = 0x2D, + Q931_SuspendReject = 0x21, + Q931_UserInformation = 0x20, + Q931_Disconnect = 0x45, + Q931_Release = 0x4D, + Q931_ReleaseComplete = 0x5A, + Q931_Restart = 0x46, + Q931_RestartAck = 0x4E, + Q931_Segment = 0x60, + Q931_CongestionCtrl = 0x79, + Q931_Information = 0x7B, + Q931_Notify = 0x6E, + Q931_Status = 0x7D, + Q931_StatusEnquiry = 0x75, + Q931_Facility = 0x62 + } MessageType; + H323_UserInformation UUIE; +} Q931; + +/***************************************************************************** + * Decode Functions Return Codes + ****************************************************************************/ + +#define H323_ERROR_NONE 0 /* Decoded successfully */ +#define H323_ERROR_STOP 1 /* Decoding stopped, not really an error */ +#define H323_ERROR_BOUND -1 +#define H323_ERROR_RANGE -2 + + +/***************************************************************************** + * Decode Functions + ****************************************************************************/ + +int DecodeRasMessage(unsigned char *buf, size_t sz, RasMessage * ras); +int DecodeQ931(unsigned char *buf, size_t sz, Q931 * q931); +int DecodeMultimediaSystemControlMessage(unsigned char *buf, size_t sz, + MultimediaSystemControlMessage * + mscm); + +#endif diff --git a/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h b/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h new file mode 100644 index 0000000..cc98f7a --- /dev/null +++ b/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h @@ -0,0 +1,938 @@ +/* Generated by Jing Min Zhao's ASN.1 parser, Mar 15 2006 + * + * Copyright (c) 2006 Jing Min Zhao + * + * This source code is licensed under General Public License version 2. + */ + +typedef struct TransportAddress_ipAddress { /* SEQUENCE */ + int options; /* No use */ + unsigned ip; +} TransportAddress_ipAddress; + +typedef struct TransportAddress { /* CHOICE */ + enum { + eTransportAddress_ipAddress, + eTransportAddress_ipSourceRoute, + eTransportAddress_ipxAddress, + eTransportAddress_ip6Address, + eTransportAddress_netBios, + eTransportAddress_nsap, + eTransportAddress_nonStandardAddress, + } choice; + union { + TransportAddress_ipAddress ipAddress; + }; +} TransportAddress; + +typedef struct DataProtocolCapability { /* CHOICE */ + enum { + eDataProtocolCapability_nonStandard, + eDataProtocolCapability_v14buffered, + eDataProtocolCapability_v42lapm, + eDataProtocolCapability_hdlcFrameTunnelling, + eDataProtocolCapability_h310SeparateVCStack, + eDataProtocolCapability_h310SingleVCStack, + eDataProtocolCapability_transparent, + eDataProtocolCapability_segmentationAndReassembly, + eDataProtocolCapability_hdlcFrameTunnelingwSAR, + eDataProtocolCapability_v120, + eDataProtocolCapability_separateLANStack, + eDataProtocolCapability_v76wCompression, + eDataProtocolCapability_tcp, + eDataProtocolCapability_udp, + } choice; +} DataProtocolCapability; + +typedef struct DataApplicationCapability_application { /* CHOICE */ + enum { + eDataApplicationCapability_application_nonStandard, + eDataApplicationCapability_application_t120, + eDataApplicationCapability_application_dsm_cc, + eDataApplicationCapability_application_userData, + eDataApplicationCapability_application_t84, + eDataApplicationCapability_application_t434, + eDataApplicationCapability_application_h224, + eDataApplicationCapability_application_nlpid, + eDataApplicationCapability_application_dsvdControl, + eDataApplicationCapability_application_h222DataPartitioning, + eDataApplicationCapability_application_t30fax, + eDataApplicationCapability_application_t140, + eDataApplicationCapability_application_t38fax, + eDataApplicationCapability_application_genericDataCapability, + } choice; + union { + DataProtocolCapability t120; + }; +} DataApplicationCapability_application; + +typedef struct DataApplicationCapability { /* SEQUENCE */ + int options; /* No use */ + DataApplicationCapability_application application; +} DataApplicationCapability; + +typedef struct DataType { /* CHOICE */ + enum { + eDataType_nonStandard, + eDataType_nullData, + eDataType_videoData, + eDataType_audioData, + eDataType_data, + eDataType_encryptionData, + eDataType_h235Control, + eDataType_h235Media, + eDataType_multiplexedStream, + } choice; + union { + DataApplicationCapability data; + }; +} DataType; + +typedef struct UnicastAddress_iPAddress { /* SEQUENCE */ + int options; /* No use */ + unsigned network; +} UnicastAddress_iPAddress; + +typedef struct UnicastAddress { /* CHOICE */ + enum { + eUnicastAddress_iPAddress, + eUnicastAddress_iPXAddress, + eUnicastAddress_iP6Address, + eUnicastAddress_netBios, + eUnicastAddress_iPSourceRouteAddress, + eUnicastAddress_nsap, + eUnicastAddress_nonStandardAddress, + } choice; + union { + UnicastAddress_iPAddress iPAddress; + }; +} UnicastAddress; + +typedef struct H245_TransportAddress { /* CHOICE */ + enum { + eH245_TransportAddress_unicastAddress, + eH245_TransportAddress_multicastAddress, + } choice; + union { + UnicastAddress unicastAddress; + }; +} H245_TransportAddress; + +typedef struct H2250LogicalChannelParameters { /* SEQUENCE */ + enum { + eH2250LogicalChannelParameters_nonStandard = (1 << 31), + eH2250LogicalChannelParameters_associatedSessionID = + (1 << 30), + eH2250LogicalChannelParameters_mediaChannel = (1 << 29), + eH2250LogicalChannelParameters_mediaGuaranteedDelivery = + (1 << 28), + eH2250LogicalChannelParameters_mediaControlChannel = + (1 << 27), + eH2250LogicalChannelParameters_mediaControlGuaranteedDelivery + = (1 << 26), + eH2250LogicalChannelParameters_silenceSuppression = (1 << 25), + eH2250LogicalChannelParameters_destination = (1 << 24), + eH2250LogicalChannelParameters_dynamicRTPPayloadType = + (1 << 23), + eH2250LogicalChannelParameters_mediaPacketization = (1 << 22), + eH2250LogicalChannelParameters_transportCapability = + (1 << 21), + eH2250LogicalChannelParameters_redundancyEncoding = (1 << 20), + eH2250LogicalChannelParameters_source = (1 << 19), + } options; + H245_TransportAddress mediaChannel; + H245_TransportAddress mediaControlChannel; +} H2250LogicalChannelParameters; + +typedef struct OpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters { /* CHOICE */ + enum { + eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_h222LogicalChannelParameters, + eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_h223LogicalChannelParameters, + eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_v76LogicalChannelParameters, + eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters, + eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_none, + } choice; + union { + H2250LogicalChannelParameters h2250LogicalChannelParameters; + }; +} OpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters; + +typedef struct OpenLogicalChannel_forwardLogicalChannelParameters { /* SEQUENCE */ + enum { + eOpenLogicalChannel_forwardLogicalChannelParameters_portNumber + = (1 << 31), + eOpenLogicalChannel_forwardLogicalChannelParameters_forwardLogicalChannelDependency + = (1 << 30), + eOpenLogicalChannel_forwardLogicalChannelParameters_replacementFor + = (1 << 29), + } options; + DataType dataType; + OpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters + multiplexParameters; +} OpenLogicalChannel_forwardLogicalChannelParameters; + +typedef struct OpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters { /* CHOICE */ + enum { + eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters_h223LogicalChannelParameters, + eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters_v76LogicalChannelParameters, + eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters, + } choice; + union { + H2250LogicalChannelParameters h2250LogicalChannelParameters; + }; +} OpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters; + +typedef struct OpenLogicalChannel_reverseLogicalChannelParameters { /* SEQUENCE */ + enum { + eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters + = (1 << 31), + eOpenLogicalChannel_reverseLogicalChannelParameters_reverseLogicalChannelDependency + = (1 << 30), + eOpenLogicalChannel_reverseLogicalChannelParameters_replacementFor + = (1 << 29), + } options; + OpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters + multiplexParameters; +} OpenLogicalChannel_reverseLogicalChannelParameters; + +typedef struct NetworkAccessParameters_networkAddress { /* CHOICE */ + enum { + eNetworkAccessParameters_networkAddress_q2931Address, + eNetworkAccessParameters_networkAddress_e164Address, + eNetworkAccessParameters_networkAddress_localAreaAddress, + } choice; + union { + H245_TransportAddress localAreaAddress; + }; +} NetworkAccessParameters_networkAddress; + +typedef struct NetworkAccessParameters { /* SEQUENCE */ + enum { + eNetworkAccessParameters_distribution = (1 << 31), + eNetworkAccessParameters_externalReference = (1 << 30), + eNetworkAccessParameters_t120SetupProcedure = (1 << 29), + } options; + NetworkAccessParameters_networkAddress networkAddress; +} NetworkAccessParameters; + +typedef struct OpenLogicalChannel { /* SEQUENCE */ + enum { + eOpenLogicalChannel_reverseLogicalChannelParameters = + (1 << 31), + eOpenLogicalChannel_separateStack = (1 << 30), + eOpenLogicalChannel_encryptionSync = (1 << 29), + } options; + OpenLogicalChannel_forwardLogicalChannelParameters + forwardLogicalChannelParameters; + OpenLogicalChannel_reverseLogicalChannelParameters + reverseLogicalChannelParameters; + NetworkAccessParameters separateStack; +} OpenLogicalChannel; + +typedef struct Setup_UUIE_fastStart { /* SEQUENCE OF */ + int count; + OpenLogicalChannel item[30]; +} Setup_UUIE_fastStart; + +typedef struct Setup_UUIE { /* SEQUENCE */ + enum { + eSetup_UUIE_h245Address = (1 << 31), + eSetup_UUIE_sourceAddress = (1 << 30), + eSetup_UUIE_destinationAddress = (1 << 29), + eSetup_UUIE_destCallSignalAddress = (1 << 28), + eSetup_UUIE_destExtraCallInfo = (1 << 27), + eSetup_UUIE_destExtraCRV = (1 << 26), + eSetup_UUIE_callServices = (1 << 25), + eSetup_UUIE_sourceCallSignalAddress = (1 << 24), + eSetup_UUIE_remoteExtensionAddress = (1 << 23), + eSetup_UUIE_callIdentifier = (1 << 22), + eSetup_UUIE_h245SecurityCapability = (1 << 21), + eSetup_UUIE_tokens = (1 << 20), + eSetup_UUIE_cryptoTokens = (1 << 19), + eSetup_UUIE_fastStart = (1 << 18), + eSetup_UUIE_mediaWaitForConnect = (1 << 17), + eSetup_UUIE_canOverlapSend = (1 << 16), + eSetup_UUIE_endpointIdentifier = (1 << 15), + eSetup_UUIE_multipleCalls = (1 << 14), + eSetup_UUIE_maintainConnection = (1 << 13), + eSetup_UUIE_connectionParameters = (1 << 12), + eSetup_UUIE_language = (1 << 11), + eSetup_UUIE_presentationIndicator = (1 << 10), + eSetup_UUIE_screeningIndicator = (1 << 9), + eSetup_UUIE_serviceControl = (1 << 8), + eSetup_UUIE_symmetricOperationRequired = (1 << 7), + eSetup_UUIE_capacity = (1 << 6), + eSetup_UUIE_circuitInfo = (1 << 5), + eSetup_UUIE_desiredProtocols = (1 << 4), + eSetup_UUIE_neededFeatures = (1 << 3), + eSetup_UUIE_desiredFeatures = (1 << 2), + eSetup_UUIE_supportedFeatures = (1 << 1), + eSetup_UUIE_parallelH245Control = (1 << 0), + } options; + TransportAddress h245Address; + TransportAddress destCallSignalAddress; + TransportAddress sourceCallSignalAddress; + Setup_UUIE_fastStart fastStart; +} Setup_UUIE; + +typedef struct CallProceeding_UUIE_fastStart { /* SEQUENCE OF */ + int count; + OpenLogicalChannel item[30]; +} CallProceeding_UUIE_fastStart; + +typedef struct CallProceeding_UUIE { /* SEQUENCE */ + enum { + eCallProceeding_UUIE_h245Address = (1 << 31), + eCallProceeding_UUIE_callIdentifier = (1 << 30), + eCallProceeding_UUIE_h245SecurityMode = (1 << 29), + eCallProceeding_UUIE_tokens = (1 << 28), + eCallProceeding_UUIE_cryptoTokens = (1 << 27), + eCallProceeding_UUIE_fastStart = (1 << 26), + eCallProceeding_UUIE_multipleCalls = (1 << 25), + eCallProceeding_UUIE_maintainConnection = (1 << 24), + eCallProceeding_UUIE_fastConnectRefused = (1 << 23), + eCallProceeding_UUIE_featureSet = (1 << 22), + } options; + TransportAddress h245Address; + CallProceeding_UUIE_fastStart fastStart; +} CallProceeding_UUIE; + +typedef struct Connect_UUIE_fastStart { /* SEQUENCE OF */ + int count; + OpenLogicalChannel item[30]; +} Connect_UUIE_fastStart; + +typedef struct Connect_UUIE { /* SEQUENCE */ + enum { + eConnect_UUIE_h245Address = (1 << 31), + eConnect_UUIE_callIdentifier = (1 << 30), + eConnect_UUIE_h245SecurityMode = (1 << 29), + eConnect_UUIE_tokens = (1 << 28), + eConnect_UUIE_cryptoTokens = (1 << 27), + eConnect_UUIE_fastStart = (1 << 26), + eConnect_UUIE_multipleCalls = (1 << 25), + eConnect_UUIE_maintainConnection = (1 << 24), + eConnect_UUIE_language = (1 << 23), + eConnect_UUIE_connectedAddress = (1 << 22), + eConnect_UUIE_presentationIndicator = (1 << 21), + eConnect_UUIE_screeningIndicator = (1 << 20), + eConnect_UUIE_fastConnectRefused = (1 << 19), + eConnect_UUIE_serviceControl = (1 << 18), + eConnect_UUIE_capacity = (1 << 17), + eConnect_UUIE_featureSet = (1 << 16), + } options; + TransportAddress h245Address; + Connect_UUIE_fastStart fastStart; +} Connect_UUIE; + +typedef struct Alerting_UUIE_fastStart { /* SEQUENCE OF */ + int count; + OpenLogicalChannel item[30]; +} Alerting_UUIE_fastStart; + +typedef struct Alerting_UUIE { /* SEQUENCE */ + enum { + eAlerting_UUIE_h245Address = (1 << 31), + eAlerting_UUIE_callIdentifier = (1 << 30), + eAlerting_UUIE_h245SecurityMode = (1 << 29), + eAlerting_UUIE_tokens = (1 << 28), + eAlerting_UUIE_cryptoTokens = (1 << 27), + eAlerting_UUIE_fastStart = (1 << 26), + eAlerting_UUIE_multipleCalls = (1 << 25), + eAlerting_UUIE_maintainConnection = (1 << 24), + eAlerting_UUIE_alertingAddress = (1 << 23), + eAlerting_UUIE_presentationIndicator = (1 << 22), + eAlerting_UUIE_screeningIndicator = (1 << 21), + eAlerting_UUIE_fastConnectRefused = (1 << 20), + eAlerting_UUIE_serviceControl = (1 << 19), + eAlerting_UUIE_capacity = (1 << 18), + eAlerting_UUIE_featureSet = (1 << 17), + } options; + TransportAddress h245Address; + Alerting_UUIE_fastStart fastStart; +} Alerting_UUIE; + +typedef struct Information_UUIE_fastStart { /* SEQUENCE OF */ + int count; + OpenLogicalChannel item[30]; +} Information_UUIE_fastStart; + +typedef struct Information_UUIE { /* SEQUENCE */ + enum { + eInformation_UUIE_callIdentifier = (1 << 31), + eInformation_UUIE_tokens = (1 << 30), + eInformation_UUIE_cryptoTokens = (1 << 29), + eInformation_UUIE_fastStart = (1 << 28), + eInformation_UUIE_fastConnectRefused = (1 << 27), + eInformation_UUIE_circuitInfo = (1 << 26), + } options; + Information_UUIE_fastStart fastStart; +} Information_UUIE; + +typedef struct FacilityReason { /* CHOICE */ + enum { + eFacilityReason_routeCallToGatekeeper, + eFacilityReason_callForwarded, + eFacilityReason_routeCallToMC, + eFacilityReason_undefinedReason, + eFacilityReason_conferenceListChoice, + eFacilityReason_startH245, + eFacilityReason_noH245, + eFacilityReason_newTokens, + eFacilityReason_featureSetUpdate, + eFacilityReason_forwardedElements, + eFacilityReason_transportedInformation, + } choice; +} FacilityReason; + +typedef struct Facility_UUIE_fastStart { /* SEQUENCE OF */ + int count; + OpenLogicalChannel item[30]; +} Facility_UUIE_fastStart; + +typedef struct Facility_UUIE { /* SEQUENCE */ + enum { + eFacility_UUIE_alternativeAddress = (1 << 31), + eFacility_UUIE_alternativeAliasAddress = (1 << 30), + eFacility_UUIE_conferenceID = (1 << 29), + eFacility_UUIE_callIdentifier = (1 << 28), + eFacility_UUIE_destExtraCallInfo = (1 << 27), + eFacility_UUIE_remoteExtensionAddress = (1 << 26), + eFacility_UUIE_tokens = (1 << 25), + eFacility_UUIE_cryptoTokens = (1 << 24), + eFacility_UUIE_conferences = (1 << 23), + eFacility_UUIE_h245Address = (1 << 22), + eFacility_UUIE_fastStart = (1 << 21), + eFacility_UUIE_multipleCalls = (1 << 20), + eFacility_UUIE_maintainConnection = (1 << 19), + eFacility_UUIE_fastConnectRefused = (1 << 18), + eFacility_UUIE_serviceControl = (1 << 17), + eFacility_UUIE_circuitInfo = (1 << 16), + eFacility_UUIE_featureSet = (1 << 15), + eFacility_UUIE_destinationInfo = (1 << 14), + eFacility_UUIE_h245SecurityMode = (1 << 13), + } options; + FacilityReason reason; + TransportAddress h245Address; + Facility_UUIE_fastStart fastStart; +} Facility_UUIE; + +typedef struct Progress_UUIE_fastStart { /* SEQUENCE OF */ + int count; + OpenLogicalChannel item[30]; +} Progress_UUIE_fastStart; + +typedef struct Progress_UUIE { /* SEQUENCE */ + enum { + eProgress_UUIE_h245Address = (1 << 31), + eProgress_UUIE_h245SecurityMode = (1 << 30), + eProgress_UUIE_tokens = (1 << 29), + eProgress_UUIE_cryptoTokens = (1 << 28), + eProgress_UUIE_fastStart = (1 << 27), + eProgress_UUIE_multipleCalls = (1 << 26), + eProgress_UUIE_maintainConnection = (1 << 25), + eProgress_UUIE_fastConnectRefused = (1 << 24), + } options; + TransportAddress h245Address; + Progress_UUIE_fastStart fastStart; +} Progress_UUIE; + +typedef struct H323_UU_PDU_h323_message_body { /* CHOICE */ + enum { + eH323_UU_PDU_h323_message_body_setup, + eH323_UU_PDU_h323_message_body_callProceeding, + eH323_UU_PDU_h323_message_body_connect, + eH323_UU_PDU_h323_message_body_alerting, + eH323_UU_PDU_h323_message_body_information, + eH323_UU_PDU_h323_message_body_releaseComplete, + eH323_UU_PDU_h323_message_body_facility, + eH323_UU_PDU_h323_message_body_progress, + eH323_UU_PDU_h323_message_body_empty, + eH323_UU_PDU_h323_message_body_status, + eH323_UU_PDU_h323_message_body_statusInquiry, + eH323_UU_PDU_h323_message_body_setupAcknowledge, + eH323_UU_PDU_h323_message_body_notify, + } choice; + union { + Setup_UUIE setup; + CallProceeding_UUIE callProceeding; + Connect_UUIE connect; + Alerting_UUIE alerting; + Information_UUIE information; + Facility_UUIE facility; + Progress_UUIE progress; + }; +} H323_UU_PDU_h323_message_body; + +typedef struct RequestMessage { /* CHOICE */ + enum { + eRequestMessage_nonStandard, + eRequestMessage_masterSlaveDetermination, + eRequestMessage_terminalCapabilitySet, + eRequestMessage_openLogicalChannel, + eRequestMessage_closeLogicalChannel, + eRequestMessage_requestChannelClose, + eRequestMessage_multiplexEntrySend, + eRequestMessage_requestMultiplexEntry, + eRequestMessage_requestMode, + eRequestMessage_roundTripDelayRequest, + eRequestMessage_maintenanceLoopRequest, + eRequestMessage_communicationModeRequest, + eRequestMessage_conferenceRequest, + eRequestMessage_multilinkRequest, + eRequestMessage_logicalChannelRateRequest, + } choice; + union { + OpenLogicalChannel openLogicalChannel; + }; +} RequestMessage; + +typedef struct OpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters { /* CHOICE */ + enum { + eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters_h222LogicalChannelParameters, + eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters, + } choice; + union { + H2250LogicalChannelParameters h2250LogicalChannelParameters; + }; +} OpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters; + +typedef struct OpenLogicalChannelAck_reverseLogicalChannelParameters { /* SEQUENCE */ + enum { + eOpenLogicalChannelAck_reverseLogicalChannelParameters_portNumber + = (1 << 31), + eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters + = (1 << 30), + eOpenLogicalChannelAck_reverseLogicalChannelParameters_replacementFor + = (1 << 29), + } options; + OpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters + multiplexParameters; +} OpenLogicalChannelAck_reverseLogicalChannelParameters; + +typedef struct H2250LogicalChannelAckParameters { /* SEQUENCE */ + enum { + eH2250LogicalChannelAckParameters_nonStandard = (1 << 31), + eH2250LogicalChannelAckParameters_sessionID = (1 << 30), + eH2250LogicalChannelAckParameters_mediaChannel = (1 << 29), + eH2250LogicalChannelAckParameters_mediaControlChannel = + (1 << 28), + eH2250LogicalChannelAckParameters_dynamicRTPPayloadType = + (1 << 27), + eH2250LogicalChannelAckParameters_flowControlToZero = + (1 << 26), + eH2250LogicalChannelAckParameters_portNumber = (1 << 25), + } options; + H245_TransportAddress mediaChannel; + H245_TransportAddress mediaControlChannel; +} H2250LogicalChannelAckParameters; + +typedef struct OpenLogicalChannelAck_forwardMultiplexAckParameters { /* CHOICE */ + enum { + eOpenLogicalChannelAck_forwardMultiplexAckParameters_h2250LogicalChannelAckParameters, + } choice; + union { + H2250LogicalChannelAckParameters + h2250LogicalChannelAckParameters; + }; +} OpenLogicalChannelAck_forwardMultiplexAckParameters; + +typedef struct OpenLogicalChannelAck { /* SEQUENCE */ + enum { + eOpenLogicalChannelAck_reverseLogicalChannelParameters = + (1 << 31), + eOpenLogicalChannelAck_separateStack = (1 << 30), + eOpenLogicalChannelAck_forwardMultiplexAckParameters = + (1 << 29), + eOpenLogicalChannelAck_encryptionSync = (1 << 28), + } options; + OpenLogicalChannelAck_reverseLogicalChannelParameters + reverseLogicalChannelParameters; + OpenLogicalChannelAck_forwardMultiplexAckParameters + forwardMultiplexAckParameters; +} OpenLogicalChannelAck; + +typedef struct ResponseMessage { /* CHOICE */ + enum { + eResponseMessage_nonStandard, + eResponseMessage_masterSlaveDeterminationAck, + eResponseMessage_masterSlaveDeterminationReject, + eResponseMessage_terminalCapabilitySetAck, + eResponseMessage_terminalCapabilitySetReject, + eResponseMessage_openLogicalChannelAck, + eResponseMessage_openLogicalChannelReject, + eResponseMessage_closeLogicalChannelAck, + eResponseMessage_requestChannelCloseAck, + eResponseMessage_requestChannelCloseReject, + eResponseMessage_multiplexEntrySendAck, + eResponseMessage_multiplexEntrySendReject, + eResponseMessage_requestMultiplexEntryAck, + eResponseMessage_requestMultiplexEntryReject, + eResponseMessage_requestModeAck, + eResponseMessage_requestModeReject, + eResponseMessage_roundTripDelayResponse, + eResponseMessage_maintenanceLoopAck, + eResponseMessage_maintenanceLoopReject, + eResponseMessage_communicationModeResponse, + eResponseMessage_conferenceResponse, + eResponseMessage_multilinkResponse, + eResponseMessage_logicalChannelRateAcknowledge, + eResponseMessage_logicalChannelRateReject, + } choice; + union { + OpenLogicalChannelAck openLogicalChannelAck; + }; +} ResponseMessage; + +typedef struct MultimediaSystemControlMessage { /* CHOICE */ + enum { + eMultimediaSystemControlMessage_request, + eMultimediaSystemControlMessage_response, + eMultimediaSystemControlMessage_command, + eMultimediaSystemControlMessage_indication, + } choice; + union { + RequestMessage request; + ResponseMessage response; + }; +} MultimediaSystemControlMessage; + +typedef struct H323_UU_PDU_h245Control { /* SEQUENCE OF */ + int count; + MultimediaSystemControlMessage item[4]; +} H323_UU_PDU_h245Control; + +typedef struct H323_UU_PDU { /* SEQUENCE */ + enum { + eH323_UU_PDU_nonStandardData = (1 << 31), + eH323_UU_PDU_h4501SupplementaryService = (1 << 30), + eH323_UU_PDU_h245Tunneling = (1 << 29), + eH323_UU_PDU_h245Control = (1 << 28), + eH323_UU_PDU_nonStandardControl = (1 << 27), + eH323_UU_PDU_callLinkage = (1 << 26), + eH323_UU_PDU_tunnelledSignallingMessage = (1 << 25), + eH323_UU_PDU_provisionalRespToH245Tunneling = (1 << 24), + eH323_UU_PDU_stimulusControl = (1 << 23), + eH323_UU_PDU_genericData = (1 << 22), + } options; + H323_UU_PDU_h323_message_body h323_message_body; + H323_UU_PDU_h245Control h245Control; +} H323_UU_PDU; + +typedef struct H323_UserInformation { /* SEQUENCE */ + enum { + eH323_UserInformation_user_data = (1 << 31), + } options; + H323_UU_PDU h323_uu_pdu; +} H323_UserInformation; + +typedef struct GatekeeperRequest { /* SEQUENCE */ + enum { + eGatekeeperRequest_nonStandardData = (1 << 31), + eGatekeeperRequest_gatekeeperIdentifier = (1 << 30), + eGatekeeperRequest_callServices = (1 << 29), + eGatekeeperRequest_endpointAlias = (1 << 28), + eGatekeeperRequest_alternateEndpoints = (1 << 27), + eGatekeeperRequest_tokens = (1 << 26), + eGatekeeperRequest_cryptoTokens = (1 << 25), + eGatekeeperRequest_authenticationCapability = (1 << 24), + eGatekeeperRequest_algorithmOIDs = (1 << 23), + eGatekeeperRequest_integrity = (1 << 22), + eGatekeeperRequest_integrityCheckValue = (1 << 21), + eGatekeeperRequest_supportsAltGK = (1 << 20), + eGatekeeperRequest_featureSet = (1 << 19), + eGatekeeperRequest_genericData = (1 << 18), + } options; + TransportAddress rasAddress; +} GatekeeperRequest; + +typedef struct GatekeeperConfirm { /* SEQUENCE */ + enum { + eGatekeeperConfirm_nonStandardData = (1 << 31), + eGatekeeperConfirm_gatekeeperIdentifier = (1 << 30), + eGatekeeperConfirm_alternateGatekeeper = (1 << 29), + eGatekeeperConfirm_authenticationMode = (1 << 28), + eGatekeeperConfirm_tokens = (1 << 27), + eGatekeeperConfirm_cryptoTokens = (1 << 26), + eGatekeeperConfirm_algorithmOID = (1 << 25), + eGatekeeperConfirm_integrity = (1 << 24), + eGatekeeperConfirm_integrityCheckValue = (1 << 23), + eGatekeeperConfirm_featureSet = (1 << 22), + eGatekeeperConfirm_genericData = (1 << 21), + } options; + TransportAddress rasAddress; +} GatekeeperConfirm; + +typedef struct RegistrationRequest_callSignalAddress { /* SEQUENCE OF */ + int count; + TransportAddress item[10]; +} RegistrationRequest_callSignalAddress; + +typedef struct RegistrationRequest_rasAddress { /* SEQUENCE OF */ + int count; + TransportAddress item[10]; +} RegistrationRequest_rasAddress; + +typedef struct RegistrationRequest { /* SEQUENCE */ + enum { + eRegistrationRequest_nonStandardData = (1 << 31), + eRegistrationRequest_terminalAlias = (1 << 30), + eRegistrationRequest_gatekeeperIdentifier = (1 << 29), + eRegistrationRequest_alternateEndpoints = (1 << 28), + eRegistrationRequest_timeToLive = (1 << 27), + eRegistrationRequest_tokens = (1 << 26), + eRegistrationRequest_cryptoTokens = (1 << 25), + eRegistrationRequest_integrityCheckValue = (1 << 24), + eRegistrationRequest_keepAlive = (1 << 23), + eRegistrationRequest_endpointIdentifier = (1 << 22), + eRegistrationRequest_willSupplyUUIEs = (1 << 21), + eRegistrationRequest_maintainConnection = (1 << 20), + eRegistrationRequest_alternateTransportAddresses = (1 << 19), + eRegistrationRequest_additiveRegistration = (1 << 18), + eRegistrationRequest_terminalAliasPattern = (1 << 17), + eRegistrationRequest_supportsAltGK = (1 << 16), + eRegistrationRequest_usageReportingCapability = (1 << 15), + eRegistrationRequest_multipleCalls = (1 << 14), + eRegistrationRequest_supportedH248Packages = (1 << 13), + eRegistrationRequest_callCreditCapability = (1 << 12), + eRegistrationRequest_capacityReportingCapability = (1 << 11), + eRegistrationRequest_capacity = (1 << 10), + eRegistrationRequest_featureSet = (1 << 9), + eRegistrationRequest_genericData = (1 << 8), + } options; + RegistrationRequest_callSignalAddress callSignalAddress; + RegistrationRequest_rasAddress rasAddress; + unsigned timeToLive; +} RegistrationRequest; + +typedef struct RegistrationConfirm_callSignalAddress { /* SEQUENCE OF */ + int count; + TransportAddress item[10]; +} RegistrationConfirm_callSignalAddress; + +typedef struct RegistrationConfirm { /* SEQUENCE */ + enum { + eRegistrationConfirm_nonStandardData = (1 << 31), + eRegistrationConfirm_terminalAlias = (1 << 30), + eRegistrationConfirm_gatekeeperIdentifier = (1 << 29), + eRegistrationConfirm_alternateGatekeeper = (1 << 28), + eRegistrationConfirm_timeToLive = (1 << 27), + eRegistrationConfirm_tokens = (1 << 26), + eRegistrationConfirm_cryptoTokens = (1 << 25), + eRegistrationConfirm_integrityCheckValue = (1 << 24), + eRegistrationConfirm_willRespondToIRR = (1 << 23), + eRegistrationConfirm_preGrantedARQ = (1 << 22), + eRegistrationConfirm_maintainConnection = (1 << 21), + eRegistrationConfirm_serviceControl = (1 << 20), + eRegistrationConfirm_supportsAdditiveRegistration = (1 << 19), + eRegistrationConfirm_terminalAliasPattern = (1 << 18), + eRegistrationConfirm_supportedPrefixes = (1 << 17), + eRegistrationConfirm_usageSpec = (1 << 16), + eRegistrationConfirm_featureServerAlias = (1 << 15), + eRegistrationConfirm_capacityReportingSpec = (1 << 14), + eRegistrationConfirm_featureSet = (1 << 13), + eRegistrationConfirm_genericData = (1 << 12), + } options; + RegistrationConfirm_callSignalAddress callSignalAddress; + unsigned timeToLive; +} RegistrationConfirm; + +typedef struct UnregistrationRequest_callSignalAddress { /* SEQUENCE OF */ + int count; + TransportAddress item[10]; +} UnregistrationRequest_callSignalAddress; + +typedef struct UnregistrationRequest { /* SEQUENCE */ + enum { + eUnregistrationRequest_endpointAlias = (1 << 31), + eUnregistrationRequest_nonStandardData = (1 << 30), + eUnregistrationRequest_endpointIdentifier = (1 << 29), + eUnregistrationRequest_alternateEndpoints = (1 << 28), + eUnregistrationRequest_gatekeeperIdentifier = (1 << 27), + eUnregistrationRequest_tokens = (1 << 26), + eUnregistrationRequest_cryptoTokens = (1 << 25), + eUnregistrationRequest_integrityCheckValue = (1 << 24), + eUnregistrationRequest_reason = (1 << 23), + eUnregistrationRequest_endpointAliasPattern = (1 << 22), + eUnregistrationRequest_supportedPrefixes = (1 << 21), + eUnregistrationRequest_alternateGatekeeper = (1 << 20), + eUnregistrationRequest_genericData = (1 << 19), + } options; + UnregistrationRequest_callSignalAddress callSignalAddress; +} UnregistrationRequest; + +typedef struct AdmissionRequest { /* SEQUENCE */ + enum { + eAdmissionRequest_callModel = (1 << 31), + eAdmissionRequest_destinationInfo = (1 << 30), + eAdmissionRequest_destCallSignalAddress = (1 << 29), + eAdmissionRequest_destExtraCallInfo = (1 << 28), + eAdmissionRequest_srcCallSignalAddress = (1 << 27), + eAdmissionRequest_nonStandardData = (1 << 26), + eAdmissionRequest_callServices = (1 << 25), + eAdmissionRequest_canMapAlias = (1 << 24), + eAdmissionRequest_callIdentifier = (1 << 23), + eAdmissionRequest_srcAlternatives = (1 << 22), + eAdmissionRequest_destAlternatives = (1 << 21), + eAdmissionRequest_gatekeeperIdentifier = (1 << 20), + eAdmissionRequest_tokens = (1 << 19), + eAdmissionRequest_cryptoTokens = (1 << 18), + eAdmissionRequest_integrityCheckValue = (1 << 17), + eAdmissionRequest_transportQOS = (1 << 16), + eAdmissionRequest_willSupplyUUIEs = (1 << 15), + eAdmissionRequest_callLinkage = (1 << 14), + eAdmissionRequest_gatewayDataRate = (1 << 13), + eAdmissionRequest_capacity = (1 << 12), + eAdmissionRequest_circuitInfo = (1 << 11), + eAdmissionRequest_desiredProtocols = (1 << 10), + eAdmissionRequest_desiredTunnelledProtocol = (1 << 9), + eAdmissionRequest_featureSet = (1 << 8), + eAdmissionRequest_genericData = (1 << 7), + } options; + TransportAddress destCallSignalAddress; + TransportAddress srcCallSignalAddress; +} AdmissionRequest; + +typedef struct AdmissionConfirm { /* SEQUENCE */ + enum { + eAdmissionConfirm_irrFrequency = (1 << 31), + eAdmissionConfirm_nonStandardData = (1 << 30), + eAdmissionConfirm_destinationInfo = (1 << 29), + eAdmissionConfirm_destExtraCallInfo = (1 << 28), + eAdmissionConfirm_destinationType = (1 << 27), + eAdmissionConfirm_remoteExtensionAddress = (1 << 26), + eAdmissionConfirm_alternateEndpoints = (1 << 25), + eAdmissionConfirm_tokens = (1 << 24), + eAdmissionConfirm_cryptoTokens = (1 << 23), + eAdmissionConfirm_integrityCheckValue = (1 << 22), + eAdmissionConfirm_transportQOS = (1 << 21), + eAdmissionConfirm_willRespondToIRR = (1 << 20), + eAdmissionConfirm_uuiesRequested = (1 << 19), + eAdmissionConfirm_language = (1 << 18), + eAdmissionConfirm_alternateTransportAddresses = (1 << 17), + eAdmissionConfirm_useSpecifiedTransport = (1 << 16), + eAdmissionConfirm_circuitInfo = (1 << 15), + eAdmissionConfirm_usageSpec = (1 << 14), + eAdmissionConfirm_supportedProtocols = (1 << 13), + eAdmissionConfirm_serviceControl = (1 << 12), + eAdmissionConfirm_multipleCalls = (1 << 11), + eAdmissionConfirm_featureSet = (1 << 10), + eAdmissionConfirm_genericData = (1 << 9), + } options; + TransportAddress destCallSignalAddress; +} AdmissionConfirm; + +typedef struct LocationRequest { /* SEQUENCE */ + enum { + eLocationRequest_endpointIdentifier = (1 << 31), + eLocationRequest_nonStandardData = (1 << 30), + eLocationRequest_sourceInfo = (1 << 29), + eLocationRequest_canMapAlias = (1 << 28), + eLocationRequest_gatekeeperIdentifier = (1 << 27), + eLocationRequest_tokens = (1 << 26), + eLocationRequest_cryptoTokens = (1 << 25), + eLocationRequest_integrityCheckValue = (1 << 24), + eLocationRequest_desiredProtocols = (1 << 23), + eLocationRequest_desiredTunnelledProtocol = (1 << 22), + eLocationRequest_featureSet = (1 << 21), + eLocationRequest_genericData = (1 << 20), + eLocationRequest_hopCount = (1 << 19), + eLocationRequest_circuitInfo = (1 << 18), + } options; + TransportAddress replyAddress; +} LocationRequest; + +typedef struct LocationConfirm { /* SEQUENCE */ + enum { + eLocationConfirm_nonStandardData = (1 << 31), + eLocationConfirm_destinationInfo = (1 << 30), + eLocationConfirm_destExtraCallInfo = (1 << 29), + eLocationConfirm_destinationType = (1 << 28), + eLocationConfirm_remoteExtensionAddress = (1 << 27), + eLocationConfirm_alternateEndpoints = (1 << 26), + eLocationConfirm_tokens = (1 << 25), + eLocationConfirm_cryptoTokens = (1 << 24), + eLocationConfirm_integrityCheckValue = (1 << 23), + eLocationConfirm_alternateTransportAddresses = (1 << 22), + eLocationConfirm_supportedProtocols = (1 << 21), + eLocationConfirm_multipleCalls = (1 << 20), + eLocationConfirm_featureSet = (1 << 19), + eLocationConfirm_genericData = (1 << 18), + eLocationConfirm_circuitInfo = (1 << 17), + eLocationConfirm_serviceControl = (1 << 16), + } options; + TransportAddress callSignalAddress; + TransportAddress rasAddress; +} LocationConfirm; + +typedef struct InfoRequestResponse_callSignalAddress { /* SEQUENCE OF */ + int count; + TransportAddress item[10]; +} InfoRequestResponse_callSignalAddress; + +typedef struct InfoRequestResponse { /* SEQUENCE */ + enum { + eInfoRequestResponse_nonStandardData = (1 << 31), + eInfoRequestResponse_endpointAlias = (1 << 30), + eInfoRequestResponse_perCallInfo = (1 << 29), + eInfoRequestResponse_tokens = (1 << 28), + eInfoRequestResponse_cryptoTokens = (1 << 27), + eInfoRequestResponse_integrityCheckValue = (1 << 26), + eInfoRequestResponse_needResponse = (1 << 25), + eInfoRequestResponse_capacity = (1 << 24), + eInfoRequestResponse_irrStatus = (1 << 23), + eInfoRequestResponse_unsolicited = (1 << 22), + eInfoRequestResponse_genericData = (1 << 21), + } options; + TransportAddress rasAddress; + InfoRequestResponse_callSignalAddress callSignalAddress; +} InfoRequestResponse; + +typedef struct RasMessage { /* CHOICE */ + enum { + eRasMessage_gatekeeperRequest, + eRasMessage_gatekeeperConfirm, + eRasMessage_gatekeeperReject, + eRasMessage_registrationRequest, + eRasMessage_registrationConfirm, + eRasMessage_registrationReject, + eRasMessage_unregistrationRequest, + eRasMessage_unregistrationConfirm, + eRasMessage_unregistrationReject, + eRasMessage_admissionRequest, + eRasMessage_admissionConfirm, + eRasMessage_admissionReject, + eRasMessage_bandwidthRequest, + eRasMessage_bandwidthConfirm, + eRasMessage_bandwidthReject, + eRasMessage_disengageRequest, + eRasMessage_disengageConfirm, + eRasMessage_disengageReject, + eRasMessage_locationRequest, + eRasMessage_locationConfirm, + eRasMessage_locationReject, + eRasMessage_infoRequest, + eRasMessage_infoRequestResponse, + eRasMessage_nonStandardMessage, + eRasMessage_unknownMessageResponse, + eRasMessage_requestInProgress, + eRasMessage_resourcesAvailableIndicate, + eRasMessage_resourcesAvailableConfirm, + eRasMessage_infoRequestAck, + eRasMessage_infoRequestNak, + eRasMessage_serviceControlIndication, + eRasMessage_serviceControlResponse, + } choice; + union { + GatekeeperRequest gatekeeperRequest; + GatekeeperConfirm gatekeeperConfirm; + RegistrationRequest registrationRequest; + RegistrationConfirm registrationConfirm; + UnregistrationRequest unregistrationRequest; + AdmissionRequest admissionRequest; + AdmissionConfirm admissionConfirm; + LocationRequest locationRequest; + LocationConfirm locationConfirm; + InfoRequestResponse infoRequestResponse; + }; +} RasMessage; diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c index daeb139..fc817fd 100644 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c @@ -54,8 +54,6 @@ #include #include -#include "ip_conntrack_helper_h323_asn1.h" - #if 0 #define DEBUGP printk #else diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.c b/net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.c index afa5251..4807800 100644 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.c +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.c @@ -15,7 +15,7 @@ #else #include #endif -#include "ip_conntrack_helper_h323_asn1.h" +#include /* Trace Flag */ #ifndef H323_TRACE diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.h b/net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.h deleted file mode 100644 index 0bd8280..0000000 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323_asn1.h +++ /dev/null @@ -1,98 +0,0 @@ -/**************************************************************************** - * ip_conntrack_helper_h323_asn1.h - BER and PER decoding library for H.323 - * conntrack/NAT module. - * - * Copyright (c) 2006 by Jing Min Zhao - * - * This source code is licensed under General Public License version 2. - * - * - * This library is based on H.225 version 4, H.235 version 2 and H.245 - * version 7. It is extremely optimized to decode only the absolutely - * necessary objects in a signal for Linux kernel NAT module use, so don't - * expect it to be a full ASN.1 library. - * - * Features: - * - * 1. Small. The total size of code plus data is less than 20 KB (IA32). - * 2. Fast. Decoding Netmeeting's Setup signal 1 million times on a PIII 866 - * takes only 3.9 seconds. - * 3. No memory allocation. It uses a static object. No need to initialize or - * cleanup. - * 4. Thread safe. - * 5. Support embedded architectures that has no misaligned memory access - * support. - * - * Limitations: - * - * 1. At most 30 faststart entries. Actually this is limited by ethernet's MTU. - * If a Setup signal contains more than 30 faststart, the packet size will - * very likely exceed the MTU size, then the TPKT will be fragmented. I - * don't know how to handle this in a Netfilter module. Anybody can help? - * Although I think 30 is enough for most of the cases. - * 2. IPv4 addresses only. - * - ****************************************************************************/ - -#ifndef _IP_CONNTRACK_HELPER_H323_ASN1_H_ -#define _IP_CONNTRACK_HELPER_H323_ASN1_H_ - -/***************************************************************************** - * H.323 Types - ****************************************************************************/ -#include "ip_conntrack_helper_h323_types.h" - -typedef struct { - enum { - Q931_NationalEscape = 0x00, - Q931_Alerting = 0x01, - Q931_CallProceeding = 0x02, - Q931_Connect = 0x07, - Q931_ConnectAck = 0x0F, - Q931_Progress = 0x03, - Q931_Setup = 0x05, - Q931_SetupAck = 0x0D, - Q931_Resume = 0x26, - Q931_ResumeAck = 0x2E, - Q931_ResumeReject = 0x22, - Q931_Suspend = 0x25, - Q931_SuspendAck = 0x2D, - Q931_SuspendReject = 0x21, - Q931_UserInformation = 0x20, - Q931_Disconnect = 0x45, - Q931_Release = 0x4D, - Q931_ReleaseComplete = 0x5A, - Q931_Restart = 0x46, - Q931_RestartAck = 0x4E, - Q931_Segment = 0x60, - Q931_CongestionCtrl = 0x79, - Q931_Information = 0x7B, - Q931_Notify = 0x6E, - Q931_Status = 0x7D, - Q931_StatusEnquiry = 0x75, - Q931_Facility = 0x62 - } MessageType; - H323_UserInformation UUIE; -} Q931; - -/***************************************************************************** - * Decode Functions Return Codes - ****************************************************************************/ - -#define H323_ERROR_NONE 0 /* Decoded successfully */ -#define H323_ERROR_STOP 1 /* Decoding stopped, not really an error */ -#define H323_ERROR_BOUND -1 -#define H323_ERROR_RANGE -2 - - -/***************************************************************************** - * Decode Functions - ****************************************************************************/ - -int DecodeRasMessage(unsigned char *buf, size_t sz, RasMessage * ras); -int DecodeQ931(unsigned char *buf, size_t sz, Q931 * q931); -int DecodeMultimediaSystemControlMessage(unsigned char *buf, size_t sz, - MultimediaSystemControlMessage * - mscm); - -#endif diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323_types.h b/net/ipv4/netfilter/ip_conntrack_helper_h323_types.h deleted file mode 100644 index cc98f7a..0000000 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323_types.h +++ /dev/null @@ -1,938 +0,0 @@ -/* Generated by Jing Min Zhao's ASN.1 parser, Mar 15 2006 - * - * Copyright (c) 2006 Jing Min Zhao - * - * This source code is licensed under General Public License version 2. - */ - -typedef struct TransportAddress_ipAddress { /* SEQUENCE */ - int options; /* No use */ - unsigned ip; -} TransportAddress_ipAddress; - -typedef struct TransportAddress { /* CHOICE */ - enum { - eTransportAddress_ipAddress, - eTransportAddress_ipSourceRoute, - eTransportAddress_ipxAddress, - eTransportAddress_ip6Address, - eTransportAddress_netBios, - eTransportAddress_nsap, - eTransportAddress_nonStandardAddress, - } choice; - union { - TransportAddress_ipAddress ipAddress; - }; -} TransportAddress; - -typedef struct DataProtocolCapability { /* CHOICE */ - enum { - eDataProtocolCapability_nonStandard, - eDataProtocolCapability_v14buffered, - eDataProtocolCapability_v42lapm, - eDataProtocolCapability_hdlcFrameTunnelling, - eDataProtocolCapability_h310SeparateVCStack, - eDataProtocolCapability_h310SingleVCStack, - eDataProtocolCapability_transparent, - eDataProtocolCapability_segmentationAndReassembly, - eDataProtocolCapability_hdlcFrameTunnelingwSAR, - eDataProtocolCapability_v120, - eDataProtocolCapability_separateLANStack, - eDataProtocolCapability_v76wCompression, - eDataProtocolCapability_tcp, - eDataProtocolCapability_udp, - } choice; -} DataProtocolCapability; - -typedef struct DataApplicationCapability_application { /* CHOICE */ - enum { - eDataApplicationCapability_application_nonStandard, - eDataApplicationCapability_application_t120, - eDataApplicationCapability_application_dsm_cc, - eDataApplicationCapability_application_userData, - eDataApplicationCapability_application_t84, - eDataApplicationCapability_application_t434, - eDataApplicationCapability_application_h224, - eDataApplicationCapability_application_nlpid, - eDataApplicationCapability_application_dsvdControl, - eDataApplicationCapability_application_h222DataPartitioning, - eDataApplicationCapability_application_t30fax, - eDataApplicationCapability_application_t140, - eDataApplicationCapability_application_t38fax, - eDataApplicationCapability_application_genericDataCapability, - } choice; - union { - DataProtocolCapability t120; - }; -} DataApplicationCapability_application; - -typedef struct DataApplicationCapability { /* SEQUENCE */ - int options; /* No use */ - DataApplicationCapability_application application; -} DataApplicationCapability; - -typedef struct DataType { /* CHOICE */ - enum { - eDataType_nonStandard, - eDataType_nullData, - eDataType_videoData, - eDataType_audioData, - eDataType_data, - eDataType_encryptionData, - eDataType_h235Control, - eDataType_h235Media, - eDataType_multiplexedStream, - } choice; - union { - DataApplicationCapability data; - }; -} DataType; - -typedef struct UnicastAddress_iPAddress { /* SEQUENCE */ - int options; /* No use */ - unsigned network; -} UnicastAddress_iPAddress; - -typedef struct UnicastAddress { /* CHOICE */ - enum { - eUnicastAddress_iPAddress, - eUnicastAddress_iPXAddress, - eUnicastAddress_iP6Address, - eUnicastAddress_netBios, - eUnicastAddress_iPSourceRouteAddress, - eUnicastAddress_nsap, - eUnicastAddress_nonStandardAddress, - } choice; - union { - UnicastAddress_iPAddress iPAddress; - }; -} UnicastAddress; - -typedef struct H245_TransportAddress { /* CHOICE */ - enum { - eH245_TransportAddress_unicastAddress, - eH245_TransportAddress_multicastAddress, - } choice; - union { - UnicastAddress unicastAddress; - }; -} H245_TransportAddress; - -typedef struct H2250LogicalChannelParameters { /* SEQUENCE */ - enum { - eH2250LogicalChannelParameters_nonStandard = (1 << 31), - eH2250LogicalChannelParameters_associatedSessionID = - (1 << 30), - eH2250LogicalChannelParameters_mediaChannel = (1 << 29), - eH2250LogicalChannelParameters_mediaGuaranteedDelivery = - (1 << 28), - eH2250LogicalChannelParameters_mediaControlChannel = - (1 << 27), - eH2250LogicalChannelParameters_mediaControlGuaranteedDelivery - = (1 << 26), - eH2250LogicalChannelParameters_silenceSuppression = (1 << 25), - eH2250LogicalChannelParameters_destination = (1 << 24), - eH2250LogicalChannelParameters_dynamicRTPPayloadType = - (1 << 23), - eH2250LogicalChannelParameters_mediaPacketization = (1 << 22), - eH2250LogicalChannelParameters_transportCapability = - (1 << 21), - eH2250LogicalChannelParameters_redundancyEncoding = (1 << 20), - eH2250LogicalChannelParameters_source = (1 << 19), - } options; - H245_TransportAddress mediaChannel; - H245_TransportAddress mediaControlChannel; -} H2250LogicalChannelParameters; - -typedef struct OpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters { /* CHOICE */ - enum { - eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_h222LogicalChannelParameters, - eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_h223LogicalChannelParameters, - eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_v76LogicalChannelParameters, - eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters, - eOpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters_none, - } choice; - union { - H2250LogicalChannelParameters h2250LogicalChannelParameters; - }; -} OpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters; - -typedef struct OpenLogicalChannel_forwardLogicalChannelParameters { /* SEQUENCE */ - enum { - eOpenLogicalChannel_forwardLogicalChannelParameters_portNumber - = (1 << 31), - eOpenLogicalChannel_forwardLogicalChannelParameters_forwardLogicalChannelDependency - = (1 << 30), - eOpenLogicalChannel_forwardLogicalChannelParameters_replacementFor - = (1 << 29), - } options; - DataType dataType; - OpenLogicalChannel_forwardLogicalChannelParameters_multiplexParameters - multiplexParameters; -} OpenLogicalChannel_forwardLogicalChannelParameters; - -typedef struct OpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters { /* CHOICE */ - enum { - eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters_h223LogicalChannelParameters, - eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters_v76LogicalChannelParameters, - eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters, - } choice; - union { - H2250LogicalChannelParameters h2250LogicalChannelParameters; - }; -} OpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters; - -typedef struct OpenLogicalChannel_reverseLogicalChannelParameters { /* SEQUENCE */ - enum { - eOpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters - = (1 << 31), - eOpenLogicalChannel_reverseLogicalChannelParameters_reverseLogicalChannelDependency - = (1 << 30), - eOpenLogicalChannel_reverseLogicalChannelParameters_replacementFor - = (1 << 29), - } options; - OpenLogicalChannel_reverseLogicalChannelParameters_multiplexParameters - multiplexParameters; -} OpenLogicalChannel_reverseLogicalChannelParameters; - -typedef struct NetworkAccessParameters_networkAddress { /* CHOICE */ - enum { - eNetworkAccessParameters_networkAddress_q2931Address, - eNetworkAccessParameters_networkAddress_e164Address, - eNetworkAccessParameters_networkAddress_localAreaAddress, - } choice; - union { - H245_TransportAddress localAreaAddress; - }; -} NetworkAccessParameters_networkAddress; - -typedef struct NetworkAccessParameters { /* SEQUENCE */ - enum { - eNetworkAccessParameters_distribution = (1 << 31), - eNetworkAccessParameters_externalReference = (1 << 30), - eNetworkAccessParameters_t120SetupProcedure = (1 << 29), - } options; - NetworkAccessParameters_networkAddress networkAddress; -} NetworkAccessParameters; - -typedef struct OpenLogicalChannel { /* SEQUENCE */ - enum { - eOpenLogicalChannel_reverseLogicalChannelParameters = - (1 << 31), - eOpenLogicalChannel_separateStack = (1 << 30), - eOpenLogicalChannel_encryptionSync = (1 << 29), - } options; - OpenLogicalChannel_forwardLogicalChannelParameters - forwardLogicalChannelParameters; - OpenLogicalChannel_reverseLogicalChannelParameters - reverseLogicalChannelParameters; - NetworkAccessParameters separateStack; -} OpenLogicalChannel; - -typedef struct Setup_UUIE_fastStart { /* SEQUENCE OF */ - int count; - OpenLogicalChannel item[30]; -} Setup_UUIE_fastStart; - -typedef struct Setup_UUIE { /* SEQUENCE */ - enum { - eSetup_UUIE_h245Address = (1 << 31), - eSetup_UUIE_sourceAddress = (1 << 30), - eSetup_UUIE_destinationAddress = (1 << 29), - eSetup_UUIE_destCallSignalAddress = (1 << 28), - eSetup_UUIE_destExtraCallInfo = (1 << 27), - eSetup_UUIE_destExtraCRV = (1 << 26), - eSetup_UUIE_callServices = (1 << 25), - eSetup_UUIE_sourceCallSignalAddress = (1 << 24), - eSetup_UUIE_remoteExtensionAddress = (1 << 23), - eSetup_UUIE_callIdentifier = (1 << 22), - eSetup_UUIE_h245SecurityCapability = (1 << 21), - eSetup_UUIE_tokens = (1 << 20), - eSetup_UUIE_cryptoTokens = (1 << 19), - eSetup_UUIE_fastStart = (1 << 18), - eSetup_UUIE_mediaWaitForConnect = (1 << 17), - eSetup_UUIE_canOverlapSend = (1 << 16), - eSetup_UUIE_endpointIdentifier = (1 << 15), - eSetup_UUIE_multipleCalls = (1 << 14), - eSetup_UUIE_maintainConnection = (1 << 13), - eSetup_UUIE_connectionParameters = (1 << 12), - eSetup_UUIE_language = (1 << 11), - eSetup_UUIE_presentationIndicator = (1 << 10), - eSetup_UUIE_screeningIndicator = (1 << 9), - eSetup_UUIE_serviceControl = (1 << 8), - eSetup_UUIE_symmetricOperationRequired = (1 << 7), - eSetup_UUIE_capacity = (1 << 6), - eSetup_UUIE_circuitInfo = (1 << 5), - eSetup_UUIE_desiredProtocols = (1 << 4), - eSetup_UUIE_neededFeatures = (1 << 3), - eSetup_UUIE_desiredFeatures = (1 << 2), - eSetup_UUIE_supportedFeatures = (1 << 1), - eSetup_UUIE_parallelH245Control = (1 << 0), - } options; - TransportAddress h245Address; - TransportAddress destCallSignalAddress; - TransportAddress sourceCallSignalAddress; - Setup_UUIE_fastStart fastStart; -} Setup_UUIE; - -typedef struct CallProceeding_UUIE_fastStart { /* SEQUENCE OF */ - int count; - OpenLogicalChannel item[30]; -} CallProceeding_UUIE_fastStart; - -typedef struct CallProceeding_UUIE { /* SEQUENCE */ - enum { - eCallProceeding_UUIE_h245Address = (1 << 31), - eCallProceeding_UUIE_callIdentifier = (1 << 30), - eCallProceeding_UUIE_h245SecurityMode = (1 << 29), - eCallProceeding_UUIE_tokens = (1 << 28), - eCallProceeding_UUIE_cryptoTokens = (1 << 27), - eCallProceeding_UUIE_fastStart = (1 << 26), - eCallProceeding_UUIE_multipleCalls = (1 << 25), - eCallProceeding_UUIE_maintainConnection = (1 << 24), - eCallProceeding_UUIE_fastConnectRefused = (1 << 23), - eCallProceeding_UUIE_featureSet = (1 << 22), - } options; - TransportAddress h245Address; - CallProceeding_UUIE_fastStart fastStart; -} CallProceeding_UUIE; - -typedef struct Connect_UUIE_fastStart { /* SEQUENCE OF */ - int count; - OpenLogicalChannel item[30]; -} Connect_UUIE_fastStart; - -typedef struct Connect_UUIE { /* SEQUENCE */ - enum { - eConnect_UUIE_h245Address = (1 << 31), - eConnect_UUIE_callIdentifier = (1 << 30), - eConnect_UUIE_h245SecurityMode = (1 << 29), - eConnect_UUIE_tokens = (1 << 28), - eConnect_UUIE_cryptoTokens = (1 << 27), - eConnect_UUIE_fastStart = (1 << 26), - eConnect_UUIE_multipleCalls = (1 << 25), - eConnect_UUIE_maintainConnection = (1 << 24), - eConnect_UUIE_language = (1 << 23), - eConnect_UUIE_connectedAddress = (1 << 22), - eConnect_UUIE_presentationIndicator = (1 << 21), - eConnect_UUIE_screeningIndicator = (1 << 20), - eConnect_UUIE_fastConnectRefused = (1 << 19), - eConnect_UUIE_serviceControl = (1 << 18), - eConnect_UUIE_capacity = (1 << 17), - eConnect_UUIE_featureSet = (1 << 16), - } options; - TransportAddress h245Address; - Connect_UUIE_fastStart fastStart; -} Connect_UUIE; - -typedef struct Alerting_UUIE_fastStart { /* SEQUENCE OF */ - int count; - OpenLogicalChannel item[30]; -} Alerting_UUIE_fastStart; - -typedef struct Alerting_UUIE { /* SEQUENCE */ - enum { - eAlerting_UUIE_h245Address = (1 << 31), - eAlerting_UUIE_callIdentifier = (1 << 30), - eAlerting_UUIE_h245SecurityMode = (1 << 29), - eAlerting_UUIE_tokens = (1 << 28), - eAlerting_UUIE_cryptoTokens = (1 << 27), - eAlerting_UUIE_fastStart = (1 << 26), - eAlerting_UUIE_multipleCalls = (1 << 25), - eAlerting_UUIE_maintainConnection = (1 << 24), - eAlerting_UUIE_alertingAddress = (1 << 23), - eAlerting_UUIE_presentationIndicator = (1 << 22), - eAlerting_UUIE_screeningIndicator = (1 << 21), - eAlerting_UUIE_fastConnectRefused = (1 << 20), - eAlerting_UUIE_serviceControl = (1 << 19), - eAlerting_UUIE_capacity = (1 << 18), - eAlerting_UUIE_featureSet = (1 << 17), - } options; - TransportAddress h245Address; - Alerting_UUIE_fastStart fastStart; -} Alerting_UUIE; - -typedef struct Information_UUIE_fastStart { /* SEQUENCE OF */ - int count; - OpenLogicalChannel item[30]; -} Information_UUIE_fastStart; - -typedef struct Information_UUIE { /* SEQUENCE */ - enum { - eInformation_UUIE_callIdentifier = (1 << 31), - eInformation_UUIE_tokens = (1 << 30), - eInformation_UUIE_cryptoTokens = (1 << 29), - eInformation_UUIE_fastStart = (1 << 28), - eInformation_UUIE_fastConnectRefused = (1 << 27), - eInformation_UUIE_circuitInfo = (1 << 26), - } options; - Information_UUIE_fastStart fastStart; -} Information_UUIE; - -typedef struct FacilityReason { /* CHOICE */ - enum { - eFacilityReason_routeCallToGatekeeper, - eFacilityReason_callForwarded, - eFacilityReason_routeCallToMC, - eFacilityReason_undefinedReason, - eFacilityReason_conferenceListChoice, - eFacilityReason_startH245, - eFacilityReason_noH245, - eFacilityReason_newTokens, - eFacilityReason_featureSetUpdate, - eFacilityReason_forwardedElements, - eFacilityReason_transportedInformation, - } choice; -} FacilityReason; - -typedef struct Facility_UUIE_fastStart { /* SEQUENCE OF */ - int count; - OpenLogicalChannel item[30]; -} Facility_UUIE_fastStart; - -typedef struct Facility_UUIE { /* SEQUENCE */ - enum { - eFacility_UUIE_alternativeAddress = (1 << 31), - eFacility_UUIE_alternativeAliasAddress = (1 << 30), - eFacility_UUIE_conferenceID = (1 << 29), - eFacility_UUIE_callIdentifier = (1 << 28), - eFacility_UUIE_destExtraCallInfo = (1 << 27), - eFacility_UUIE_remoteExtensionAddress = (1 << 26), - eFacility_UUIE_tokens = (1 << 25), - eFacility_UUIE_cryptoTokens = (1 << 24), - eFacility_UUIE_conferences = (1 << 23), - eFacility_UUIE_h245Address = (1 << 22), - eFacility_UUIE_fastStart = (1 << 21), - eFacility_UUIE_multipleCalls = (1 << 20), - eFacility_UUIE_maintainConnection = (1 << 19), - eFacility_UUIE_fastConnectRefused = (1 << 18), - eFacility_UUIE_serviceControl = (1 << 17), - eFacility_UUIE_circuitInfo = (1 << 16), - eFacility_UUIE_featureSet = (1 << 15), - eFacility_UUIE_destinationInfo = (1 << 14), - eFacility_UUIE_h245SecurityMode = (1 << 13), - } options; - FacilityReason reason; - TransportAddress h245Address; - Facility_UUIE_fastStart fastStart; -} Facility_UUIE; - -typedef struct Progress_UUIE_fastStart { /* SEQUENCE OF */ - int count; - OpenLogicalChannel item[30]; -} Progress_UUIE_fastStart; - -typedef struct Progress_UUIE { /* SEQUENCE */ - enum { - eProgress_UUIE_h245Address = (1 << 31), - eProgress_UUIE_h245SecurityMode = (1 << 30), - eProgress_UUIE_tokens = (1 << 29), - eProgress_UUIE_cryptoTokens = (1 << 28), - eProgress_UUIE_fastStart = (1 << 27), - eProgress_UUIE_multipleCalls = (1 << 26), - eProgress_UUIE_maintainConnection = (1 << 25), - eProgress_UUIE_fastConnectRefused = (1 << 24), - } options; - TransportAddress h245Address; - Progress_UUIE_fastStart fastStart; -} Progress_UUIE; - -typedef struct H323_UU_PDU_h323_message_body { /* CHOICE */ - enum { - eH323_UU_PDU_h323_message_body_setup, - eH323_UU_PDU_h323_message_body_callProceeding, - eH323_UU_PDU_h323_message_body_connect, - eH323_UU_PDU_h323_message_body_alerting, - eH323_UU_PDU_h323_message_body_information, - eH323_UU_PDU_h323_message_body_releaseComplete, - eH323_UU_PDU_h323_message_body_facility, - eH323_UU_PDU_h323_message_body_progress, - eH323_UU_PDU_h323_message_body_empty, - eH323_UU_PDU_h323_message_body_status, - eH323_UU_PDU_h323_message_body_statusInquiry, - eH323_UU_PDU_h323_message_body_setupAcknowledge, - eH323_UU_PDU_h323_message_body_notify, - } choice; - union { - Setup_UUIE setup; - CallProceeding_UUIE callProceeding; - Connect_UUIE connect; - Alerting_UUIE alerting; - Information_UUIE information; - Facility_UUIE facility; - Progress_UUIE progress; - }; -} H323_UU_PDU_h323_message_body; - -typedef struct RequestMessage { /* CHOICE */ - enum { - eRequestMessage_nonStandard, - eRequestMessage_masterSlaveDetermination, - eRequestMessage_terminalCapabilitySet, - eRequestMessage_openLogicalChannel, - eRequestMessage_closeLogicalChannel, - eRequestMessage_requestChannelClose, - eRequestMessage_multiplexEntrySend, - eRequestMessage_requestMultiplexEntry, - eRequestMessage_requestMode, - eRequestMessage_roundTripDelayRequest, - eRequestMessage_maintenanceLoopRequest, - eRequestMessage_communicationModeRequest, - eRequestMessage_conferenceRequest, - eRequestMessage_multilinkRequest, - eRequestMessage_logicalChannelRateRequest, - } choice; - union { - OpenLogicalChannel openLogicalChannel; - }; -} RequestMessage; - -typedef struct OpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters { /* CHOICE */ - enum { - eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters_h222LogicalChannelParameters, - eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters, - } choice; - union { - H2250LogicalChannelParameters h2250LogicalChannelParameters; - }; -} OpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters; - -typedef struct OpenLogicalChannelAck_reverseLogicalChannelParameters { /* SEQUENCE */ - enum { - eOpenLogicalChannelAck_reverseLogicalChannelParameters_portNumber - = (1 << 31), - eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters - = (1 << 30), - eOpenLogicalChannelAck_reverseLogicalChannelParameters_replacementFor - = (1 << 29), - } options; - OpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters - multiplexParameters; -} OpenLogicalChannelAck_reverseLogicalChannelParameters; - -typedef struct H2250LogicalChannelAckParameters { /* SEQUENCE */ - enum { - eH2250LogicalChannelAckParameters_nonStandard = (1 << 31), - eH2250LogicalChannelAckParameters_sessionID = (1 << 30), - eH2250LogicalChannelAckParameters_mediaChannel = (1 << 29), - eH2250LogicalChannelAckParameters_mediaControlChannel = - (1 << 28), - eH2250LogicalChannelAckParameters_dynamicRTPPayloadType = - (1 << 27), - eH2250LogicalChannelAckParameters_flowControlToZero = - (1 << 26), - eH2250LogicalChannelAckParameters_portNumber = (1 << 25), - } options; - H245_TransportAddress mediaChannel; - H245_TransportAddress mediaControlChannel; -} H2250LogicalChannelAckParameters; - -typedef struct OpenLogicalChannelAck_forwardMultiplexAckParameters { /* CHOICE */ - enum { - eOpenLogicalChannelAck_forwardMultiplexAckParameters_h2250LogicalChannelAckParameters, - } choice; - union { - H2250LogicalChannelAckParameters - h2250LogicalChannelAckParameters; - }; -} OpenLogicalChannelAck_forwardMultiplexAckParameters; - -typedef struct OpenLogicalChannelAck { /* SEQUENCE */ - enum { - eOpenLogicalChannelAck_reverseLogicalChannelParameters = - (1 << 31), - eOpenLogicalChannelAck_separateStack = (1 << 30), - eOpenLogicalChannelAck_forwardMultiplexAckParameters = - (1 << 29), - eOpenLogicalChannelAck_encryptionSync = (1 << 28), - } options; - OpenLogicalChannelAck_reverseLogicalChannelParameters - reverseLogicalChannelParameters; - OpenLogicalChannelAck_forwardMultiplexAckParameters - forwardMultiplexAckParameters; -} OpenLogicalChannelAck; - -typedef struct ResponseMessage { /* CHOICE */ - enum { - eResponseMessage_nonStandard, - eResponseMessage_masterSlaveDeterminationAck, - eResponseMessage_masterSlaveDeterminationReject, - eResponseMessage_terminalCapabilitySetAck, - eResponseMessage_terminalCapabilitySetReject, - eResponseMessage_openLogicalChannelAck, - eResponseMessage_openLogicalChannelReject, - eResponseMessage_closeLogicalChannelAck, - eResponseMessage_requestChannelCloseAck, - eResponseMessage_requestChannelCloseReject, - eResponseMessage_multiplexEntrySendAck, - eResponseMessage_multiplexEntrySendReject, - eResponseMessage_requestMultiplexEntryAck, - eResponseMessage_requestMultiplexEntryReject, - eResponseMessage_requestModeAck, - eResponseMessage_requestModeReject, - eResponseMessage_roundTripDelayResponse, - eResponseMessage_maintenanceLoopAck, - eResponseMessage_maintenanceLoopReject, - eResponseMessage_communicationModeResponse, - eResponseMessage_conferenceResponse, - eResponseMessage_multilinkResponse, - eResponseMessage_logicalChannelRateAcknowledge, - eResponseMessage_logicalChannelRateReject, - } choice; - union { - OpenLogicalChannelAck openLogicalChannelAck; - }; -} ResponseMessage; - -typedef struct MultimediaSystemControlMessage { /* CHOICE */ - enum { - eMultimediaSystemControlMessage_request, - eMultimediaSystemControlMessage_response, - eMultimediaSystemControlMessage_command, - eMultimediaSystemControlMessage_indication, - } choice; - union { - RequestMessage request; - ResponseMessage response; - }; -} MultimediaSystemControlMessage; - -typedef struct H323_UU_PDU_h245Control { /* SEQUENCE OF */ - int count; - MultimediaSystemControlMessage item[4]; -} H323_UU_PDU_h245Control; - -typedef struct H323_UU_PDU { /* SEQUENCE */ - enum { - eH323_UU_PDU_nonStandardData = (1 << 31), - eH323_UU_PDU_h4501SupplementaryService = (1 << 30), - eH323_UU_PDU_h245Tunneling = (1 << 29), - eH323_UU_PDU_h245Control = (1 << 28), - eH323_UU_PDU_nonStandardControl = (1 << 27), - eH323_UU_PDU_callLinkage = (1 << 26), - eH323_UU_PDU_tunnelledSignallingMessage = (1 << 25), - eH323_UU_PDU_provisionalRespToH245Tunneling = (1 << 24), - eH323_UU_PDU_stimulusControl = (1 << 23), - eH323_UU_PDU_genericData = (1 << 22), - } options; - H323_UU_PDU_h323_message_body h323_message_body; - H323_UU_PDU_h245Control h245Control; -} H323_UU_PDU; - -typedef struct H323_UserInformation { /* SEQUENCE */ - enum { - eH323_UserInformation_user_data = (1 << 31), - } options; - H323_UU_PDU h323_uu_pdu; -} H323_UserInformation; - -typedef struct GatekeeperRequest { /* SEQUENCE */ - enum { - eGatekeeperRequest_nonStandardData = (1 << 31), - eGatekeeperRequest_gatekeeperIdentifier = (1 << 30), - eGatekeeperRequest_callServices = (1 << 29), - eGatekeeperRequest_endpointAlias = (1 << 28), - eGatekeeperRequest_alternateEndpoints = (1 << 27), - eGatekeeperRequest_tokens = (1 << 26), - eGatekeeperRequest_cryptoTokens = (1 << 25), - eGatekeeperRequest_authenticationCapability = (1 << 24), - eGatekeeperRequest_algorithmOIDs = (1 << 23), - eGatekeeperRequest_integrity = (1 << 22), - eGatekeeperRequest_integrityCheckValue = (1 << 21), - eGatekeeperRequest_supportsAltGK = (1 << 20), - eGatekeeperRequest_featureSet = (1 << 19), - eGatekeeperRequest_genericData = (1 << 18), - } options; - TransportAddress rasAddress; -} GatekeeperRequest; - -typedef struct GatekeeperConfirm { /* SEQUENCE */ - enum { - eGatekeeperConfirm_nonStandardData = (1 << 31), - eGatekeeperConfirm_gatekeeperIdentifier = (1 << 30), - eGatekeeperConfirm_alternateGatekeeper = (1 << 29), - eGatekeeperConfirm_authenticationMode = (1 << 28), - eGatekeeperConfirm_tokens = (1 << 27), - eGatekeeperConfirm_cryptoTokens = (1 << 26), - eGatekeeperConfirm_algorithmOID = (1 << 25), - eGatekeeperConfirm_integrity = (1 << 24), - eGatekeeperConfirm_integrityCheckValue = (1 << 23), - eGatekeeperConfirm_featureSet = (1 << 22), - eGatekeeperConfirm_genericData = (1 << 21), - } options; - TransportAddress rasAddress; -} GatekeeperConfirm; - -typedef struct RegistrationRequest_callSignalAddress { /* SEQUENCE OF */ - int count; - TransportAddress item[10]; -} RegistrationRequest_callSignalAddress; - -typedef struct RegistrationRequest_rasAddress { /* SEQUENCE OF */ - int count; - TransportAddress item[10]; -} RegistrationRequest_rasAddress; - -typedef struct RegistrationRequest { /* SEQUENCE */ - enum { - eRegistrationRequest_nonStandardData = (1 << 31), - eRegistrationRequest_terminalAlias = (1 << 30), - eRegistrationRequest_gatekeeperIdentifier = (1 << 29), - eRegistrationRequest_alternateEndpoints = (1 << 28), - eRegistrationRequest_timeToLive = (1 << 27), - eRegistrationRequest_tokens = (1 << 26), - eRegistrationRequest_cryptoTokens = (1 << 25), - eRegistrationRequest_integrityCheckValue = (1 << 24), - eRegistrationRequest_keepAlive = (1 << 23), - eRegistrationRequest_endpointIdentifier = (1 << 22), - eRegistrationRequest_willSupplyUUIEs = (1 << 21), - eRegistrationRequest_maintainConnection = (1 << 20), - eRegistrationRequest_alternateTransportAddresses = (1 << 19), - eRegistrationRequest_additiveRegistration = (1 << 18), - eRegistrationRequest_terminalAliasPattern = (1 << 17), - eRegistrationRequest_supportsAltGK = (1 << 16), - eRegistrationRequest_usageReportingCapability = (1 << 15), - eRegistrationRequest_multipleCalls = (1 << 14), - eRegistrationRequest_supportedH248Packages = (1 << 13), - eRegistrationRequest_callCreditCapability = (1 << 12), - eRegistrationRequest_capacityReportingCapability = (1 << 11), - eRegistrationRequest_capacity = (1 << 10), - eRegistrationRequest_featureSet = (1 << 9), - eRegistrationRequest_genericData = (1 << 8), - } options; - RegistrationRequest_callSignalAddress callSignalAddress; - RegistrationRequest_rasAddress rasAddress; - unsigned timeToLive; -} RegistrationRequest; - -typedef struct RegistrationConfirm_callSignalAddress { /* SEQUENCE OF */ - int count; - TransportAddress item[10]; -} RegistrationConfirm_callSignalAddress; - -typedef struct RegistrationConfirm { /* SEQUENCE */ - enum { - eRegistrationConfirm_nonStandardData = (1 << 31), - eRegistrationConfirm_terminalAlias = (1 << 30), - eRegistrationConfirm_gatekeeperIdentifier = (1 << 29), - eRegistrationConfirm_alternateGatekeeper = (1 << 28), - eRegistrationConfirm_timeToLive = (1 << 27), - eRegistrationConfirm_tokens = (1 << 26), - eRegistrationConfirm_cryptoTokens = (1 << 25), - eRegistrationConfirm_integrityCheckValue = (1 << 24), - eRegistrationConfirm_willRespondToIRR = (1 << 23), - eRegistrationConfirm_preGrantedARQ = (1 << 22), - eRegistrationConfirm_maintainConnection = (1 << 21), - eRegistrationConfirm_serviceControl = (1 << 20), - eRegistrationConfirm_supportsAdditiveRegistration = (1 << 19), - eRegistrationConfirm_terminalAliasPattern = (1 << 18), - eRegistrationConfirm_supportedPrefixes = (1 << 17), - eRegistrationConfirm_usageSpec = (1 << 16), - eRegistrationConfirm_featureServerAlias = (1 << 15), - eRegistrationConfirm_capacityReportingSpec = (1 << 14), - eRegistrationConfirm_featureSet = (1 << 13), - eRegistrationConfirm_genericData = (1 << 12), - } options; - RegistrationConfirm_callSignalAddress callSignalAddress; - unsigned timeToLive; -} RegistrationConfirm; - -typedef struct UnregistrationRequest_callSignalAddress { /* SEQUENCE OF */ - int count; - TransportAddress item[10]; -} UnregistrationRequest_callSignalAddress; - -typedef struct UnregistrationRequest { /* SEQUENCE */ - enum { - eUnregistrationRequest_endpointAlias = (1 << 31), - eUnregistrationRequest_nonStandardData = (1 << 30), - eUnregistrationRequest_endpointIdentifier = (1 << 29), - eUnregistrationRequest_alternateEndpoints = (1 << 28), - eUnregistrationRequest_gatekeeperIdentifier = (1 << 27), - eUnregistrationRequest_tokens = (1 << 26), - eUnregistrationRequest_cryptoTokens = (1 << 25), - eUnregistrationRequest_integrityCheckValue = (1 << 24), - eUnregistrationRequest_reason = (1 << 23), - eUnregistrationRequest_endpointAliasPattern = (1 << 22), - eUnregistrationRequest_supportedPrefixes = (1 << 21), - eUnregistrationRequest_alternateGatekeeper = (1 << 20), - eUnregistrationRequest_genericData = (1 << 19), - } options; - UnregistrationRequest_callSignalAddress callSignalAddress; -} UnregistrationRequest; - -typedef struct AdmissionRequest { /* SEQUENCE */ - enum { - eAdmissionRequest_callModel = (1 << 31), - eAdmissionRequest_destinationInfo = (1 << 30), - eAdmissionRequest_destCallSignalAddress = (1 << 29), - eAdmissionRequest_destExtraCallInfo = (1 << 28), - eAdmissionRequest_srcCallSignalAddress = (1 << 27), - eAdmissionRequest_nonStandardData = (1 << 26), - eAdmissionRequest_callServices = (1 << 25), - eAdmissionRequest_canMapAlias = (1 << 24), - eAdmissionRequest_callIdentifier = (1 << 23), - eAdmissionRequest_srcAlternatives = (1 << 22), - eAdmissionRequest_destAlternatives = (1 << 21), - eAdmissionRequest_gatekeeperIdentifier = (1 << 20), - eAdmissionRequest_tokens = (1 << 19), - eAdmissionRequest_cryptoTokens = (1 << 18), - eAdmissionRequest_integrityCheckValue = (1 << 17), - eAdmissionRequest_transportQOS = (1 << 16), - eAdmissionRequest_willSupplyUUIEs = (1 << 15), - eAdmissionRequest_callLinkage = (1 << 14), - eAdmissionRequest_gatewayDataRate = (1 << 13), - eAdmissionRequest_capacity = (1 << 12), - eAdmissionRequest_circuitInfo = (1 << 11), - eAdmissionRequest_desiredProtocols = (1 << 10), - eAdmissionRequest_desiredTunnelledProtocol = (1 << 9), - eAdmissionRequest_featureSet = (1 << 8), - eAdmissionRequest_genericData = (1 << 7), - } options; - TransportAddress destCallSignalAddress; - TransportAddress srcCallSignalAddress; -} AdmissionRequest; - -typedef struct AdmissionConfirm { /* SEQUENCE */ - enum { - eAdmissionConfirm_irrFrequency = (1 << 31), - eAdmissionConfirm_nonStandardData = (1 << 30), - eAdmissionConfirm_destinationInfo = (1 << 29), - eAdmissionConfirm_destExtraCallInfo = (1 << 28), - eAdmissionConfirm_destinationType = (1 << 27), - eAdmissionConfirm_remoteExtensionAddress = (1 << 26), - eAdmissionConfirm_alternateEndpoints = (1 << 25), - eAdmissionConfirm_tokens = (1 << 24), - eAdmissionConfirm_cryptoTokens = (1 << 23), - eAdmissionConfirm_integrityCheckValue = (1 << 22), - eAdmissionConfirm_transportQOS = (1 << 21), - eAdmissionConfirm_willRespondToIRR = (1 << 20), - eAdmissionConfirm_uuiesRequested = (1 << 19), - eAdmissionConfirm_language = (1 << 18), - eAdmissionConfirm_alternateTransportAddresses = (1 << 17), - eAdmissionConfirm_useSpecifiedTransport = (1 << 16), - eAdmissionConfirm_circuitInfo = (1 << 15), - eAdmissionConfirm_usageSpec = (1 << 14), - eAdmissionConfirm_supportedProtocols = (1 << 13), - eAdmissionConfirm_serviceControl = (1 << 12), - eAdmissionConfirm_multipleCalls = (1 << 11), - eAdmissionConfirm_featureSet = (1 << 10), - eAdmissionConfirm_genericData = (1 << 9), - } options; - TransportAddress destCallSignalAddress; -} AdmissionConfirm; - -typedef struct LocationRequest { /* SEQUENCE */ - enum { - eLocationRequest_endpointIdentifier = (1 << 31), - eLocationRequest_nonStandardData = (1 << 30), - eLocationRequest_sourceInfo = (1 << 29), - eLocationRequest_canMapAlias = (1 << 28), - eLocationRequest_gatekeeperIdentifier = (1 << 27), - eLocationRequest_tokens = (1 << 26), - eLocationRequest_cryptoTokens = (1 << 25), - eLocationRequest_integrityCheckValue = (1 << 24), - eLocationRequest_desiredProtocols = (1 << 23), - eLocationRequest_desiredTunnelledProtocol = (1 << 22), - eLocationRequest_featureSet = (1 << 21), - eLocationRequest_genericData = (1 << 20), - eLocationRequest_hopCount = (1 << 19), - eLocationRequest_circuitInfo = (1 << 18), - } options; - TransportAddress replyAddress; -} LocationRequest; - -typedef struct LocationConfirm { /* SEQUENCE */ - enum { - eLocationConfirm_nonStandardData = (1 << 31), - eLocationConfirm_destinationInfo = (1 << 30), - eLocationConfirm_destExtraCallInfo = (1 << 29), - eLocationConfirm_destinationType = (1 << 28), - eLocationConfirm_remoteExtensionAddress = (1 << 27), - eLocationConfirm_alternateEndpoints = (1 << 26), - eLocationConfirm_tokens = (1 << 25), - eLocationConfirm_cryptoTokens = (1 << 24), - eLocationConfirm_integrityCheckValue = (1 << 23), - eLocationConfirm_alternateTransportAddresses = (1 << 22), - eLocationConfirm_supportedProtocols = (1 << 21), - eLocationConfirm_multipleCalls = (1 << 20), - eLocationConfirm_featureSet = (1 << 19), - eLocationConfirm_genericData = (1 << 18), - eLocationConfirm_circuitInfo = (1 << 17), - eLocationConfirm_serviceControl = (1 << 16), - } options; - TransportAddress callSignalAddress; - TransportAddress rasAddress; -} LocationConfirm; - -typedef struct InfoRequestResponse_callSignalAddress { /* SEQUENCE OF */ - int count; - TransportAddress item[10]; -} InfoRequestResponse_callSignalAddress; - -typedef struct InfoRequestResponse { /* SEQUENCE */ - enum { - eInfoRequestResponse_nonStandardData = (1 << 31), - eInfoRequestResponse_endpointAlias = (1 << 30), - eInfoRequestResponse_perCallInfo = (1 << 29), - eInfoRequestResponse_tokens = (1 << 28), - eInfoRequestResponse_cryptoTokens = (1 << 27), - eInfoRequestResponse_integrityCheckValue = (1 << 26), - eInfoRequestResponse_needResponse = (1 << 25), - eInfoRequestResponse_capacity = (1 << 24), - eInfoRequestResponse_irrStatus = (1 << 23), - eInfoRequestResponse_unsolicited = (1 << 22), - eInfoRequestResponse_genericData = (1 << 21), - } options; - TransportAddress rasAddress; - InfoRequestResponse_callSignalAddress callSignalAddress; -} InfoRequestResponse; - -typedef struct RasMessage { /* CHOICE */ - enum { - eRasMessage_gatekeeperRequest, - eRasMessage_gatekeeperConfirm, - eRasMessage_gatekeeperReject, - eRasMessage_registrationRequest, - eRasMessage_registrationConfirm, - eRasMessage_registrationReject, - eRasMessage_unregistrationRequest, - eRasMessage_unregistrationConfirm, - eRasMessage_unregistrationReject, - eRasMessage_admissionRequest, - eRasMessage_admissionConfirm, - eRasMessage_admissionReject, - eRasMessage_bandwidthRequest, - eRasMessage_bandwidthConfirm, - eRasMessage_bandwidthReject, - eRasMessage_disengageRequest, - eRasMessage_disengageConfirm, - eRasMessage_disengageReject, - eRasMessage_locationRequest, - eRasMessage_locationConfirm, - eRasMessage_locationReject, - eRasMessage_infoRequest, - eRasMessage_infoRequestResponse, - eRasMessage_nonStandardMessage, - eRasMessage_unknownMessageResponse, - eRasMessage_requestInProgress, - eRasMessage_resourcesAvailableIndicate, - eRasMessage_resourcesAvailableConfirm, - eRasMessage_infoRequestAck, - eRasMessage_infoRequestNak, - eRasMessage_serviceControlIndication, - eRasMessage_serviceControlResponse, - } choice; - union { - GatekeeperRequest gatekeeperRequest; - GatekeeperConfirm gatekeeperConfirm; - RegistrationRequest registrationRequest; - RegistrationConfirm registrationConfirm; - UnregistrationRequest unregistrationRequest; - AdmissionRequest admissionRequest; - AdmissionConfirm admissionConfirm; - LocationRequest locationRequest; - LocationConfirm locationConfirm; - InfoRequestResponse infoRequestResponse; - }; -} RasMessage; diff --git a/net/ipv4/netfilter/ip_nat_helper_h323.c b/net/ipv4/netfilter/ip_nat_helper_h323.c index a0bc883..6f19c20 100644 --- a/net/ipv4/netfilter/ip_nat_helper_h323.c +++ b/net/ipv4/netfilter/ip_nat_helper_h323.c @@ -41,65 +41,12 @@ #include #include -#include "ip_conntrack_helper_h323_asn1.h" - #if 0 #define DEBUGP printk #else #define DEBUGP(format, args...) #endif -extern int get_h245_addr(unsigned char *data, H245_TransportAddress * addr, - u_int32_t * ip, u_int16_t * port); -extern int get_h225_addr(unsigned char *data, TransportAddress * addr, - u_int32_t * ip, u_int16_t * port); -extern void ip_conntrack_h245_expect(struct ip_conntrack *new, - struct ip_conntrack_expect *this); -extern void ip_conntrack_q931_expect(struct ip_conntrack *new, - struct ip_conntrack_expect *this); -extern int (*set_h245_addr_hook) (struct sk_buff ** pskb, - unsigned char **data, int dataoff, - H245_TransportAddress * addr, - u_int32_t ip, u_int16_t port); -extern int (*set_h225_addr_hook) (struct sk_buff ** pskb, - unsigned char **data, int dataoff, - TransportAddress * addr, - u_int32_t ip, u_int16_t port); -extern int (*set_sig_addr_hook) (struct sk_buff ** pskb, - struct ip_conntrack * ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, - TransportAddress * addr, int count); -extern int (*set_ras_addr_hook) (struct sk_buff ** pskb, - struct ip_conntrack * ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, - TransportAddress * addr, int count); -extern int (*nat_rtp_rtcp_hook) (struct sk_buff ** pskb, - struct ip_conntrack * ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, int dataoff, - H245_TransportAddress * addr, - u_int16_t port, u_int16_t rtp_port, - struct ip_conntrack_expect * rtp_exp, - struct ip_conntrack_expect * rtcp_exp); -extern int (*nat_t120_hook) (struct sk_buff ** pskb, struct ip_conntrack * ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, int dataoff, - H245_TransportAddress * addr, u_int16_t port, - struct ip_conntrack_expect * exp); -extern int (*nat_h245_hook) (struct sk_buff ** pskb, struct ip_conntrack * ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, int dataoff, - TransportAddress * addr, u_int16_t port, - struct ip_conntrack_expect * exp); -extern int (*nat_q931_hook) (struct sk_buff ** pskb, struct ip_conntrack * ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, TransportAddress * addr, - int idx, u_int16_t port, - struct ip_conntrack_expect * exp); - - /****************************************************************************/ static int set_addr(struct sk_buff **pskb, unsigned char **data, int dataoff, From olenf at ans.pl Thu Apr 6 12:34:21 2006 From: olenf at ans.pl (Krzysztof Oledzki) Date: Thu Apr 6 12:50:46 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <4434CFBF.7030208@trash.net> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> Message-ID: On Thu, 6 Apr 2006, Patrick McHardy wrote: > Harald Welte wrote: >> As indicated in Patricks mail, there's a 30 day grace period. Until >> then the original authors (if they care) or other people can take >> maintenance for individual patchlets and send us URL's to those >> repositories. We will add them to our list file, and distribute a >> 'runme' script which downloads those repositories off the net. >> >> If you want to help, I suggest to wait for those patchlets that nobody >> takes care of, and run a repository for them. > > As a side-note: anyone who decides to take maintanance for some > patchlet, please drop me a short note, so I can keep a list > of unmaintained patches. If there are no other volenteers I would like to keep following patchlets: - TARPIT - connlimit - geoip - ipp2p - time What about ROUTE, ipv4options, random, u32? Are they going to be included in mainline? >> Also, I assume that there is a lot that can be done to improve that >> patchlet-handling script, i.e. add suport for GPG signature checking and >> the like. I suggest you coordinate with Patrick on this. > > Definitely. The code is very basic, it only makes sure a patchlet > 1) doesn't overwrite anything outside of its patchlet directory > 2) can only overwrite "Repository: external" patchlets > > But doensn't do any signature verification. I'll add it today, > patches are welcome. So, this external repository will be used only by netfilter server to download patchlets? People will be still able to download complete pom-ng package? How it is better from giving access to the svn server? Best regards, Krzysztof Ol?dzki From kaber at trash.net Thu Apr 6 12:40:25 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 12:56:42 2006 Subject: The future of patch-o-matic-ng In-Reply-To: References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> Message-ID: <4434F019.3060000@trash.net> Krzysztof Oledzki wrote: > If there are no other volenteers I would like to keep following patchlets: > - TARPIT > - connlimit > - geoip > - ipp2p > - time Thanks, I've updated my list. I think some of these are actually actively maintained. If a maintainer itself offers to keep a repository, he will most likely be prefered. > What about ROUTE, ipv4options, random, u32? Are they going to be > included in mainline? ROUTE will be kept in pomng, ipv4options will be merged, random will be merged with nth and then go into the kernel (I've already started this), u32 will also go in the kernel. >>> Also, I assume that there is a lot that can be done to improve that >>> patchlet-handling script, i.e. add suport for GPG signature checking and >>> the like. I suggest you coordinate with Patrick on this. >> >> >> Definitely. The code is very basic, it only makes sure a patchlet >> 1) doesn't overwrite anything outside of its patchlet directory >> 2) can only overwrite "Repository: external" patchlets >> >> But doensn't do any signature verification. I'll add it today, >> patches are welcome. > > > So, this external repository will be used only by netfilter server to > download patchlets? People will be still able to download complete > pom-ng package? How it is better from giving access to the svn server? No, it will be used by users to download patchlets. BTW, the code is in SVN now. From beunlovable at gmail.com Thu Apr 6 12:50:05 2006 From: beunlovable at gmail.com (David Vogt) Date: Thu Apr 6 13:06:23 2006 Subject: Multiple programs for QUEUE target In-Reply-To: <20060405152409.GH20558@sunbeam.de.gnumonks.org> References: <859616420604040655h6312ac86g3c8661c29bf4c7e5@mail.gmail.com> <859616420604040702g1e74bcacr2115fb36e0e7298e@mail.gmail.com> <20060405152409.GH20558@sunbeam.de.gnumonks.org> Message-ID: <859616420604060350q379873b4j5b7e27c71958b93b@mail.gmail.com> 2006/4/5, Harald Welte : > On Tue, Apr 04, 2006 at 04:02:41PM +0200, David Vogt wrote: > Please don't use any of that old 'crap' (I'm the author, so I can call > it that). These days, you use NFQUEUE, nf_queue, nfnetlink_queue, > libnetfilter_queue, and you get up to 65535 distinct queues for > different userespace processes. Is it possible to run libnetfilter_queue and libipq (for old applications) in parallel? I did some testing and it doesn't seem to work. Thanks, David From laforge at netfilter.org Thu Apr 6 12:53:50 2006 From: laforge at netfilter.org (Harald Welte) Date: Thu Apr 6 13:10:07 2006 Subject: The future of patch-o-matic-ng In-Reply-To: References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> Message-ID: <20060406105350.GT6887@sunbeam.de.gnumonks.org> On Thu, Apr 06, 2006 at 12:34:21PM +0200, Krzysztof Oledzki wrote: > So, this external repository will be used only by netfilter server to > download patchlets? People will be still able to download complete > pom-ng package? No, users will actually only download > How it is better from giving access to the svn server? for security reasons we only do svn-over-webdav-over-https with client based certificates. Therefore, it's not very easy to handle, both on the 'user/developer' side, as well with regards to maintenance on our side. Also, using fine-grained permission control (such as giving some 30+ individual developers access to only their patchlet-subdirectories) is a configuration nightmare. Therefore, we prefer not to give svn access to people outside the core development community, webaster, etc. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060406/840ebc4d/attachment.pgp From kaber at trash.net Thu Apr 6 12:57:35 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 13:13:52 2006 Subject: Multiple programs for QUEUE target In-Reply-To: <859616420604060350q379873b4j5b7e27c71958b93b@mail.gmail.com> References: <859616420604040655h6312ac86g3c8661c29bf4c7e5@mail.gmail.com> <859616420604040702g1e74bcacr2115fb36e0e7298e@mail.gmail.com> <20060405152409.GH20558@sunbeam.de.gnumonks.org> <859616420604060350q379873b4j5b7e27c71958b93b@mail.gmail.com> Message-ID: <4434F41F.3020509@trash.net> David Vogt wrote: > 2006/4/5, Harald Welte : > >>On Tue, Apr 04, 2006 at 04:02:41PM +0200, David Vogt wrote: >>Please don't use any of that old 'crap' (I'm the author, so I can call >>it that). These days, you use NFQUEUE, nf_queue, nfnetlink_queue, >>libnetfilter_queue, and you get up to 65535 distinct queues for >>different userespace processes. > > > Is it possible to run libnetfilter_queue and libipq (for old > applications) in parallel? I did some testing and it doesn't seem to > work. Only a single queue handler can register for an address family inside the kernel, so most likely one of them is simply not receiving any packets. There is an ipq compat library for nfnetlink_queue, I'm not sure but I think you should be able to use those in parallel. From kaber at trash.net Thu Apr 6 13:02:18 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 13:18:35 2006 Subject: [PATCH 4/4] first conntrack ID must be 1 not 2 In-Reply-To: <20060401193138.GG11031@sunbeam.de.gnumonks.org> References: <43F43FA9.4000906@trash.net> <43F4426D.9060807@trash.net> <43F4DBDF.9010008@trash.net> <442B9765.2020105@ufomechanic.net> <442C81A6.3040501@trash.net> <442D78A8.4050300@trash.net> <20060401193138.GG11031@sunbeam.de.gnumonks.org> Message-ID: <4434F53A.2030302@trash.net> Harald Welte wrote: > So if there's now a majority of people who want to delete the ID: Go for > it :) Found the patch again. What it does is: - note entry of next conntrack to be dumped and keep a reference to it - when continuing, look for the conntrack and continue at it if its still there - if not, dump the entire bucket again In theory we could end up in an endless loop if the conntrack entry we're keeping the reference to is deleted everytime we want to continue dumping. It shouldn't be triggerable intentionally because of the jenkins hash though. If there are no objections I'll port it to nf_conntrack_netlink and submit it. -------------- next part -------------- diff --git a/net/ipv4/netfilter/ip_conntrack_netlink.c b/net/ipv4/netfilter/ip_conntrack_netlink.c index e0b5926..5a1769d 100644 --- a/net/ipv4/netfilter/ip_conntrack_netlink.c +++ b/net/ipv4/netfilter/ip_conntrack_netlink.c @@ -387,38 +387,52 @@ nfattr_failure: static int ctnetlink_done(struct netlink_callback *cb) { DEBUGP("entered %s\n", __FUNCTION__); + if (cb->args[1]) + ip_conntrack_put(cb->args[1]); return 0; } static int ctnetlink_dump_table(struct sk_buff *skb, struct netlink_callback *cb) { - struct ip_conntrack *ct = NULL; + struct ip_conntrack *ct; struct ip_conntrack_tuple_hash *h; struct list_head *i; - u_int32_t *id = (u_int32_t *) &cb->args[1]; DEBUGP("entered %s, last bucket=%lu id=%u\n", __FUNCTION__, cb->args[0], *id); read_lock_bh(&ip_conntrack_lock); - for (; cb->args[0] < ip_conntrack_htable_size; cb->args[0]++, *id = 0) { + for (; cb->args[0] < ip_conntrack_htable_size; cb->args[0]++) { +restart: list_for_each_prev(i, &ip_conntrack_hash[cb->args[0]]) { h = (struct ip_conntrack_tuple_hash *) i; if (DIRECTION(h) != IP_CT_DIR_ORIGINAL) continue; ct = tuplehash_to_ctrack(h); - if (ct->id <= *id) - continue; + if (cb->args[1]) { + if (ct == cb->args[1]) { + ip_conntrack_put(cb->args[1]); + cb->args[1] = NULL; + } else + continue; + } if (ctnetlink_fill_info(skb, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, IPCTNL_MSG_CT_NEW, - 1, ct) < 0) + 1, ct) < 0) { + nf_conntrack_get(&ct->ct_general); + cb->args[1] = ct; goto out; - *id = ct->id; + } + } + if (cb->args[1]) { + ip_conntrack_put(cb->args[1]); + cb->args[1] = NULL; + goto restart; } } -out: +out: read_unlock_bh(&ip_conntrack_lock); DEBUGP("leaving, last bucket=%lu id=%u\n", cb->args[0], *id); From kaber at trash.net Thu Apr 6 13:03:58 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 13:20:14 2006 Subject: [PATCH] Re: Setting skb->priority with libnetfilter_queue (patch really attached this time) In-Reply-To: <44285BC2.3020602@info-link.net> References: <44283F9F.4010206@info-link.net> <44285B64.1000004@info-link.net> <44285BC2.3020602@info-link.net> Message-ID: <4434F59E.6060000@trash.net> Brad Fisher wrote: > Sorry - I got trigger happy and sent without attaching the patch... > Patches should be attached now. > -Brad > > Brad Fisher wrote: > >> In case anyone is interested, I have written a couple of small patches >> to accomplish what I desired. It adds three new functions to >> libnetfilter_queue: >> >> /* Set both mark and priority */ >> int nfq_set_verdict_mark_priority(struct nfq_q_handle *qh, u_int32_t >> id, u_int32_t verdict, u_int32_t mark, u_int32_t priority, >> u_int32_t data_len, unsigned char *buf) >> >> /* Sets priority, but leaves mark unchanged */ >> int nfq_set_verdict_priority(struct nfq_q_handle *qh, u_int32_t id, >> u_int32_t verdict, u_int32_t priority, >> u_int32_t data_len, unsigned char *buf) >> >> /* Get current skb->priority value */ >> u_int32_t nfq_get_priority(struct nfq_data *nfad) I think allowing to set skb->priority makes sense, but I'm not entirely happy with the 2^n nfq_set_verdict_* combinations. It would be nicer if we had some struct representing the packet and some functions to change nfmark, priority etc. Then we could just do nfq_set_verdict(qh, pkt, verdict). From olenf at ans.pl Thu Apr 6 13:42:34 2006 From: olenf at ans.pl (Krzysztof Oledzki) Date: Thu Apr 6 13:59:18 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <4434F019.3060000@trash.net> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> <4434F019.3060000@trash.net> Message-ID: On Thu, 6 Apr 2006, Patrick McHardy wrote: > Krzysztof Oledzki wrote: >> If there are no other volenteers I would like to keep following patchlets: >> - TARPIT >> - connlimit >> - geoip >> - ipp2p >> - time > > Thanks, I've updated my list. I think some of these are actually > actively maintained. If a maintainer itself offers to keep a > repository, he will most likely be prefered. Sure! I volunteered as I have in my queue ready-for-send patches for connlimit and geoip and have been sending patches for ipp2p/time (and some other patchlets) in pom-ng for some time. But of course original authors are defintelly preferred. Best regards, Krzysztof Ol?dzki From c-d.hailfinger.devel.2006 at gmx.net Thu Apr 6 15:14:38 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu Apr 6 15:30:58 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <20060406105350.GT6887@sunbeam.de.gnumonks.org> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> <20060406105350.GT6887@sunbeam.de.gnumonks.org> Message-ID: <4435143E.3030700@gmx.net> Harald Welte schrieb: > On Thu, Apr 06, 2006 at 12:34:21PM +0200, Krzysztof Oledzki wrote: > >>So, this external repository will be used only by netfilter server to >>download patchlets? People will be still able to download complete >>pom-ng package? > > No, users will actually only download And exactly that's the problem with the proposed change. The value of pom-ng was not a central list of patches (I can always get that from the netfilter web site), but the packaged collection. So if you really don't want to package patches from other sources anymore, please be honest and call the new package pom-coreteam or something like that. Regards, Carl-Daniel -- http://www.hailfinger.org/ From bof at bof.de Thu Apr 6 15:19:39 2006 From: bof at bof.de (Patrick Schaaf) Date: Thu Apr 6 15:35:58 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <4435143E.3030700@gmx.net> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> <20060406105350.GT6887@sunbeam.de.gnumonks.org> <4435143E.3030700@gmx.net> Message-ID: <20060406131939.GA19216@oknodo.bof.de> > So if you really don't want to package patches from other sources > anymore, please be honest and call the new package pom-coreteam > or something like that. What has honesty to do with naming things? As far as I can see, the core team is honestly telling us what they are going to do, and why. Happy naming games don't enter into this feeling of mine. best regards Patrick From c-d.hailfinger.devel.2006 at gmx.net Thu Apr 6 15:42:13 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu Apr 6 15:58:30 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <20060406131939.GA19216@oknodo.bof.de> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> <20060406105350.GT6887@sunbeam.de.gnumonks.org> <4435143E.3030700@gmx.net> <20060406131939.GA19216@oknodo.bof.de> Message-ID: <44351AB5.9090103@gmx.net> Patrick Schaaf schrieb: >>So if you really don't want to package patches from other sources >>anymore, please be honest and call the new package pom-coreteam >>or something like that. > > What has honesty to do with naming things? Sorry, english is my second language. Maybe "broken expectation" would be a better description. > As far as I can see, the core team is honestly telling us what > they are going to do, and why. Happy naming games don't enter > into this feeling of mine. Yes. I always treated pom-ng as patch collection which is usable offline. With the proposed change, it becomes a mix of patch collection and patch list. Packaging a patch list doesn't make sense, but packaging a link to a package list makes sense. If I already have to download patches on the machine where I want to apply them (no offline capability anymore), I can as well get the patch list from a link on the netfilter.org site. And if the linux machine has no network, I can simply download the packages via the link on the netfilter.org site on another machine. Changing the name to pom-coreteam would give others the chance to provide a package with the same features and same name as the current pom-ng. Regards, Carl-Daniel -- http://www.hailfinger.org/ From kaber at trash.net Thu Apr 6 16:23:36 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 16:42:25 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <4435143E.3030700@gmx.net> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> <20060406105350.GT6887@sunbeam.de.gnumonks.org> <4435143E.3030700@gmx.net> Message-ID: <44352468.5010505@trash.net> Carl-Daniel Hailfinger wrote: > Harald Welte schrieb: > >>On Thu, Apr 06, 2006 at 12:34:21PM +0200, Krzysztof Oledzki wrote: >> >> >>>So, this external repository will be used only by netfilter server to >>>download patchlets? People will be still able to download complete >>>pom-ng package? >> >>No, users will actually only download > > > And exactly that's the problem with the proposed change. The value > of pom-ng was not a central list of patches (I can always get that > from the netfilter web site), but the packaged collection. You can always do "runme --download" and you have the packaged collection. We could also start doing two releases, one with only patches maintained by the netfilter team and one with all the patches. > So if you really don't want to package patches from other sources > anymore, please be honest and call the new package pom-coreteam > or something like that. Whats the point? We _do_ include other patches, just not every random crap. From kaber at trash.net Thu Apr 6 16:30:32 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 16:49:21 2006 Subject: The future of patch-o-matic-ng In-Reply-To: <44351AB5.9090103@gmx.net> References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> <4434CFBF.7030208@trash.net> <20060406105350.GT6887@sunbeam.de.gnumonks.org> <4435143E.3030700@gmx.net> <20060406131939.GA19216@oknodo.bof.de> <44351AB5.9090103@gmx.net> Message-ID: <44352608.7000509@trash.net> Carl-Daniel Hailfinger wrote: > Yes. I always treated pom-ng as patch collection which is usable > offline. With the proposed change, it becomes a mix of patch > collection and patch list. Packaging a patch list doesn't make > sense, but packaging a link to a package list makes sense. If > I already have to download patches on the machine where I want > to apply them (no offline capability anymore), I can as well > get the patch list from a link on the netfilter.org site. > And if the linux machine has no network, I can simply download > the packages via the link on the netfilter.org site on another > machine. > > Changing the name to pom-coreteam would give others the chance > to provide a package with the same features and same name as > the current pom-ng. I honestly don't care about the name at all, but I don't really see the point. We're pushing the good stuff to the kernel, which should benefit everyone. Old, broken and obscure patches are moved out, as are patches that are not ready for mainline where we don't have enough interest in getting them ready ourselves. You are of course welcome to work on these patches to get them mergable. Ideally we will just obsolete pom. From kaber at trash.net Thu Apr 6 16:31:57 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 16:50:43 2006 Subject: The future of patch-o-matic-ng In-Reply-To: References: <20060405152628.GI20558@sunbeam.de.gnumonks.org> <20060406073514.GE6887@sunbeam.de.gnumonks.org> Message-ID: <4435265D.4080603@trash.net> Grzegorz Janoszka wrote: > On Thu, 6 Apr 2006, Harald Welte wrote: > >> As indicated in Patricks mail, there's a 30 day grace period. Until >> then the original authors (if they care) or other people can take >> maintenance for individual patchlets and send us URL's to those >> repositories. We will add them to our list file, and distribute a >> 'runme' script which downloads those repositories off the net. >> If you want to help, I suggest to wait for those patchlets that nobody >> takes care of, and run a repository for them. > > > I want to maintain my target IPMARK. A can take care of some other > targets. At this moment I use IPMARK, nth, random and connlimit. The > esiest for me would be to take care of a target/match I know and I use. Thanks, I've updated my list for IPMARK. nth and random will be merged, so this just leaves connlimit. Shall I add you for this as well? From jones at ingate.com Thu Apr 6 17:42:27 2006 From: jones at ingate.com (Jones Desougi) Date: Thu Apr 6 17:59:03 2006 Subject: [NETFILTER 01/12]: Add helper functions for mass hook registration/unregistration In-Reply-To: <20060406100453.17409.47998.sendpatchset@localhost.localdomain> (message from Patrick McHardy on Thu, 6 Apr 2006 12:04:53 +0200 (MEST)) References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100453.17409.47998.sendpatchset@localhost.localdomain> Message-ID: <200604061542.k36FgRVL032443@usagi.ingate.se> > +err: > + if (i > 0) > + nf_unregister_hooks(reg, i - i); ^^^^^ > + return err; > +} That should make it a nice noop. :-) Change the line to: + nf_unregister_hooks(reg, i); /Jones From laforge at netfilter.org Thu Apr 6 15:13:06 2006 From: laforge at netfilter.org (Harald Welte) Date: Thu Apr 6 18:11:53 2006 Subject: Multiple programs for QUEUE target In-Reply-To: <859616420604060350q379873b4j5b7e27c71958b93b@mail.gmail.com> References: <859616420604040655h6312ac86g3c8661c29bf4c7e5@mail.gmail.com> <859616420604040702g1e74bcacr2115fb36e0e7298e@mail.gmail.com> <20060405152409.GH20558@sunbeam.de.gnumonks.org> <859616420604060350q379873b4j5b7e27c71958b93b@mail.gmail.com> Message-ID: <20060406131306.GS20558@sunbeam.de.gnumonks.org> On Thu, Apr 06, 2006 at 12:50:05PM +0200, David Vogt wrote: > 2006/4/5, Harald Welte : > > On Tue, Apr 04, 2006 at 04:02:41PM +0200, David Vogt wrote: > > Please don't use any of that old 'crap' (I'm the author, so I can call > > it that). These days, you use NFQUEUE, nf_queue, nfnetlink_queue, > > libnetfilter_queue, and you get up to 65535 distinct queues for > > different userespace processes. > > Is it possible to run libnetfilter_queue and libipq (for old > applications) in parallel? I did some testing and it doesn't seem to > work. you can run the libraries in parallel, but not the kernel code. Why would you want to do that anyway? libnetfilter_queue provides a backwards compatibility API for libipq apps. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060406/d5e9c3de/attachment.pgp From kaber at trash.net Thu Apr 6 18:10:02 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 18:26:21 2006 Subject: [NETFILTER 01/12]: Add helper functions for mass hook registration/unregistration In-Reply-To: <200604061542.k36FgRVL032443@usagi.ingate.se> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100453.17409.47998.sendpatchset@localhost.localdomain> <200604061542.k36FgRVL032443@usagi.ingate.se> Message-ID: <44353D5A.2040301@trash.net> Jones Desougi wrote: >>+err: >>+ if (i > 0) >>+ nf_unregister_hooks(reg, i - i); > > ^^^^^ > >>+ return err; >>+} > > > That should make it a nice noop. :-) > Change the line to: > + nf_unregister_hooks(reg, i); One typo and one thinko, good catch. I wonder why it didn't crash in my tests, I did try unloading and reloading. Corrected patch attached. -------------- next part -------------- [NETFILTER]: Add helper functions for mass hook registration/unregistration Signed-off-by: Patrick McHardy --- commit 3bf0d209e539917efcc5286b8f1cab2856ebdd49 tree 4c5840cf32ee69cc6138534d24c4d43a23fad557 parent 32a976a8703b098e898a9a13f9ddcabbf654e7d8 author Patrick McHardy Thu, 06 Apr 2006 11:32:05 +0200 committer Patrick McHardy Thu, 06 Apr 2006 11:32:05 +0200 include/linux/netfilter.h | 2 ++ net/netfilter/core.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 0 deletions(-) diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h index 412e52c..5aa9316 100644 --- a/include/linux/netfilter.h +++ b/include/linux/netfilter.h @@ -110,6 +110,8 @@ struct nf_info /* Function to register/unregister hook points. */ int nf_register_hook(struct nf_hook_ops *reg); void nf_unregister_hook(struct nf_hook_ops *reg); +int nf_register_hooks(struct nf_hook_ops *reg, unsigned int n); +void nf_unregister_hooks(struct nf_hook_ops *reg, unsigned int n); /* Functions to register get/setsockopt ranges (non-inclusive). You need to check permissions yourself! */ diff --git a/net/netfilter/core.c b/net/netfilter/core.c index 1ceb1a6..5c7143e 100644 --- a/net/netfilter/core.c +++ b/net/netfilter/core.c @@ -63,6 +63,34 @@ void nf_unregister_hook(struct nf_hook_o } EXPORT_SYMBOL(nf_unregister_hook); +int nf_register_hooks(struct nf_hook_ops *reg, unsigned int n) +{ + unsigned int i; + int err = 0; + + for (i = 0; i < n; i++) { + err = nf_register_hook(®[i]); + if (err) + goto err; + } + return err; + +err: + if (i > 0) + nf_unregister_hooks(reg, i); + return err; +} +EXPORT_SYMBOL(nf_register_hooks); + +void nf_unregister_hooks(struct nf_hook_ops *reg, unsigned int n) +{ + unsigned int i; + + for (i = 0; i < n; i++) + nf_unregister_hook(®[i]); +} +EXPORT_SYMBOL(nf_unregister_hooks); + unsigned int nf_iterate(struct list_head *head, struct sk_buff **skb, int hook, From kaber at trash.net Thu Apr 6 19:53:30 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Apr 6 20:12:15 2006 Subject: nth, random and fuzzy match Message-ID: <4435559A.60904@trash.net> Also following the decisions from the netfilter workshop, I've started merging nth and random into a new "statistic" match. I won't merge fuzzy since it seems to obscure and complex and I don't see what it offers beyond nth + random. The current nth match optionally uses shared state for the counters (which as we know isn't pretty with the current iptables userspace interface) and has a compile-time limit on the number of shared counters. I don't see the need for this shared state, I think everything expressable today should also be expressable using just per-match state. So my questions to the nth users: is anyone using the nth match in a way that can't be done by just matching on every nth packet with an optional starting point? From davem at davemloft.net Thu Apr 6 23:11:43 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:28:14 2006 Subject: [NETFILTER 01/12]: Add helper functions for mass hook registration/unregistration In-Reply-To: <44353D5A.2040301@trash.net> References: <20060406100453.17409.47998.sendpatchset@localhost.localdomain> <200604061542.k36FgRVL032443@usagi.ingate.se> <44353D5A.2040301@trash.net> Message-ID: <20060406.141143.33653553.davem@davemloft.net> From: Patrick McHardy Date: Thu, 06 Apr 2006 18:10:02 +0200 > Corrected patch attached. Applied, thanks. From davem at davemloft.net Thu Apr 6 23:12:01 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:28:19 2006 Subject: [NETFILTER 02/12]: Clean up hook registration In-Reply-To: <20060406100455.17409.91188.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100455.17409.91188.sendpatchset@localhost.localdomain> Message-ID: <20060406.141201.66577631.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:04:55 +0200 (MEST) > [NETFILTER]: Clean up hook registration > > Clean up hook registration by makeing use of the new mass registration and > unregistration helpers. > > Signed-off-by: Patrick McHardy Nice cleanup, applied. Thanks. From davem at davemloft.net Thu Apr 6 23:13:09 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:29:31 2006 Subject: [NETFILTER 03/12]: Fix section mismatch warnings In-Reply-To: <20060406100456.17409.89515.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100456.17409.89515.sendpatchset@localhost.localdomain> Message-ID: <20060406.141309.51862771.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:04:56 +0200 (MEST) > [NETFILTER]: Fix section mismatch warnings > > Fix section mismatch warnings caused by netfilter's init_or_cleanup > functions used in many places by splitting the init from the cleanup > parts. > > Signed-off-by: Patrick McHardy Applied, but lots of trailing whitespace I had to clean up before applying. Please test your patches with: git apply --check --whitespace=error-all $1 Thanks. From davem at davemloft.net Thu Apr 6 23:13:51 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:30:15 2006 Subject: [NETFILTER 04/12]: H.323 helper: move some function prototypes to ip_conntrack_h323.h In-Reply-To: <20060406100458.17409.70510.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100458.17409.70510.sendpatchset@localhost.localdomain> Message-ID: <20060406.141351.22547966.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:04:58 +0200 (MEST) > [NETFILTER]: H.323 helper: move some function prototypes to ip_conntrack_h323.h > > Move prototypes of NAT callbacks to ip_conntrack_h323.h. Because the use of > typedefs as arguments, some header files need to be moved as well. > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied, thanks. From davem at davemloft.net Thu Apr 6 23:14:21 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:30:39 2006 Subject: [NETFILTER 05/12]: H.323 helper: change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL In-Reply-To: <20060406100500.17409.42955.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100500.17409.42955.sendpatchset@localhost.localdomain> Message-ID: <20060406.141421.89742698.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:00 +0200 (MEST) > [NETFILTER]: H.323 helper: change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied, thanks. From davem at davemloft.net Thu Apr 6 23:15:09 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:31:31 2006 Subject: [NETFILTER 06/12]: H.323 helper: make get_h245_addr() static In-Reply-To: <20060406100501.17409.55970.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100501.17409.55970.sendpatchset@localhost.localdomain> Message-ID: <20060406.141509.12741506.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:01 +0200 (MEST) > [NETFILTER]: H.323 helper: make get_h245_addr() static > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied, thanks. From davem at davemloft.net Thu Apr 6 23:15:44 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:32:07 2006 Subject: [NETFILTER 07/12]: H.323 helper: add parameter 'default_rrq_ttl' In-Reply-To: <20060406100502.17409.1181.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100502.17409.1181.sendpatchset@localhost.localdomain> Message-ID: <20060406.141544.92069339.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:03 +0200 (MEST) > [NETFILTER]: H.323 helper: add parameter 'default_rrq_ttl' > > default_rrq_ttl is used when no TTL is included in the RRQ. > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied, thanks. From davem at davemloft.net Thu Apr 6 23:17:05 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:33:27 2006 Subject: [NETFILTER 08/12]: H.323 helper: update Changelog In-Reply-To: <20060406100504.17409.80683.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100504.17409.80683.sendpatchset@localhost.localdomain> Message-ID: <20060406.141705.22962861.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:04 +0200 (MEST) > [NETFILTER]: H.323 helper: update Changelog > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy This doesn't make any sense. We have source revision control for keeping this kind of information around, so adding it to the source file is unnecessary duplication. I'm not applying this, sorry. From davem at davemloft.net Thu Apr 6 23:17:38 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:34:00 2006 Subject: [NETFILTER 09/12]: Fix IP_NF_CONNTRACK_NETLINK dependency In-Reply-To: <20060406100505.17409.24939.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100505.17409.24939.sendpatchset@localhost.localdomain> Message-ID: <20060406.141738.92396272.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:05 +0200 (MEST) > [NETFILTER]: Fix IP_NF_CONNTRACK_NETLINK dependency > > When NAT is built as a module, ip_conntrack_netlink can not be linked > statically. > > Signed-off-by: Patrick McHardy Applied, thanks. From davem at davemloft.net Thu Apr 6 23:18:19 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:34:43 2006 Subject: [NETFILTER 10/12]: Introduce infrastructure for address family specific operations In-Reply-To: <20060406100506.17409.27277.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100506.17409.27277.sendpatchset@localhost.localdomain> Message-ID: <20060406.141819.98488166.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:07 +0200 (MEST) > [NETFILTER]: Introduce infrastructure for address family specific operations > > Change the queue rerouter intrastructure to a generic usable infrastructure > for address family specific operations as a base for some cleanups. > > Signed-off-by: Patrick McHardy Applied, thanks. From davem at davemloft.net Thu Apr 6 23:18:52 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:35:10 2006 Subject: [NETFILTER 11/12]: Add address family specific checksum helpers In-Reply-To: <20060406100508.17409.68682.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100508.17409.68682.sendpatchset@localhost.localdomain> Message-ID: <20060406.141852.98287210.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:08 +0200 (MEST) > [NETFILTER]: Add address family specific checksum helpers > > Add checksum operation which takes care of verifying the checksum and > dealing with HW checksum errors and avoids multiple checksum operations > by setting ip_summed to CHECKSUM_UNNECESSARY after successful verification. > > Signed-off-by: Patrick McHardy Applied, thanks. From davem at davemloft.net Thu Apr 6 23:19:45 2006 From: davem at davemloft.net (David S. Miller) Date: Thu Apr 6 23:36:08 2006 Subject: [NETFILTER 12/12]: Convert conntrack/ipt_REJECT to new checksumming functions In-Reply-To: <20060406100509.17409.82693.sendpatchset@localhost.localdomain> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100509.17409.82693.sendpatchset@localhost.localdomain> Message-ID: <20060406.141945.06115674.davem@davemloft.net> From: Patrick McHardy Date: Thu, 6 Apr 2006 12:05:09 +0200 (MEST) > [NETFILTER]: Convert conntrack/ipt_REJECT to new checksumming functions > > Besides removing lots of duplicate code, all converted users benefit > from improved HW checksum error handling. Tested with and without > HW checksums in almost all combinations. > > Signed-off-by: Patrick McHardy Also applied, thanks a lot Patrick. From kaber at trash.net Fri Apr 7 00:36:21 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Apr 7 00:52:45 2006 Subject: [NETFILTER 08/12]: H.323 helper: update Changelog In-Reply-To: <20060406.141705.22962861.davem@davemloft.net> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100504.17409.80683.sendpatchset@localhost.localdomain> <20060406.141705.22962861.davem@davemloft.net> Message-ID: <443597E5.40907@trash.net> David S. Miller wrote: > From: Patrick McHardy > Date: Thu, 6 Apr 2006 12:05:04 +0200 (MEST) > > >>[NETFILTER]: H.323 helper: update Changelog >> >>Signed-off-by: Jing Min Zhao >>Signed-off-by: Patrick McHardy > > > This doesn't make any sense. We have source revision control > for keeping this kind of information around, so adding it to > the source file is unnecessary duplication. > > I'm not applying this, sorry. Fine with me, I already suggested to Jing Min to remove the changelogs. Just tried to be polite by letting the decision up to him :) From kaber at trash.net Fri Apr 7 00:42:24 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Apr 7 00:58:44 2006 Subject: [NETFILTER 03/12]: Fix section mismatch warnings In-Reply-To: <20060406.141309.51862771.davem@davemloft.net> References: <20060406100452.17409.37120.sendpatchset@localhost.localdomain> <20060406100456.17409.89515.sendpatchset@localhost.localdomain> <20060406.141309.51862771.davem@davemloft.net> Message-ID: <44359950.7080805@trash.net> David S. Miller wrote: > From: Patrick McHardy > Date: Thu, 6 Apr 2006 12:04:56 +0200 (MEST) > > >>[NETFILTER]: Fix section mismatch warnings >> >>Fix section mismatch warnings caused by netfilter's init_or_cleanup >>functions used in many places by splitting the init from the cleanup >>parts. >> >>Signed-off-by: Patrick McHardy > > > Applied, but lots of trailing whitespace I had to clean up > before applying. Please test your patches with: > > git apply --check --whitespace=error-all $1 Sorry, I know you already mentioned this. I already had the feeling something is wrong with my whitespace-stripping regexes recently, but didn't investigate. Most of my scripts need a rework anyway, I'll make sure to fix this before submitting the next batch. From kaber at trash.net Fri Apr 7 01:13:13 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Apr 7 01:29:33 2006 Subject: [NETFILTER]: H.323 helper: remove changelog Message-ID: <4435A089.4040602@trash.net> Since we have the git history now, remove the changelogs from the H.323 helper. -------------- next part -------------- [NETFILTER]: H.323 helper: remove changelog Signed-off-by: Patrick McHardy --- commit 4a7986fa34c9eed31b2f7df81a59fe7a282f689d tree 5df1f9c86ed575131439d866ad240464816024b1 parent f29b83bf3ca68ea545b7cf6d25f0ababe109b8a9 author Patrick McHardy Fri, 07 Apr 2006 01:04:53 +0200 committer Patrick McHardy Fri, 07 Apr 2006 01:04:53 +0200 net/ipv4/netfilter/ip_conntrack_helper_h323.c | 31 ------------------------- net/ipv4/netfilter/ip_nat_helper_h323.c | 18 --------------- 2 files changed, 0 insertions(+), 49 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c index dccc6c3..2c2fb70 100644 --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c @@ -9,37 +9,6 @@ * Jozsef Kadlecsik * * For more information, please see http://nath323.sourceforge.net/ - * - * Changes: - * 2006-02-01 - initial version 0.1 - * - * 2006-02-20 - version 0.2 - * 1. Changed source format to follow kernel conventions - * 2. Deleted some unnecessary structures - * 3. Minor fixes - * - * 2006-03-10 - version 0.3 - * 1. Added support for multiple TPKTs in one packet (suggested by - * Patrick McHardy) - * 2. Avoid excessive stack usage (based on Patrick McHardy's patch) - * 3. Added support for non-linear skb (based on Patrick McHardy's patch) - * 4. Fixed missing H.245 module owner (Patrick McHardy) - * 5. Avoid long RAS expectation chains (Patrick McHardy) - * 6. Fixed incorrect __exit attribute (Patrick McHardy) - * 7. Eliminated unnecessary return code - * 8. Fixed incorrect use of NAT data from conntrack code (suggested by - * Patrick McHardy) - * 9. Fixed TTL calculation error in RCF - * 10. Added TTL support in RRQ - * 11. Better support for separate TPKT header and data - * - * 2006-03-15 - version 0.4 - * 1. Added support for T.120 channels - * 2. Added parameter gkrouted_only (suggested by Patrick McHardy) - * 3. Splitted ASN.1 code and data (suggested by Patrick McHardy) - * 4. Sort ASN.1 data to avoid forwarding declarations (suggested by - * Patrick McHardy) - * 5. Reset next TPKT data length in get_tpkt_data() */ #include diff --git a/net/ipv4/netfilter/ip_nat_helper_h323.c b/net/ipv4/netfilter/ip_nat_helper_h323.c index 6f19c20..d45663d 100644 --- a/net/ipv4/netfilter/ip_nat_helper_h323.c +++ b/net/ipv4/netfilter/ip_nat_helper_h323.c @@ -7,24 +7,6 @@ * * Based on the 'brute force' H.323 NAT module by * Jozsef Kadlecsik - * - * Changes: - * 2006-02-01 - initial version 0.1 - * - * 2006-02-20 - version 0.2 - * 1. Changed source format to follow kernel conventions - * 2. Deleted some unnecessary structures - * 3. Minor fixes - * - * 2006-03-10 - version 0.3 - * 1. Added support for multiple TPKTs in one packet (suggested by - * Patrick McHardy) - * 2. Added support for non-linear skb (based on Patrick McHardy's patch) - * 3. Eliminated unnecessary return code - * - * 2006-03-15 - version 0.4 - * 1. Added support for T.120 channels - * 2. Added parameter gkrouted_only (suggested by Patrick McHardy) */ #include From davem at davemloft.net Fri Apr 7 01:18:31 2006 From: davem at davemloft.net (David S. Miller) Date: Fri Apr 7 01:37:08 2006 Subject: [NETFILTER]: H.323 helper: remove changelog In-Reply-To: <4435A089.4040602@trash.net> References: <4435A089.4040602@trash.net> Message-ID: <20060406.161831.104210982.davem@davemloft.net> From: Patrick McHardy Date: Fri, 07 Apr 2006 01:13:13 +0200 > Since we have the git history now, remove the changelogs from > the H.323 helper. Applied, thanks a lot Patrick. From yasuyuki.kozakai at toshiba.co.jp Fri Apr 7 10:59:43 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 7 11:16:23 2006 Subject: [PATCH] nf_conntrack: Fix module refcount dropping too far Message-ID: <200604070859.k378xiZ3009767@toshiba.co.jp> If nf_ct_l3proto_find_get() fails to get the refcount of nf_ct_l3proto_generic, nf_ct_l3proto_put() will drop the refcount too far. Only nf_ct_l3proto_generic has this problem. This fix is missing synchronization with ip_conntrack at the last minutes, but it's not critical, I think. -- Yasuyuki Kozakai -------------- next part -------------- [NETFILTER] nf_conntrack: Fix module refcount dropping too far If nf_ct_l3proto_find_get() fails to get the refcount of nf_ct_l3proto_generic, nf_ct_l3proto_put() will drop the refcount too far. This gets rid of '.me = THIS_MODULE' of nf_ct_l3proto_generic so that nf_ct_l3proto_find_get() doesn't try to get refcount of it. It's OK because its symbol is usable until nf_conntrack.ko is unloaded. This also kills unnecessary NULL pointer check as well. __nf_ct_proto_find() allways returns non-NULL pointer. Signed-off-by: Yasuyuki Kozakai --- commit e2a1cbe4dda205181d6206df84fe3eb22ec85273 tree 01324536d3cf7d405dfddbb954ea155bed8a64af parent a8b9aa85685a7f5c5841dfc4c5772d453fbf5776 author Yasuyuki Kozakai Fri, 07 Apr 2006 14:54:25 +0900 committer Yasuyuki Kozakai Fri, 07 Apr 2006 14:54:25 +0900 net/netfilter/nf_conntrack_core.c | 12 ++++-------- net/netfilter/nf_conntrack_l3proto_generic.c | 1 - 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 56389c8..54bdc08 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -208,10 +208,8 @@ nf_ct_proto_find_get(u_int16_t l3proto, preempt_disable(); p = __nf_ct_proto_find(l3proto, protocol); - if (p) { - if (!try_module_get(p->me)) - p = &nf_conntrack_generic_protocol; - } + if (!try_module_get(p->me)) + p = &nf_conntrack_generic_protocol; preempt_enable(); return p; @@ -229,10 +227,8 @@ nf_ct_l3proto_find_get(u_int16_t l3proto preempt_disable(); p = __nf_ct_l3proto_find(l3proto); - if (p) { - if (!try_module_get(p->me)) - p = &nf_conntrack_generic_l3proto; - } + if (!try_module_get(p->me)) + p = &nf_conntrack_generic_l3proto; preempt_enable(); return p; diff --git a/net/netfilter/nf_conntrack_l3proto_generic.c b/net/netfilter/nf_conntrack_l3proto_generic.c index 7de4f06..3fc58e4 100644 --- a/net/netfilter/nf_conntrack_l3proto_generic.c +++ b/net/netfilter/nf_conntrack_l3proto_generic.c @@ -94,5 +94,4 @@ struct nf_conntrack_l3proto nf_conntrack .print_conntrack = generic_print_conntrack, .prepare = generic_prepare, .get_features = generic_get_features, - .me = THIS_MODULE, }; From yasuyuki.kozakai at toshiba.co.jp Fri Apr 7 13:30:11 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 7 13:46:40 2006 Subject: [PATCH IP{,6}TABLES 0/4] fix loading icmpv6 module and minor changes Message-ID: <200604071130.k37BUBa3009024@toshiba.co.jp> Hi, One patch fixes unusable icmpv6 because ip6tables doesn't try to load libip6t_icmpv6.so. Others are minor fixes/cleanup in ip{,6}tables. If no objection/miss, I'll commit them next weekend. Regards, -- Yasuyuki Kozakai From yasuyuki.kozakai at toshiba.co.jp Fri Apr 7 13:31:01 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 7 13:47:34 2006 Subject: [PATCH 1/4] fix loading shared library of ICMPv6 match In-Reply-To: <200603290725.k2T7PRIa020651@toshiba.co.jp> Message-ID: <200604071131.k37BV2CJ025099@toshiba.co.jp> From: Yasuyuki KOZAKAI Date: Wed, 29 Mar 2006 16:25:27 +0900 (JST) > From: "Daniel De Graaf" > Date: Sun, 26 Mar 2006 22:19:27 -0600 > > > libip6t_icmpv6.c registers a match called "icmp6", which means that > > ip6tables -vL and ip6tables-save cannot output the match correctly. > > There are 2 solutions. > > 1. just rename libip6t_icmpv6.c to libip6t_icmp6.c. This can > conform names of internal structure, library and kernel module. > 2. apply attached patch to fix find_match() so that ip6tables can > load libip6t_icmpv6.so. > > I like 1 but I'm not sure we can do it. Anyone knows any historical > problem about it ? No problem ? OK, then I take 1. -------------- next part -------------- [IP6TABLES] fix loading shared library of ICMPv6 match The current ip6tables tries to load libip6t_icmp6.so when user types 'ip6tables -p icmpv6 ...' or 'ip6tables ... -m icmpv6' ...', and it fails. This patch renames libip6t_icmpv6.c to libip6t_icmp6.c so that ip6tables can load it. Now kernel module and user library has same name 'icmp6'. It can reduce confusion about name mismatch. That's why I renamed it instead of reverting change in find_match() which brought this bug. This patch keeps compatibiity and we can use '-p icmpv6', '-p ipv6-icmpv6', '-m icmpv6', '-m ipv6-icmpv6', and '-m icmp6', as ever. --- commit f7eed26853dda6a51d70221f5c9ef0fac60f73a7 tree b064a28c63406f4ec54762731ad32a7a68234ae7 parent c94b52d4b6fff1bfc2da3e192b39e0f45cd12750 author Yasuyuki Kozakai Thu, 06 Apr 2006 22:18:27 +0900 committer Yasuyuki Kozakai Thu, 06 Apr 2006 22:18:27 +0900 extensions/Makefile | 2 extensions/libip6t_icmp6.c | 272 +++++++++++++++++++++++++++++++++++++++++ extensions/libip6t_icmp6.man | 14 ++ extensions/libip6t_icmpv6.c | 272 ----------------------------------------- extensions/libip6t_icmpv6.man | 14 -- 5 files changed, 287 insertions(+), 287 deletions(-) diff --git a/extensions/Makefile b/extensions/Makefile index 7164e1d..af051f8 100644 --- a/extensions/Makefile +++ b/extensions/Makefile @@ -6,7 +6,7 @@ # package (HW) # PF_EXT_SLIB:=ah addrtype comment connlimit connmark conntrack dscp ecn esp hashlimit helper icmp iprange length limit mac mark multiport owner physdev pkttype policy realm rpc sctp standard state tcp tcpmss tos ttl udp unclean CLASSIFY CONNMARK DNAT DSCP ECN LOG MARK MASQUERADE MIRROR NETMAP NFQUEUE NOTRACK REDIRECT REJECT SAME SNAT TARPIT TCPMSS TOS TRACE TTL ULOG -PF6_EXT_SLIB:=connmark eui64 hl icmpv6 length limit mac mark multiport owner physdev policy standard state tcp udp CONNMARK HL LOG NFQUEUE MARK TRACE +PF6_EXT_SLIB:=connmark eui64 hl icmp6 length limit mac mark multiport owner physdev policy standard state tcp udp CONNMARK HL LOG NFQUEUE MARK TRACE # Optionals PF_EXT_SLIB_OPTS:=$(foreach T,$(wildcard extensions/.*-test),$(shell KERNEL_DIR=$(KERNEL_DIR) $(T))) diff --git a/extensions/libip6t_icmp6.c b/extensions/libip6t_icmp6.c new file mode 100644 index 0000000..a29bb38 --- /dev/null +++ b/extensions/libip6t_icmp6.c @@ -0,0 +1,272 @@ +/* Shared library add-on to iptables to add ICMP support. */ +#include +#include +#include +#include +#include +#include +#include + +struct icmpv6_names { + const char *name; + u_int8_t type; + u_int8_t code_min, code_max; +}; + +static const struct icmpv6_names icmpv6_codes[] = { + { "destination-unreachable", 1, 0, 0xFF }, + { "no-route", 1, 0, 0 }, + { "communication-prohibited", 1, 1, 1 }, + { "address-unreachable", 1, 3, 3 }, + { "port-unreachable", 1, 4, 4 }, + + { "packet-too-big", 2, 0, 0xFF }, + + { "time-exceeded", 3, 0, 0xFF }, + /* Alias */ { "ttl-exceeded", 3, 0, 0xFF }, + { "ttl-zero-during-transit", 3, 0, 0 }, + { "ttl-zero-during-reassembly", 3, 1, 1 }, + + { "parameter-problem", 4, 0, 0xFF }, + { "bad-header", 4, 0, 0 }, + { "unknown-header-type", 4, 1, 1 }, + { "unknown-option", 4, 2, 2 }, + + { "echo-request", 128, 0, 0xFF }, + /* Alias */ { "ping", 128, 0, 0xFF }, + + { "echo-reply", 129, 0, 0xFF }, + /* Alias */ { "pong", 129, 0, 0xFF }, + + { "router-solicitation", 133, 0, 0xFF }, + + { "router-advertisement", 134, 0, 0xFF }, + + { "neighbour-solicitation", 135, 0, 0xFF }, + /* Alias */ { "neighbor-solicitation", 135, 0, 0xFF }, + + { "neighbour-advertisement", 136, 0, 0xFF }, + /* Alias */ { "neighbor-advertisement", 136, 0, 0xFF }, + + { "redirect", 137, 0, 0xFF }, + +}; + +static void +print_icmpv6types() +{ + unsigned int i; + printf("Valid ICMPv6 Types:"); + + for (i = 0; i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); i++) { + if (i && icmpv6_codes[i].type == icmpv6_codes[i-1].type) { + if (icmpv6_codes[i].code_min == icmpv6_codes[i-1].code_min + && (icmpv6_codes[i].code_max + == icmpv6_codes[i-1].code_max)) + printf(" (%s)", icmpv6_codes[i].name); + else + printf("\n %s", icmpv6_codes[i].name); + } + else + printf("\n%s", icmpv6_codes[i].name); + } + printf("\n"); +} + +/* Function which prints out usage message. */ +static void +help(void) +{ + printf( +"ICMPv6 v%s options:\n" +" --icmpv6-type [!] typename match icmpv6 type\n" +" (or numeric type or type/code)\n" +"\n", IPTABLES_VERSION); + print_icmpv6types(); +} + +static struct option opts[] = { + { "icmpv6-type", 1, 0, '1' }, + {0} +}; + +static void +parse_icmpv6(const char *icmpv6type, u_int8_t *type, u_int8_t code[]) +{ + unsigned int limit = sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); + unsigned int match = limit; + unsigned int i; + + for (i = 0; i < limit; i++) { + if (strncasecmp(icmpv6_codes[i].name, icmpv6type, strlen(icmpv6type)) + == 0) { + if (match != limit) + exit_error(PARAMETER_PROBLEM, + "Ambiguous ICMPv6 type `%s':" + " `%s' or `%s'?", + icmpv6type, + icmpv6_codes[match].name, + icmpv6_codes[i].name); + match = i; + } + } + + if (match != limit) { + *type = icmpv6_codes[match].type; + code[0] = icmpv6_codes[match].code_min; + code[1] = icmpv6_codes[match].code_max; + } else { + char *slash; + char buffer[strlen(icmpv6type) + 1]; + unsigned int number; + + strcpy(buffer, icmpv6type); + slash = strchr(buffer, '/'); + + if (slash) + *slash = '\0'; + + if (string_to_number(buffer, 0, 255, &number) == -1) + exit_error(PARAMETER_PROBLEM, + "Invalid ICMPv6 type `%s'\n", buffer); + *type = number; + if (slash) { + if (string_to_number(slash+1, 0, 255, &number) == -1) + exit_error(PARAMETER_PROBLEM, + "Invalid ICMPv6 code `%s'\n", + slash+1); + code[0] = code[1] = number; + } else { + code[0] = 0; + code[1] = 0xFF; + } + } +} + +/* Initialize the match. */ +static void +init(struct ip6t_entry_match *m, unsigned int *nfcache) +{ + struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)m->data; + + icmpv6info->code[1] = 0xFF; +} + +/* Function which parses command options; returns true if it + ate an option */ +static int +parse(int c, char **argv, int invert, unsigned int *flags, + const struct ip6t_entry *entry, + unsigned int *nfcache, + struct ip6t_entry_match **match) +{ + struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)(*match)->data; + + switch (c) { + case '1': + check_inverse(optarg, &invert, &optind, 0); + parse_icmpv6(argv[optind-1], &icmpv6info->type, + icmpv6info->code); + if (invert) + icmpv6info->invflags |= IP6T_ICMP_INV; + break; + + default: + return 0; + } + + return 1; +} + +static void print_icmpv6type(u_int8_t type, + u_int8_t code_min, u_int8_t code_max, + int invert, + int numeric) +{ + if (!numeric) { + unsigned int i; + + for (i = 0; + i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); + i++) { + if (icmpv6_codes[i].type == type + && icmpv6_codes[i].code_min == code_min + && icmpv6_codes[i].code_max == code_max) + break; + } + + if (i != sizeof(icmpv6_codes)/sizeof(struct icmpv6_names)) { + printf("%s%s ", + invert ? "!" : "", + icmpv6_codes[i].name); + return; + } + } + + if (invert) + printf("!"); + + printf("type %u", type); + if (code_min == 0 && code_max == 0xFF) + printf(" "); + else if (code_min == code_max) + printf(" code %u ", code_min); + else + printf(" codes %u-%u ", code_min, code_max); +} + +/* Prints out the union ipt_matchinfo. */ +static void +print(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match, + int numeric) +{ + const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data; + + printf("ipv6-icmp "); + print_icmpv6type(icmpv6->type, icmpv6->code[0], icmpv6->code[1], + icmpv6->invflags & IP6T_ICMP_INV, + numeric); + + if (icmpv6->invflags & ~IP6T_ICMP_INV) + printf("Unknown invflags: 0x%X ", + icmpv6->invflags & ~IP6T_ICMP_INV); +} + +/* Saves the match in parsable form to stdout. */ +static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match) +{ + const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data; + + if (icmpv6->invflags & IP6T_ICMP_INV) + printf("! "); + + printf("--icmpv6-type %u", icmpv6->type); + if (icmpv6->code[0] != 0 || icmpv6->code[1] != 0xFF) + printf("/%u", icmpv6->code[0]); + printf(" "); +} + +/* Final check; we don't care. */ +static void final_check(unsigned int flags) +{ +} + +static struct ip6tables_match icmpv6 = { + .name = "icmp6", + .version = IPTABLES_VERSION, + .size = IP6T_ALIGN(sizeof(struct ip6t_icmp)), + .userspacesize = IP6T_ALIGN(sizeof(struct ip6t_icmp)), + .help = &help, + .init = &init, + .parse = &parse, + .final_check = &final_check, + .print = &print, + .save = &save, + .extra_opts = opts, +}; + +void _init(void) +{ + register_match6(&icmpv6); +} diff --git a/extensions/libip6t_icmp6.man b/extensions/libip6t_icmp6.man new file mode 100644 index 0000000..2047180 --- /dev/null +++ b/extensions/libip6t_icmp6.man @@ -0,0 +1,14 @@ +This extension is loaded if `--protocol ipv6-icmp' or `--protocol icmpv6' is +specified. It provides the following option: +.TP +.BR "--icmpv6-type " "[!] \fItype\fP[/\fIcode\fP]|\fItypename\fP" +This allows specification of the ICMPv6 type, which can be a numeric +ICMPv6 +.IR type , +.IR type +and +.IR code , +or one of the ICMPv6 type names shown by the command +.nf + ip6tables -p ipv6-icmp -h +.fi diff --git a/extensions/libip6t_icmpv6.c b/extensions/libip6t_icmpv6.c deleted file mode 100644 index a29bb38..0000000 --- a/extensions/libip6t_icmpv6.c +++ /dev/null @@ -1,272 +0,0 @@ -/* Shared library add-on to iptables to add ICMP support. */ -#include -#include -#include -#include -#include -#include -#include - -struct icmpv6_names { - const char *name; - u_int8_t type; - u_int8_t code_min, code_max; -}; - -static const struct icmpv6_names icmpv6_codes[] = { - { "destination-unreachable", 1, 0, 0xFF }, - { "no-route", 1, 0, 0 }, - { "communication-prohibited", 1, 1, 1 }, - { "address-unreachable", 1, 3, 3 }, - { "port-unreachable", 1, 4, 4 }, - - { "packet-too-big", 2, 0, 0xFF }, - - { "time-exceeded", 3, 0, 0xFF }, - /* Alias */ { "ttl-exceeded", 3, 0, 0xFF }, - { "ttl-zero-during-transit", 3, 0, 0 }, - { "ttl-zero-during-reassembly", 3, 1, 1 }, - - { "parameter-problem", 4, 0, 0xFF }, - { "bad-header", 4, 0, 0 }, - { "unknown-header-type", 4, 1, 1 }, - { "unknown-option", 4, 2, 2 }, - - { "echo-request", 128, 0, 0xFF }, - /* Alias */ { "ping", 128, 0, 0xFF }, - - { "echo-reply", 129, 0, 0xFF }, - /* Alias */ { "pong", 129, 0, 0xFF }, - - { "router-solicitation", 133, 0, 0xFF }, - - { "router-advertisement", 134, 0, 0xFF }, - - { "neighbour-solicitation", 135, 0, 0xFF }, - /* Alias */ { "neighbor-solicitation", 135, 0, 0xFF }, - - { "neighbour-advertisement", 136, 0, 0xFF }, - /* Alias */ { "neighbor-advertisement", 136, 0, 0xFF }, - - { "redirect", 137, 0, 0xFF }, - -}; - -static void -print_icmpv6types() -{ - unsigned int i; - printf("Valid ICMPv6 Types:"); - - for (i = 0; i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); i++) { - if (i && icmpv6_codes[i].type == icmpv6_codes[i-1].type) { - if (icmpv6_codes[i].code_min == icmpv6_codes[i-1].code_min - && (icmpv6_codes[i].code_max - == icmpv6_codes[i-1].code_max)) - printf(" (%s)", icmpv6_codes[i].name); - else - printf("\n %s", icmpv6_codes[i].name); - } - else - printf("\n%s", icmpv6_codes[i].name); - } - printf("\n"); -} - -/* Function which prints out usage message. */ -static void -help(void) -{ - printf( -"ICMPv6 v%s options:\n" -" --icmpv6-type [!] typename match icmpv6 type\n" -" (or numeric type or type/code)\n" -"\n", IPTABLES_VERSION); - print_icmpv6types(); -} - -static struct option opts[] = { - { "icmpv6-type", 1, 0, '1' }, - {0} -}; - -static void -parse_icmpv6(const char *icmpv6type, u_int8_t *type, u_int8_t code[]) -{ - unsigned int limit = sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); - unsigned int match = limit; - unsigned int i; - - for (i = 0; i < limit; i++) { - if (strncasecmp(icmpv6_codes[i].name, icmpv6type, strlen(icmpv6type)) - == 0) { - if (match != limit) - exit_error(PARAMETER_PROBLEM, - "Ambiguous ICMPv6 type `%s':" - " `%s' or `%s'?", - icmpv6type, - icmpv6_codes[match].name, - icmpv6_codes[i].name); - match = i; - } - } - - if (match != limit) { - *type = icmpv6_codes[match].type; - code[0] = icmpv6_codes[match].code_min; - code[1] = icmpv6_codes[match].code_max; - } else { - char *slash; - char buffer[strlen(icmpv6type) + 1]; - unsigned int number; - - strcpy(buffer, icmpv6type); - slash = strchr(buffer, '/'); - - if (slash) - *slash = '\0'; - - if (string_to_number(buffer, 0, 255, &number) == -1) - exit_error(PARAMETER_PROBLEM, - "Invalid ICMPv6 type `%s'\n", buffer); - *type = number; - if (slash) { - if (string_to_number(slash+1, 0, 255, &number) == -1) - exit_error(PARAMETER_PROBLEM, - "Invalid ICMPv6 code `%s'\n", - slash+1); - code[0] = code[1] = number; - } else { - code[0] = 0; - code[1] = 0xFF; - } - } -} - -/* Initialize the match. */ -static void -init(struct ip6t_entry_match *m, unsigned int *nfcache) -{ - struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)m->data; - - icmpv6info->code[1] = 0xFF; -} - -/* Function which parses command options; returns true if it - ate an option */ -static int -parse(int c, char **argv, int invert, unsigned int *flags, - const struct ip6t_entry *entry, - unsigned int *nfcache, - struct ip6t_entry_match **match) -{ - struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)(*match)->data; - - switch (c) { - case '1': - check_inverse(optarg, &invert, &optind, 0); - parse_icmpv6(argv[optind-1], &icmpv6info->type, - icmpv6info->code); - if (invert) - icmpv6info->invflags |= IP6T_ICMP_INV; - break; - - default: - return 0; - } - - return 1; -} - -static void print_icmpv6type(u_int8_t type, - u_int8_t code_min, u_int8_t code_max, - int invert, - int numeric) -{ - if (!numeric) { - unsigned int i; - - for (i = 0; - i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); - i++) { - if (icmpv6_codes[i].type == type - && icmpv6_codes[i].code_min == code_min - && icmpv6_codes[i].code_max == code_max) - break; - } - - if (i != sizeof(icmpv6_codes)/sizeof(struct icmpv6_names)) { - printf("%s%s ", - invert ? "!" : "", - icmpv6_codes[i].name); - return; - } - } - - if (invert) - printf("!"); - - printf("type %u", type); - if (code_min == 0 && code_max == 0xFF) - printf(" "); - else if (code_min == code_max) - printf(" code %u ", code_min); - else - printf(" codes %u-%u ", code_min, code_max); -} - -/* Prints out the union ipt_matchinfo. */ -static void -print(const struct ip6t_ip6 *ip, - const struct ip6t_entry_match *match, - int numeric) -{ - const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data; - - printf("ipv6-icmp "); - print_icmpv6type(icmpv6->type, icmpv6->code[0], icmpv6->code[1], - icmpv6->invflags & IP6T_ICMP_INV, - numeric); - - if (icmpv6->invflags & ~IP6T_ICMP_INV) - printf("Unknown invflags: 0x%X ", - icmpv6->invflags & ~IP6T_ICMP_INV); -} - -/* Saves the match in parsable form to stdout. */ -static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match) -{ - const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data; - - if (icmpv6->invflags & IP6T_ICMP_INV) - printf("! "); - - printf("--icmpv6-type %u", icmpv6->type); - if (icmpv6->code[0] != 0 || icmpv6->code[1] != 0xFF) - printf("/%u", icmpv6->code[0]); - printf(" "); -} - -/* Final check; we don't care. */ -static void final_check(unsigned int flags) -{ -} - -static struct ip6tables_match icmpv6 = { - .name = "icmp6", - .version = IPTABLES_VERSION, - .size = IP6T_ALIGN(sizeof(struct ip6t_icmp)), - .userspacesize = IP6T_ALIGN(sizeof(struct ip6t_icmp)), - .help = &help, - .init = &init, - .parse = &parse, - .final_check = &final_check, - .print = &print, - .save = &save, - .extra_opts = opts, -}; - -void _init(void) -{ - register_match6(&icmpv6); -} diff --git a/extensions/libip6t_icmpv6.man b/extensions/libip6t_icmpv6.man deleted file mode 100644 index 2047180..0000000 --- a/extensions/libip6t_icmpv6.man +++ /dev/null @@ -1,14 +0,0 @@ -This extension is loaded if `--protocol ipv6-icmp' or `--protocol icmpv6' is -specified. It provides the following option: -.TP -.BR "--icmpv6-type " "[!] \fItype\fP[/\fIcode\fP]|\fItypename\fP" -This allows specification of the ICMPv6 type, which can be a numeric -ICMPv6 -.IR type , -.IR type -and -.IR code , -or one of the ICMPv6 type names shown by the command -.nf - ip6tables -p ipv6-icmp -h -.fi From yasuyuki.kozakai at toshiba.co.jp Fri Apr 7 13:31:33 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 7 13:48:08 2006 Subject: [PATCH 2/4] kill manually comparing protocol name with "ipv6-icmp" Message-ID: <200604071131.k37BVY3F025271@toshiba.co.jp> [IP6TABLES] kill manually comparing protocol name with "ipv6-icmp" This adds "ipv6-icmp" to chain_protos[] and kill manually comparing the argument of '-p' with it. chain_protos[] has the "icmpv6" with the same protocol number, but it's OK because proto_to_name() returns the firstly matched entry "icmpv6" as ever. --- commit 62607c174a8c1cc7a4f18e7537be75a1d5a87944 tree f1c65a0db8d249e19a4c35b46d95e7d8f1eaf628 parent f7eed26853dda6a51d70221f5c9ef0fac60f73a7 author Yasuyuki Kozakai Thu, 06 Apr 2006 22:34:56 +0900 committer Yasuyuki Kozakai Thu, 06 Apr 2006 22:34:56 +0900 ip6tables.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/ip6tables.c b/ip6tables.c index dcf7d36..1279888 100644 --- a/ip6tables.c +++ b/ip6tables.c @@ -222,6 +222,7 @@ static const struct pprot chain_protos[] { "tcp", IPPROTO_TCP }, { "udp", IPPROTO_UDP }, { "icmpv6", IPPROTO_ICMPV6 }, + { "ipv6-icmp", IPPROTO_ICMPV6 }, { "esp", IPPROTO_ESP }, { "ah", IPPROTO_AH }, }; @@ -1748,7 +1749,6 @@ int do_command6(int argc, char *argv[], char *protocol = NULL; const char *modprobe = NULL; int proto_used = 0; - char icmp6p[] = "icmpv6"; memset(&fw, 0, sizeof(fw)); @@ -1917,8 +1917,6 @@ int do_command6(int argc, char *argv[], *protocol = tolower(*protocol); protocol = argv[optind-1]; - if ( strcmp(protocol,"ipv6-icmp") == 0) - protocol = icmp6p; fw.ipv6.proto = parse_protocol(protocol); fw.ipv6.flags |= IP6T_F_PROTO; From yasuyuki.kozakai at toshiba.co.jp Fri Apr 7 13:31:49 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 7 13:48:18 2006 Subject: [PATCH 3/4] check invalid esp spi range Message-ID: <200604071131.k37BVoAs009386@toshiba.co.jp> [IPTABLES,IP6TABLES]: check invalid esp spi range --- commit c2faea0a63833f5b8c65542c36a24ee1fb53207b tree 3c49018aafea3725abbf6b1519bbc252b5374b7b parent c94b52d4b6fff1bfc2da3e192b39e0f45cd12750 author Yasuyuki Kozakai Thu, 06 Apr 2006 20:21:50 +0900 committer Yasuyuki Kozakai Thu, 06 Apr 2006 20:21:50 +0900 extensions/libip6t_esp.c | 3 +++ extensions/libipt_esp.c | 3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/extensions/libip6t_esp.c b/extensions/libip6t_esp.c index 29e865d..886e09b 100644 --- a/extensions/libip6t_esp.c +++ b/extensions/libip6t_esp.c @@ -61,6 +61,9 @@ parse_esp_spis(const char *spistring, u_ spis[0] = buffer[0] ? parse_esp_spi(buffer) : 0; spis[1] = cp[0] ? parse_esp_spi(cp) : 0xFFFFFFFF; + if (spis[0] > spis[1]) + exit_error(PARAMETER_PROBLEM, + "Invalid ESP spi range: %s", spistring); } free(buffer); } diff --git a/extensions/libipt_esp.c b/extensions/libipt_esp.c index 4abfba3..21e912b 100644 --- a/extensions/libipt_esp.c +++ b/extensions/libipt_esp.c @@ -62,6 +62,9 @@ parse_esp_spis(const char *spistring, u_ spis[0] = buffer[0] ? parse_esp_spi(buffer) : 0; spis[1] = cp[0] ? parse_esp_spi(cp) : 0xFFFFFFFF; + if (spis[0] > spis[1]) + exit_error(PARAMETER_PROBLEM, + "Invalid ESP spi range: %s", spistring); } free(buffer); } From yasuyuki.kozakai at toshiba.co.jp Fri Apr 7 13:34:32 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 7 13:51:01 2006 Subject: [PATCH 4/4] fix the path to detect esp/connbytes support in kernel Message-ID: <200604071134.k37BYXMq007297@toshiba.co.jp> [IPTABLES,IP6TABLES]: fix the path to detect esp/connbytes support in kernel The recent kernels don't have ipt_connbytes.c and ip6t_esp.c. --- commit 12bc86c77dae9d0590c5ee021d9c00f2291bfe0b tree 29a3b1b160d4784a2b264c348d1f781eedbb0ae5 parent c94b52d4b6fff1bfc2da3e192b39e0f45cd12750 author Yasuyuki Kozakai Thu, 06 Apr 2006 20:18:10 +0900 committer Yasuyuki Kozakai Thu, 06 Apr 2006 20:18:10 +0900 extensions/.connbytes-test | 2 +- extensions/.esp-test6 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/extensions/.connbytes-test b/extensions/.connbytes-test index 350140f..61355d0 100755 --- a/extensions/.connbytes-test +++ b/extensions/.connbytes-test @@ -1,2 +1,2 @@ #! /bin/sh -[ -f $KERNEL_DIR/net/ipv4/netfilter/ipt_connbytes.c ] && echo connbytes +[ -f $KERNEL_DIR/include/linux/netfilter_ipv4/ipt_connbytes.h ] && echo connbytes diff --git a/extensions/.esp-test6 b/extensions/.esp-test6 index ff63ca4..7ded945 100755 --- a/extensions/.esp-test6 +++ b/extensions/.esp-test6 @@ -1,2 +1,2 @@ #!/bin/sh -[ -f $KERNEL_DIR/net/ipv6/netfilter/ip6t_esp.c -a -f $KERNEL_DIR/include/linux/netfilter_ipv6/ip6t_esp.h ] && echo esp +[ -f $KERNEL_DIR/include/linux/netfilter_ipv6/ip6t_esp.h ] && echo esp From eddy_kvetny at yahoo.com Wed Apr 5 16:03:05 2006 From: eddy_kvetny at yahoo.com (Eddy Kvetny) Date: Fri Apr 7 14:16:16 2006 Subject: Huge impact of the conntrack mechanism on routing performance (30% with a single conntrack entry) Message-ID: <20060405140305.9637.qmail@web33801.mail.mud.yahoo.com> Netfilter gurus, Could someone shed light on pretty strange problem of a huge impact of the conntrack mechanism on routing performance ? The configuration is as follows: - the ARM9E-based (500Mhz) board with Linux 2.6.12 - 2 GbE interfaces connected to the traffic generator tool (Smartbit) - Smartbit injects UDP packets to the device via 1st network interface, then the devices routes these packets back to Smartbit via the 2nd interface When only plain routing without any netfilter stuff (conntrack, NAT, filter modules) is done, 40K packets per second are processed and returned to Smartbit giving about 485Mbps througput (40000 packets x 8 bit x 1518 byte/packet) Right after "insmod ip_conntrack.ko" the throughput drastically falls to 28 kpps (-12 kpps or -30% !!!). I know that "conntrack" mechanism has some overhead but 30% is still seems to be too much, especially when in my case there is only 1 connection in the conntrack table and as far as I know most of the "conntrack" processing is done for the 1st packet of each connection only. Then this connection is put in the "conntrack" hash table and it is supposed to be very quickly found for successive packets belonging to the same connection After "insmod iptable_filter.ko" throughput is 25 kpps (-3 kpps) and after "insmod iptable_nat.ko" (NAT mechanism) throughput is 23 kpps (-2 kpps). Insertion of additional modules (like ipt_state.ko, ip_conntrack_ftp.ko etc.) and configuring rules for firewall/NAT (not talking about hundreds or more rules) has no significant impact on throughput So, I am wondering whether there is some logic explanation for this huge impact of the conntrack mechanism on routing performance. I would appreciate any information in this regard Thanks in advance Eddy P.S. I found a couple of similar observations in Internet >From http://lwn.net/Articles/103858/ ....... 13.3. Netfilter benchmarking by HW ..... Lose 30% of performance (850kpps to 500kpps) ... Initial rate (forwarding only) 800kpps insmod ip_conntrack -200 kpps load IPtable (even empty) 25% oprofile (non-halted) everything in ip_tables (3%) static compiling makes 5% difference full test (nat, mangle, filter, ip_conntrack): down to 350kpps .................... ================================================ >From http://lkml.org/lkml/2004/9/8/235 ................................................. I'm sure others here have far better examples, but one post to the netfilter-devel list last December provided an example of a firewall that could process 580kpps with netfilter/conntrack turned off. Granted, the post noted that adding netfilter brought that down to 450kpps, and adding conntrack on top of that brought it down to 295kpps,but all three of those numbers are well over the claimed 100kpps. .................................................. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kaber at trash.net Fri Apr 7 14:37:04 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Apr 7 14:53:34 2006 Subject: [PATCH 1/4] fix loading shared library of ICMPv6 match In-Reply-To: <200604071131.k37BV2wB005845@toshiba.co.jp> References: <200604071131.k37BV2wB005845@toshiba.co.jp> Message-ID: <44365CF0.4030304@trash.net> Yasuyuki KOZAKAI wrote: > From: Yasuyuki KOZAKAI > Date: Wed, 29 Mar 2006 16:25:27 +0900 (JST) > > >>From: "Daniel De Graaf" >>Date: Sun, 26 Mar 2006 22:19:27 -0600 >> >> >>>libip6t_icmpv6.c registers a match called "icmp6", which means that >>>ip6tables -vL and ip6tables-save cannot output the match correctly. >> >>There are 2 solutions. >> >> 1. just rename libip6t_icmpv6.c to libip6t_icmp6.c. This can >> conform names of internal structure, library and kernel module. >> 2. apply attached patch to fix find_match() so that ip6tables can >> load libip6t_icmpv6.so. >> >>I like 1 but I'm not sure we can do it. Anyone knows any historical >>problem about it ? > > > No problem ? OK, then I take 1. I'm not aware of any historical problems. I think it should be fine. From kaber at trash.net Fri Apr 7 14:43:11 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Apr 7 14:59:35 2006 Subject: [PATCH] nf_conntrack: Fix module refcount dropping too far In-Reply-To: <200604070859.k378xiNM009770@toshiba.co.jp> References: <200604070859.k378xiNM009770@toshiba.co.jp> Message-ID: <44365E5F.5000004@trash.net> Yasuyuki KOZAKAI wrote: > If nf_ct_l3proto_find_get() fails to get the refcount of > nf_ct_l3proto_generic, nf_ct_l3proto_put() will drop the refcount > too far. Only nf_ct_l3proto_generic has this problem. > > This fix is missing synchronization with ip_conntrack at the last minutes, > but it's not critical, I think. Applies cleanly, thanks. From davem at davemloft.net Fri Apr 7 23:28:29 2006 From: davem at davemloft.net (David S. Miller) Date: Fri Apr 7 23:45:52 2006 Subject: Huge impact of the conntrack mechanism on routing performance (30% with a single conntrack entry) In-Reply-To: <20060405140305.9637.qmail@web33801.mail.mud.yahoo.com> References: <20060405140305.9637.qmail@web33801.mail.mud.yahoo.com> Message-ID: <20060407.142829.87870703.davem@davemloft.net> From: Eddy Kvetny Date: Wed, 5 Apr 2006 07:03:05 -0700 (PDT) > Right after "insmod ip_conntrack.ko" the throughput > drastically falls to 28 kpps (-12 kpps or -30% !!!). Yes, this is pretty much what the cost of netfilter is for a router. This has been known and well understood for a long time, and solutions to this problem are not easy which is why there hasn't been any progress in this area to date. From eric at inl.fr Fri Apr 7 23:53:47 2006 From: eric at inl.fr (Eric Leblond) Date: Sat Apr 8 00:10:16 2006 Subject: [PATCH 0/3] [RFC] fixed duration connection In-Reply-To: <4433CCBF.6060103@trash.net> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> Message-ID: <4436DF6B.4060208@inl.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick McHardy wrote: > Eric Leblond wrote: >>For this reason, we've worked on a simple kernel level implementation. >>This is done via a second "struct timer" that is added in connection >>structure. Activation of the timer, is for now done via userspace by >>using libnetfilter_conntrack or by using new option -T of the conntrack >>tool. > > > If I understand you correctly, a fixed timeout is just a timeout that > isn't refreshed, right? Why can't we just use the regular timers etc. > and add a flag that it should not be touched by ip_ct_refresh? This > would also eliminate the need for any ctnetlink changes since the > timeout value can already be specified. A set of patch following this recommandation is to follow. Big thanks to Patrick ! - -- Eric Leblond -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENt9rnxA7CdMWjzIRAjj4AKCCLFCSsT1QRpJ1Cen4PlI0qKseeACfYChO jlewNiF3gV8IifVWoMfxshI= =uBaq -----END PGP SIGNATURE----- From eric at inl.fr Fri Apr 7 23:57:18 2006 From: eric at inl.fr (Eric Leblond) Date: Sat Apr 8 00:13:48 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <4436DF6B.4060208@inl.fr> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> Message-ID: <4436E03E.9030402@inl.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here's the patch against Linus git tree. It simply modifies enum ip_conntrack_status by adding a IPS_FIXED_TIMEOUT field. This field is then checked at refresh time. - -- Regit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENuA+nxA7CdMWjzIRAoedAKCOuZyfUK8CWq3k5UBzZSc+HP1slwCgh00S PYw7RpDtK/3TwMByLfCihNk= =+LK+ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed_timeout-flag.patch Type: text/x-patch Size: 4862 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060408/b461f872/fixed_timeout-flag.bin From eric at inl.fr Fri Apr 7 23:59:18 2006 From: eric at inl.fr (Eric Leblond) Date: Sat Apr 8 00:15:49 2006 Subject: [PATCH 2/3] [libnetfilter_conntrack] fixed duration connection In-Reply-To: <4436DF6B.4060208@inl.fr> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> Message-ID: <4436E0B6.9040602@inl.fr> Hi, This patch add support for the IPS_FIXED_TIMEOUT state. BR, -- Regit -------------- next part -------------- A non-text attachment was scrubbed... Name: libnetfilter_conntrack_fixed_timeout-flag.patch Type: text/x-patch Size: 4108 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060408/76926aa1/libnetfilter_conntrack_fixed_timeout-flag-0001.bin From eric at inl.fr Sat Apr 8 00:01:58 2006 From: eric at inl.fr (Eric Leblond) Date: Sat Apr 8 00:18:30 2006 Subject: [PATCH 0/3] [conntrack] fixed duration connection In-Reply-To: <4436DF6B.4060208@inl.fr> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> Message-ID: <4436E156.5010306@inl.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch against conntrack tool adds support for fixed connection. for example : conntrack -U -d 153.113.34.136 -s 192.168.11.32 -p tcp \\ --orig-port-src 59119 --orig-port-dst 22 -t 10 \\ -u ASSURED,SEEN_REPLY,FIXED_TIMEOUT will fix timeout of connection to 10 seconds after command. BR, - -- Regit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENuFWnxA7CdMWjzIRAqu2AJ4oOokoHVGh5KWxBv/nahkc4OtIDwCfRsqV bPL3bs87V4eM/ymbSlnP/vc= =IjGO -----END PGP SIGNATURE----- From eric at inl.fr Sat Apr 8 00:08:04 2006 From: eric at inl.fr (Eric Leblond) Date: Sat Apr 8 00:24:33 2006 Subject: [PATCH 3/3] [conntrack] fixed duration connection In-Reply-To: <4436E156.5010306@inl.fr> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E156.5010306@inl.fr> Message-ID: <4436E2C4.1030303@inl.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, This is better with the patch... All my apologies BR, Eric Leblond wrote: > Hi, > > This patch against conntrack tool adds support for fixed connection. for > example : > conntrack -U -d 153.113.34.136 -s 192.168.11.32 -p tcp \\ > --orig-port-src 59119 --orig-port-dst 22 -t 10 \\ > -u ASSURED,SEEN_REPLY,FIXED_TIMEOUT > will fix timeout of connection to 10 seconds after command. > > BR, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENuLEnxA7CdMWjzIRAiKaAJ9tC+/xQ44ibVF1ioAakWn9JC7mbgCdFGiO vZLLCcIN08G45vaNsru4TAw= =BWXz -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: conntrack_fixed_timeout-flag.patch Type: text/x-patch Size: 830 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060408/0716bd1a/conntrack_fixed_timeout-flag.bin From gokultck at yahoo.com Sat Apr 8 09:16:05 2006 From: gokultck at yahoo.com (Gokul K) Date: Sat Apr 8 09:32:36 2006 Subject: configuration error Message-ID: <20060408071605.21695.qmail@web34203.mail.mud.yahoo.com> Hi, I'm trying to install a software called seppl. While configuring i'm getting the following errors. checking iptables.h usability... yes checking iptables.h presence... yes checking for iptables.h... yes checking for /lib/iptables... configure: error: *** Sorry, failed to find iptables plugin directory *** can anyone tell how to overcome this thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sumit at elitecore.com Sat Apr 8 10:06:41 2006 From: sumit at elitecore.com (Sumit) Date: Sat Apr 8 10:23:26 2006 Subject: ipt_unclean query Message-ID: <44376F11.4000804@elitecore.com> Hi Devs, After making an unclean DROP ruleset I got "not-working" complains form some of my clients who using specific stock-trading application. Simply looking to dmesg I found there are few message states that ipt_unclean: TCP flags bad: 0x0015 This message mean unclean match is dropping tcp packet with ACK,RST, and FIN flags. This I confirm with ipt_unclean.c code As per RFC793 (TCP) ... ... ... In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. ... ... ... Then is there any significance of dropping ACK+RST+FIN combination? Happy Netfiltering, -- _____ __ __ ____ ____ __ ______ /\ ___\ /\ \ /\ \ /\ \ \/ /\ \ /\ \ /\__ _\ \ \ ____\ \ \ \\_| \\ \ \_ /\ \ \\ \ \\__ \ \/ \//\___ \ \ \______ / \ \__\ \ \__\\ \__\ \ \__\ \/_____/ \/_____ / \/__/ \/__/ \/__/ \/__/ From kaber at trash.net Sat Apr 8 13:51:21 2006 From: kaber at trash.net (Patrick McHardy) Date: Sat Apr 8 14:10:34 2006 Subject: Fw: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295 In-Reply-To: <20060407142331.26e6b653.akpm@osdl.org> References: <20060407142331.26e6b653.akpm@osdl.org> Message-ID: <4437A3B9.8000000@trash.net> Andrew Morton wrote: > > Begin forwarded message: > > Date: Fri, 7 Apr 2006 06:12:07 -0700 > From: bugme-daemon@bugzilla.kernel.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295 > > > http://bugzilla.kernel.org/show_bug.cgi?id=6349 > > Summary: iptables DNAT returns unknown error 4294967295 > Kernel Version: 2.6.17-rc1 > Status: NEW > Severity: blocking > Owner: laforge@gnumonks.org > Submitter: dmb@pochta.ru > > > Problem Description: > When I try to add the rule with target DNAT to the OUTPUT chain I get the error > message: > [root@dbagrii:~]# iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport 119 -j > DNAT --to-destination 192.168.1.10:8119 > iptables: Unknown error 4294967295 > > No rule is added, and the kernel says the message to the syslog: > Apr 7 15:20:05 dbagrii kernel: ip_tables: DNAT target: bad hook_mask 8 > > This error appears with iptables tool version 1.3.3 and 1.3.5 i tried to use. > > Steps to reproduce: > Run the iptables tool with this arguments: > $ iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport 119 -j DNAT > --to-destination 192.168.1.10:8119 Please try if this patch helps. -------------- next part -------------- [NETFILTER]: Fix DNAT in LOCAL_OUT Signed-off-by: Patrick McHardy --- commit 0fc7ff57191de5c09afe7db3932009963bba44d6 tree 02bc033088605bfd51fa4ea7ceb57d0aae1db65e parent 8cc24d7ca2ffc6d9d70e1d94dc8dffbdf677e58f author Patrick McHardy Sat, 08 Apr 2006 13:52:18 +0200 committer Patrick McHardy Sat, 08 Apr 2006 13:52:18 +0200 net/ipv4/netfilter/ip_nat_rule.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/ip_nat_rule.c b/net/ipv4/netfilter/ip_nat_rule.c index efba8c4..250b8ed 100644 --- a/net/ipv4/netfilter/ip_nat_rule.c +++ b/net/ipv4/netfilter/ip_nat_rule.c @@ -279,7 +279,7 @@ static struct ipt_target ipt_dnat_reg = .target = ipt_dnat_target, .targetsize = sizeof(struct ip_nat_multi_range_compat), .table = "nat", - .hooks = 1 << NF_IP_PRE_ROUTING, + .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT, .checkentry = ipt_dnat_checkentry, }; From kaber at trash.net Sat Apr 8 13:58:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Sat Apr 8 14:17:09 2006 Subject: Fw: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295 In-Reply-To: <4437A3B9.8000000@trash.net> References: <20060407142331.26e6b653.akpm@osdl.org> <4437A3B9.8000000@trash.net> Message-ID: <4437A552.902@trash.net> Patrick McHardy wrote: > Please try if this patch helps. > > + .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT, I shouldn't send patches before getting out of bed .. :) Please try this one instead. -------------- next part -------------- [NETFILTER]: Fix DNAT in LOCAL_OUT Signed-off-by: Patrick McHardy --- commit 2ceefa038e908d5da21aefedae02da4eab1b2787 tree 417f03eca3b97b16a78321ace1556e57f5c60351 parent 8cc24d7ca2ffc6d9d70e1d94dc8dffbdf677e58f author Patrick McHardy Sat, 08 Apr 2006 13:59:53 +0200 committer Patrick McHardy Sat, 08 Apr 2006 13:59:53 +0200 net/ipv4/netfilter/ip_nat_rule.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/ip_nat_rule.c b/net/ipv4/netfilter/ip_nat_rule.c index efba8c4..1aba926 100644 --- a/net/ipv4/netfilter/ip_nat_rule.c +++ b/net/ipv4/netfilter/ip_nat_rule.c @@ -279,7 +279,7 @@ static struct ipt_target ipt_dnat_reg = .target = ipt_dnat_target, .targetsize = sizeof(struct ip_nat_multi_range_compat), .table = "nat", - .hooks = 1 << NF_IP_PRE_ROUTING, + .hooks = (1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_LOCAL_OUT), .checkentry = ipt_dnat_checkentry, }; From kernel at linuxace.com Sat Apr 8 18:44:42 2006 From: kernel at linuxace.com (Phil Oester) Date: Sat Apr 8 19:01:16 2006 Subject: ipt_unclean query In-Reply-To: <44376F11.4000804@elitecore.com> References: <44376F11.4000804@elitecore.com> Message-ID: <20060408164442.GA20209@linuxace.com> On Sat, Apr 08, 2006 at 01:36:41PM +0530, Sumit wrote: > Hi Devs, > After making an unclean DROP ruleset I got "not-working" complains > form some of my clients who using specific stock-trading application. Unclean is unsafe, and is scheduled to be removed from pom within the next 30 days. Don't use it. Phil From kaber at trash.net Sat Apr 8 21:56:52 2006 From: kaber at trash.net (Patrick McHardy) Date: Sat Apr 8 22:13:37 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <4436E03E.9030402@inl.fr> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> Message-ID: <44381584.4020109@trash.net> Eric Leblond wrote: > Hi, > > Here's the patch against Linus git tree. I don't have any principle objections against merging this (if there are no objections from others), a couple of comments on the patch though. +#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) || defined(CONFIG_NF_CT_FIXED_TIMEOUT) + /* Connection has fixed timeout. */ + IPS_FIXED_TIMEOUT_BIT = 10, + IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT), +#endif Probably not worth adding a config option for this. + }; @@ -85,6 +85,7 @@ struct ip_conntrack /* Timer function; drops refcnt when it goes off. */ struct timer_list timeout; + Please remove this. #ifdef CONFIG_IP_NF_CT_ACCT /* Accounting Information (same cache line as other written members) */ struct ip_conntrack_counter counters[IP_CT_DIR_MAX]; @@ -292,6 +293,13 @@ static inline int is_dying(struct ip_con return test_bit(IPS_DYING_BIT, &ct->status); } +#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) || defined(CONFIG_NF_CT_FIXED_TIMEOUT) +static inline int is_fixedtimeout(struct ip_conntrack *ct) +{ + return test_bit(IPS_FIXED_TIMEOUT_BIT, &ct->status); +} +#endif I guess without a seperate config option we don't need this function anymore. diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c index ceaabc1..44fa788 100644 --- a/net/ipv4/netfilter/ip_conntrack_core.c +++ b/net/ipv4/netfilter/ip_conntrack_core.c @@ -1130,18 +1130,27 @@ void __ip_ct_refresh_acct(struct ip_conn write_lock_bh(&ip_conntrack_lock); - /* If not in hash table, timer will not be active yet */ - if (!is_confirmed(ct)) { - ct->timeout.expires = extra_jiffies; - event = IPCT_REFRESH; - } else { - /* Need del_timer for race avoidance (may already be dying). */ - if (del_timer(&ct->timeout)) { - ct->timeout.expires = jiffies + extra_jiffies; - add_timer(&ct->timeout); - event = IPCT_REFRESH; - } - } +#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) || defined(CONFIG_NF_CT_FIXED_TIMEOUT) + /* only update if this is not a fixed timeout */ + if (! is_fixedtimeout(ct)){ +#endif + /* If not in hash table, timer will not be active yet */ + if (!is_confirmed(ct)) { + ct->timeout.expires = extra_jiffies; + event = IPCT_REFRESH; + } else { + /* Need del_timer for race avoidance (may already be dying). */ + if (del_timer(&ct->timeout)) { + ct->timeout.expires = jiffies + extra_jiffies; + add_timer(&ct->timeout); + event = IPCT_REFRESH; + } + } +#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) + } else { + DEBUGP("FIXED TIMEOUT: Not updating\n"); + } +#endif Please just do a simple if (!test_bit(...)) return; at the beginning. From kaber at trash.net Sat Apr 8 21:58:58 2006 From: kaber at trash.net (Patrick McHardy) Date: Sat Apr 8 22:15:31 2006 Subject: [PATCH 2/3] [libnetfilter_conntrack] fixed duration connection In-Reply-To: <4436E0B6.9040602@inl.fr> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E0B6.9040602@inl.fr> Message-ID: <44381602.5090105@trash.net> Eric Leblond wrote: > Hi, > > This patch add support for the IPS_FIXED_TIMEOUT state. > > BR, > -- > Regit > > > ------------------------------------------------------------------------ > > Index: include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h > =================================================================== > --- include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h (r??vision 6576) > +++ include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h (copie de travail) > @@ -29,6 +29,7 @@ > CTA_HELP, > CTA_NAT, > CTA_TIMEOUT, > + CTA_FIXED_TIMEOUT, > CTA_MARK, > CTA_COUNTERS_ORIG, > CTA_COUNTERS_REPLY, I didn't see the patch adding support for this in the kernel. Since there is no seperate fixed timeout anymore, this also looks obsolete. The way I understood the kernel patch, you would just do two netlink operations: - set flag FIXED_TIMEOUT - change timeout using CTA_TIMEOUT Am I missing something? From eric at inl.fr Sat Apr 8 22:23:27 2006 From: eric at inl.fr (Eric Leblond) Date: Sat Apr 8 22:40:01 2006 Subject: [PATCH 2/3] [libnetfilter_conntrack] fixed duration connection In-Reply-To: <44381602.5090105@trash.net> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E0B6.9040602@inl.fr> <44381602.5090105@trash.net> Message-ID: <44381BBF.4060605@inl.fr> Patrick McHardy wrote: > Eric Leblond wrote: > >>Hi, >> >>This patch add support for the IPS_FIXED_TIMEOUT state. > I didn't see the patch adding support for this in the kernel. Since > there is no seperate fixed timeout anymore, this also looks obsolete. > The way I understood the kernel patch, you would just do two netlink > operations: > > - set flag FIXED_TIMEOUT > - change timeout using CTA_TIMEOUT > > Am I missing something? Clearly not. I was a little bit too tired yesterday and I've done a "svn diff" in the bad directory. Please ignore previous patch and consider this far smaller one. Best regards, -- Eric Leblond -------------- next part -------------- A non-text attachment was scrubbed... Name: libnetfilter_conntrack_fixed_timeout-flag.patch Type: text/x-patch Size: 574 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060408/9b06834a/libnetfilter_conntrack_fixed_timeout-flag-0001.bin From eric at inl.fr Sat Apr 8 22:55:38 2006 From: eric at inl.fr (Eric Leblond) Date: Sat Apr 8 23:12:04 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <44381584.4020109@trash.net> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> <44381584.4020109@trash.net> Message-ID: <4438234A.2080702@inl.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, I followed your recommendation and here's the patch. Patrick McHardy wrote: > Eric Leblond wrote: > >>Hi, >> >>Here's the patch against Linus git tree. > > > I don't have any principle objections against merging this (if > there are no objections from others), a couple of comments > on the patch though. BR and thanks a lot for your help, - -- Eric Leblond -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEOCNKnxA7CdMWjzIRAuVlAJ9v75j2WeEvMAJVqDekgOxzTRmHQwCcDN5B sdtE712lSkUuG25DMBB9v+w= =K6vk -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed_timeout-flag.patch Type: text/x-patch Size: 1942 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060408/f93bd9cf/fixed_timeout-flag.bin From jim at jimpick.com Sun Apr 9 02:01:30 2006 From: jim at jimpick.com (Jim Pick) Date: Sun Apr 9 02:18:45 2006 Subject: Masquerading problems - XenU 3.0 on x86_64 Message-ID: <44384EDA.2080106@jimpick.com> Hi, I'm trying to migrate my Xen sessions installed on 32-bit Xen 2.0 server to a 64-bit Xen 3.0 server. On the Xen 2.0 server (32-bit), I built a DomU kernel with masquerading, and I use that to do NAT for some private networks running on the same box. When I tried to do it with Xen 3.0 (64-bit), I couldn't get it to work. I had to build a custom DomU kernel (from xen-3.0-testing.hg, 2.6.16, 2 days ago) in order to include the netfilter/iptables code. ICMP works. TCP doesn't. Non-masquerading traffic is OK. I had the same problems with the 2.6.12 kernel from Xen 3.0.1. I captured some of the traffic, and ethereal is showing that the masqueraded traffic being output has bad TCP checksums. I'm going to have to do some debugging to try to figure out what's going wrong. Has anybody else encountered this? Also, if it's already been fixed somewhere, I'd love to know. Any Netfilter debugging tips would also be appreciated. Cheers, - Jim From jim at jimpick.com Sun Apr 9 22:18:34 2006 From: jim at jimpick.com (Jim Pick) Date: Sun Apr 9 22:35:19 2006 Subject: [Xen-devel] Masquerading problems - XenU 3.0 on x86_64 In-Reply-To: <6677c9ee1b32caad4ff87bf462512ee3@cl.cam.ac.uk> References: <44384EDA.2080106@jimpick.com> <6677c9ee1b32caad4ff87bf462512ee3@cl.cam.ac.uk> Message-ID: <44396C1A.5020102@jimpick.com> Keir Fraser wrote: > > On 9 Apr 2006, at 01:01, Jim Pick wrote: > >> I'm trying to migrate my Xen sessions installed on 32-bit Xen 2.0 >> server to a 64-bit Xen 3.0 server. >> >> On the Xen 2.0 server (32-bit), I built a DomU kernel with >> masquerading, and I use that to do NAT for some private networks >> running on the same box. >> >> When I tried to do it with Xen 3.0 (64-bit), I couldn't get it to >> work. I had to build a custom DomU kernel (from xen-3.0-testing.hg, >> 2.6.16, 2 days ago) in order to include the netfilter/iptables code. >> ICMP works. TCP doesn't. Non-masquerading traffic is OK. I had the >> same problems with the 2.6.12 kernel from Xen 3.0.1. >> >> I captured some of the traffic, and ethereal is showing that the >> masqueraded traffic being output has bad TCP checksums. >> >> I'm going to have to do some debugging to try to figure out what's >> going wrong. >> >> Has anybody else encountered this? Also, if it's already been fixed >> somewhere, I'd love to know. Any Netfilter debugging tips would also >> be appreciated. > > > Turn off tx checksum offload in your domU's using ethtool. We had fixed > some forms of NAT with our checksum offload, but maybe not for your type > of setup. That fixed it. Thanks! Cheers, - Jim From davem at davemloft.net Mon Apr 10 07:39:07 2006 From: davem at davemloft.net (David S. Miller) Date: Mon Apr 10 07:56:09 2006 Subject: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295 In-Reply-To: <4437A552.902@trash.net> References: <20060407142331.26e6b653.akpm@osdl.org> <4437A3B9.8000000@trash.net> <4437A552.902@trash.net> Message-ID: <20060409.223907.11399328.davem@davemloft.net> From: Patrick McHardy Date: Sat, 08 Apr 2006 13:58:10 +0200 > Patrick McHardy wrote: > > Please try if this patch helps. > > > > + .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT, > > I shouldn't send patches before getting out of bed .. :) > > Please try this one instead. I'm applying this to my tree. If it's wrong for some reason, we still have time in the 2.6.17-X devel cycle to correct it. From eddy.linux at yahoo.com Sun Apr 9 23:10:31 2006 From: eddy.linux at yahoo.com (Eddy Kvetny) Date: Mon Apr 10 14:10:09 2006 Subject: Huge impact of the conntrack mechanism on routing performance (30% with a single conntrack entry) Message-ID: <20060409211031.97319.qmail@web38408.mail.mud.yahoo.com> > From: David S. Miller davem at davemloft.net > Date: Fri Apr 7 23:28:29 CEST 2006 >> From: Eddy Kvetny >> Date: Wed, 5 Apr 2006 07:03:05 -0700 (PDT) >> Right after "insmod ip_conntrack.ko" the throughput >> drastically falls to 28 kpps (-12 kpps or -30% !!!). > Yes, this is pretty much what the cost of netfilter > is for a router. > This has been known and well understood for a long > time, and solutions > to this problem are not easy which is why there > hasn't been any progress in this area to date. Thanks for the response I would appreciate if someone could explain this "well understood" :-) thing to me. How come such an overhead for a single entry in the conntrack table ? After putting it to the table this entry is hashed and later is supposed to be find very quickly. What am I missing here ? Thanks in advance Best regards, Eddy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From azez at ufomechanic.net Mon Apr 10 14:02:02 2006 From: azez at ufomechanic.net (Amin Azez) Date: Mon Apr 10 14:19:18 2006 Subject: [PATCH 2/4] kill manually comparing protocol name with "ipv6-icmp" In-Reply-To: <200604071131.k37BVY3F025271@toshiba.co.jp> References: <200604071131.k37BVY3F025271@toshiba.co.jp> Message-ID: <443A493A.5030307@ufomechanic.net> Yasuyuki KOZAKAI wrote: > [IP6TABLES] kill manually comparing protocol name with "ipv6-icmp" > > This adds "ipv6-icmp" to chain_protos[] and kill manually comparing > the argument of '-p' with it. > > chain_protos[] has the "icmpv6" with the same protocol number, but it's > OK because proto_to_name() returns the firstly matched entry "icmpv6" > as ever. I'm uncomfortable with having proto names in source code anyway, to me it clashes horribly with getprotobyname and friends which for historical and bizarre reasons might be looked up centrally (using nss) via ldap !! However I guess history also shows that protocol names have been stable over the years :-) so what can I say? Sam From varun at rocsys.com Mon Apr 10 15:09:27 2006 From: varun at rocsys.com (varun) Date: Mon Apr 10 15:19:12 2006 Subject: problem in iptables!!! Message-ID: <443A5907.7000202@rocsys.com> Hi all, I have a small problem with iptables. Iam trying to use iptables in an Cyberton Board (ARM). I compiled it with ucLibc. and i also put the images on the board. Then when board comes up i manually insmoded the following modules. ip_conntrack.ko ipt_REJECT.ko ipt_state.ko ip_tables.ko ipt_conntrack.ko iptable_filter.ko Then i tried to add a policy iptables -t filter -A OUTPUT -j REJECT This works well in my PC with the 2.6 kernel but gives this error on the same kernel arm compiled. The error i get is iptables v1.2.11: Couldn't find target `REJECT' Try `iptables -h' or 'iptables --help' for more information. Can someone tell me what is wrong? Varun From yasuyuki.kozakai at toshiba.co.jp Tue Apr 11 03:04:20 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Tue Apr 11 03:21:35 2006 Subject: problem in iptables!!! In-Reply-To: <443A5907.7000202@rocsys.com> References: <443A5907.7000202@rocsys.com> Message-ID: <200604110104.k3B14K6U026702@toshiba.co.jp> From: varun Date: Mon, 10 Apr 2006 18:39:27 +0530 > Hi all, > > I have a small problem with iptables. Iam trying to use > iptables in an Cyberton Board (ARM). I compiled it with ucLibc. and i > also put the images on the board. Then when board comes up i manually > insmoded the following modules. > > ip_conntrack.ko ipt_REJECT.ko ipt_state.ko > ip_tables.ko ipt_conntrack.ko iptable_filter.ko > > Then i tried to add a policy > iptables -t filter -A OUTPUT -j REJECT > This works well in my PC with the 2.6 kernel but gives this error on > the same kernel arm compiled. > The error i get is > iptables v1.2.11: Couldn't find target `REJECT' > > Try `iptables -h' or 'iptables --help' for more > information. This message means that shared library libipt_REJECT.so isn't not found. > Can someone tell me what is wrong? I think that you didn't install shared libraries for matches/targets to your image even though you build iptables without statically linking them. If so, you have 2 options. - You can install them to /usr/local/lib/iptables (or path you specified clearly when building iptables) on image. - You can build iptables statically linking them by 'make NO_SHARED_LIBS=1' . -- Yasuyuki Kozakai From azez at ufomechanic.net Tue Apr 11 18:09:31 2006 From: azez at ufomechanic.net (Amin Azez) Date: Tue Apr 11 18:26:34 2006 Subject: [PATCH 4/4] first conntrack ID must be 1 not 2 In-Reply-To: <4434F53A.2030302@trash.net> References: <43F43FA9.4000906@trash.net> <43F4426D.9060807@trash.net> <43F4DBDF.9010008@trash.net> <442B9765.2020105@ufomechanic.net> <442C81A6.3040501@trash.net> <442D78A8.4050300@trash.net> <20060401193138.GG11031@sunbeam.de.gnumonks.org> <4434F53A.2030302@trash.net> Message-ID: <443BD4BB.7090806@ufomechanic.net> Patrick McHardy wrote: > Harald Welte wrote: > >>So if there's now a majority of people who want to delete the ID: Go for >>it :) > > > Found the patch again. What it does is: > > - note entry of next conntrack to be dumped and keep a reference to it > - when continuing, look for the conntrack and continue at it if its > still there > - if not, dump the entire bucket again > > In theory we could end up in an endless loop if the conntrack entry > we're keeping the reference to is deleted everytime we want to > continue dumping. Why not defer the ip_conntrack_put until after ctnetlink_fill_info, would that avoid the problem altogether? It's no longer the entry of the next conntrack but the entry of the last conntrack by the time it gets deleted then...? Or have I misunderstood the way in which the loop would occur? Sam From azez at ufomechanic.net Tue Apr 11 18:09:31 2006 From: azez at ufomechanic.net (Amin Azez) Date: Tue Apr 11 18:26:51 2006 Subject: [PATCH 4/4] first conntrack ID must be 1 not 2 In-Reply-To: <4434F53A.2030302@trash.net> References: <43F43FA9.4000906@trash.net> <43F4426D.9060807@trash.net> <43F4DBDF.9010008@trash.net> <442B9765.2020105@ufomechanic.net> <442C81A6.3040501@trash.net> <442D78A8.4050300@trash.net> <20060401193138.GG11031@sunbeam.de.gnumonks.org> <4434F53A.2030302@trash.net> Message-ID: <443BD4BB.7090806@ufomechanic.net> Patrick McHardy wrote: > Harald Welte wrote: > >>So if there's now a majority of people who want to delete the ID: Go for >>it :) > > > Found the patch again. What it does is: > > - note entry of next conntrack to be dumped and keep a reference to it > - when continuing, look for the conntrack and continue at it if its > still there > - if not, dump the entire bucket again > > In theory we could end up in an endless loop if the conntrack entry > we're keeping the reference to is deleted everytime we want to > continue dumping. Why not defer the ip_conntrack_put until after ctnetlink_fill_info, would that avoid the problem altogether? It's no longer the entry of the next conntrack but the entry of the last conntrack by the time it gets deleted then...? Or have I misunderstood the way in which the loop would occur? Sam From kaber at trash.net Tue Apr 11 18:17:55 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Apr 11 18:34:46 2006 Subject: [PATCH 4/4] first conntrack ID must be 1 not 2 In-Reply-To: <443BD4BB.7090806@ufomechanic.net> References: <43F43FA9.4000906@trash.net> <43F4426D.9060807@trash.net> <43F4DBDF.9010008@trash.net> <442B9765.2020105@ufomechanic.net> <442C81A6.3040501@trash.net> <442D78A8.4050300@trash.net> <20060401193138.GG11031@sunbeam.de.gnumonks.org> <4434F53A.2030302@trash.net> <443BD4BB.7090806@ufomechanic.net> Message-ID: <443BD6B3.8020607@trash.net> Amin Azez wrote: > Patrick McHardy wrote: > >> Found the patch again. What it does is: >> >> - note entry of next conntrack to be dumped and keep a reference to it >> - when continuing, look for the conntrack and continue at it if its >> still there >> - if not, dump the entire bucket again >> >> In theory we could end up in an endless loop if the conntrack entry >> we're keeping the reference to is deleted everytime we want to >> continue dumping. > > > Why not defer the ip_conntrack_put until after ctnetlink_fill_info, > would that avoid the problem altogether? > > It's no longer the entry of the next conntrack but the entry of the last > conntrack by the time it gets deleted then...? Or have I misunderstood > the way in which the loop would occur? Yes, the loop is interrupted when the skb is full and continued when userspace issues the next recvmsg(). The reference is kept to find the point where to continue. From kaber at trash.net Tue Apr 11 18:22:46 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Apr 11 18:39:38 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <4438234A.2080702@inl.fr> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> <44381584.4020109@trash.net> <4438234A.2080702@inl.fr> Message-ID: <443BD7D6.7030805@trash.net> Eric Leblond wrote: > I followed your recommendation and here's the patch. Seems you missed one in the noise :) ------------------------------------------------------------------------ diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c index ceaabc1..d9dbe0f 100644 --- a/net/ipv4/netfilter/ip_conntrack_core.c +++ b/net/ipv4/netfilter/ip_conntrack_core.c @@ -1130,18 +1130,21 @@ void __ip_ct_refresh_acct(struct ip_conn write_lock_bh(&ip_conntrack_lock); ------- Please just do: if (test_bit(...)) return; ------- - /* If not in hash table, timer will not be active yet */ - if (!is_confirmed(ct)) { - ct->timeout.expires = extra_jiffies; - event = IPCT_REFRESH; - } else { - /* Need del_timer for race avoidance (may already be dying). */ - if (del_timer(&ct->timeout)) { - ct->timeout.expires = jiffies + extra_jiffies; - add_timer(&ct->timeout); - event = IPCT_REFRESH; - } - } + /* only update if this is not a fixed timeout */ + if (! test_bit(IPS_FIXED_TIMEOUT_BIT, &ct->status)){ + /* If not in hash table, timer will not be active yet */ + if (!is_confirmed(ct)) { + ct->timeout.expires = extra_jiffies; + event = IPCT_REFRESH; + } else { + /* Need del_timer for race avoidance (may already be dying). */ + if (del_timer(&ct->timeout)) { + ct->timeout.expires = jiffies + extra_jiffies; + add_timer(&ct->timeout); + event = IPCT_REFRESH; + } + } + } #ifdef CONFIG_IP_NF_CT_ACCT if (do_acct) { From laforge at netfilter.org Tue Apr 11 20:26:24 2006 From: laforge at netfilter.org (Harald Welte) Date: Tue Apr 11 20:43:18 2006 Subject: [RFC: 2.6 patch] the overdue removal of ip{,6}_queue In-Reply-To: <443BC06A.8020103@trash.net> References: <20060409180105.GK8454@stusta.de> <44395505.1070608@trash.net> <20060411090139.GI5167@rama.linbit> <443BC06A.8020103@trash.net> Message-ID: <20060411182624.GD31616@sunbeam.de.gnumonks.org> On Tue, Apr 11, 2006 at 04:42:50PM +0200, Patrick McHardy wrote: > > Maybe we should add a printk ('app foo is using obsolete ip_queue > > system'). > > Good idea, that will probably help speed it up. But I still think > we need to give them at least another six month. ok. I'll prepare a patch for both the printk and the update of feature-removal-schedule. > I think we need to do two things: > > - make libipq_compat a drop-in replacement that doesn't require > recompilation libipq is not distributed as a shared library (at least not by us), so I don't see any purpose for doing so. Do you think anyone is going to re-link statically linked code against the new lib > - make it work with both ipq and nfnetlink_queue that should be possible, though. I still don't really think that it is worth all the effort, especially since there is only one hand full of applications using libipq. The backwards compatibility library is expected to perform a lot worse thna both the old libipq as well as the new native libnetfilter_queue due to additional data copies, etc. When I wrote it, it was more intended as some intermediate aid, something that helps while people migrate. We shouldn't make it too perfect, otherwise they won't migrate at all. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060411/c58a015f/attachment.pgp From eric at inl.fr Tue Apr 11 22:20:15 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Apr 11 22:36:50 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <443BD7D6.7030805@trash.net> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> <44381584.4020109@trash.net> <4438234A.2080702@inl.fr> <443BD7D6.7030805@trash.net> Message-ID: <443C0F7F.7060208@inl.fr> Patrick McHardy wrote: > Eric Leblond wrote: > >>I followed your recommendation and here's the patch. > > > Seems you missed one in the noise :) Here it is. Thank you very much for your patience. humm, google define:patience gives me : good-natured tolerance of delay or incompetence Definition looks really good this time ;-) BR, -- Eric Leblond -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed_timeout-flag.patch Type: text/x-patch Size: 1145 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060411/f2ff910d/fixed_timeout-flag.bin From shemminger at osdl.org Tue Apr 11 22:22:11 2006 From: shemminger at osdl.org (Stephen Hemminger) Date: Tue Apr 11 22:39:09 2006 Subject: Netfilter bug in 2.6.16 Message-ID: <20060411132211.67c6ef51@localhost.localdomain> I looked at this bug: http://bugzilla.kernel.org/show_bug.cgi?id=6322 It seems that a filter is crashing. Can't see what it is because the important info has already scrolled off the screen shots. From laforge at netfilter.org Wed Apr 12 10:38:36 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 10:55:34 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <44381584.4020109@trash.net> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> <44381584.4020109@trash.net> Message-ID: <20060412083835.GN31616@sunbeam.de.gnumonks.org> On Sat, Apr 08, 2006 at 09:56:52PM +0200, Patrick McHardy wrote: > I don't have any principle objections against merging this (if > there are no objections from others), a couple of comments > on the patch though. Well, if we merge it for ip_conntrack, we _have_ to also merge it into nf_conntrack for consistency reasons. > +#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) || > defined(CONFIG_NF_CT_FIXED_TIMEOUT) > + /* Connection has fixed timeout. */ > + IPS_FIXED_TIMEOUT_BIT = 10, > + IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT), > +#endif > > Probably not worth adding a config option for this. not for the bit, but in general we would need one, otherwise we have an (extremely large) timer entry per conntrack... -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/62719e5c/attachment.pgp From laforge at netfilter.org Wed Apr 12 10:43:05 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 11:00:02 2006 Subject: Huge impact of the conntrack mechanism on routing performance (30% with a single conntrack entry) In-Reply-To: <20060409211031.97319.qmail@web38408.mail.mud.yahoo.com> References: <20060409211031.97319.qmail@web38408.mail.mud.yahoo.com> Message-ID: <20060412084305.GO31616@sunbeam.de.gnumonks.org> On Sun, Apr 09, 2006 at 02:10:31PM -0700, Eddy Kvetny wrote: > I would appreciate if someone could explain this "well > understood" :-) thing to me. How come such an overhead > for a single entry in the conntrack table ? After > putting it to the table this entry is hashed and later > is supposed to be find very quickly. What am I missing > here ? You are probably missing that the hashtable lookup is quite expensive, as well as referencing multiple cacheline worth of data (i.e. producing a number of more data cache misses per packet). Also, the connection tracking entry needs to be updated with every packet (new timeout, tcp state changes), and you need to look way deeper into the packet than just for routing (additional instruction cycles, additional data cache misses). -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/dfdf5e70/attachment.pgp From laforge at netfilter.org Wed Apr 12 10:47:19 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 11:04:16 2006 Subject: nth, random and fuzzy match In-Reply-To: <4435559A.60904@trash.net> References: <4435559A.60904@trash.net> Message-ID: <20060412084719.GP31616@sunbeam.de.gnumonks.org> On Thu, Apr 06, 2006 at 07:53:30PM +0200, Patrick McHardy wrote: > So my questions to the nth users: is anyone using the nth > match in a way that can't be done by just matching on every > nth packet with an optional starting point? I suggest posting this to the users mailinglist, since the question is addressed to users :) -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/0855af3d/attachment.pgp From laforge at netfilter.org Wed Apr 12 10:52:33 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 11:09:32 2006 Subject: [PATCH 2/4] kill manually comparing protocol name with "ipv6-icmp" In-Reply-To: <443A493A.5030307@ufomechanic.net> References: <200604071131.k37BVY3F025271@toshiba.co.jp> <443A493A.5030307@ufomechanic.net> Message-ID: <20060412085233.GQ31616@sunbeam.de.gnumonks.org> On Mon, Apr 10, 2006 at 01:02:02PM +0100, Amin Azez wrote: > Yasuyuki KOZAKAI wrote: > >[IP6TABLES] kill manually comparing protocol name with "ipv6-icmp" > >This adds "ipv6-icmp" to chain_protos[] and kill manually comparing > >the argument of '-p' with it. > >chain_protos[] has the "icmpv6" with the same protocol number, but it's > >OK because proto_to_name() returns the firstly matched entry "icmpv6" > >as ever. > > I'm uncomfortable with having proto names in source code anyway, to me > it clashes horribly with getprotobyname and friends which for > historical and bizarre reasons might be looked up centrally (using > nss) via ldap !! We're talking about a firewall here. Decent security practise suggests that you block all kind of traffic until you've loaded your ruleset. Retrieving service/protocol information from NIS/LDAP or other network based services is a conflicht with this practise and prone to fail sooner or later, since it creates awkward dependencies (can't restart/reload firewall because other machine not alive, etc.). Also, any kind of lookup table can probably be compromised, and any small change in /etc/{protocols,services} has implicit changes in your packet filter ruleset, so it provides for an interesting 'hidden' path for attackers. So I'm very comfortable in having some values hardcoded, and I very much support any admin who hardcodes port and protocol numbers in their rulesets. For similar (and even worse) reasons, I'm strictly against host name lookup support... -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/d6528d5f/attachment-0001.pgp From laforge at netfilter.org Wed Apr 12 10:59:26 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 11:16:25 2006 Subject: [PATCH 4/4] fix the path to detect esp/connbytes support in kernel In-Reply-To: <200604071134.k37BYXMq007297@toshiba.co.jp> References: <200604071134.k37BYXMq007297@toshiba.co.jp> Message-ID: <20060412085926.GR31616@sunbeam.de.gnumonks.org> On Fri, Apr 07, 2006 at 08:34:32PM +0900, Yasuyuki KOZAKAI wrote: > [IPTABLES,IP6TABLES]: fix the path to detect esp/connbytes support in kernel > > The recent kernels don't have ipt_connbytes.c and ip6t_esp.c. thanks, applied. Please commit such changes to svn on your own in the future. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/8cf0e546/attachment.pgp From laforge at netfilter.org Wed Apr 12 12:43:18 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 13:00:15 2006 Subject: [PATCH IP{, 6}TABLES 0/4] fix loading icmpv6 module and minor changes In-Reply-To: <200604071130.k37BUBa3009024@toshiba.co.jp> References: <200604071130.k37BUBa3009024@toshiba.co.jp> Message-ID: <20060412104318.GS31616@sunbeam.de.gnumonks.org> On Fri, Apr 07, 2006 at 08:30:11PM +0900, Yasuyuki KOZAKAI wrote: > > Hi, > > One patch fixes unusable icmpv6 because ip6tables doesn't try to load > libip6t_icmpv6.so. Others are minor fixes/cleanup in ip{,6}tables. > > If no objection/miss, I'll commit them next weekend. ah, ok. pleaes ignore my comment from a couple of minutes ago. Please commit at least simple fixes like this immediately in the future. The changes are visible in the changelog (netfilter-cvslog mailinglist), and if there really are any problems with a change, we can always fix it incrementally. Thanks! -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/ce5a9835/attachment.pgp From laforge at netfilter.org Wed Apr 12 12:44:03 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 13:01:01 2006 Subject: configuration error In-Reply-To: <20060408071605.21695.qmail@web34203.mail.mud.yahoo.com> References: <20060408071605.21695.qmail@web34203.mail.mud.yahoo.com> Message-ID: <20060412104403.GT31616@sunbeam.de.gnumonks.org> On Sat, Apr 08, 2006 at 12:16:05AM -0700, Gokul K wrote: > Hi, > > I'm trying to install a software called seppl. While > configuring i'm getting the following errors. > > checking iptables.h usability... yes > checking iptables.h presence... yes > checking for iptables.h... yes > checking for /lib/iptables... configure: error: *** > Sorry, failed to find iptables plugin directory *** > > can anyone tell how to overcome this I suggest you contact the seppl author(s). We have no idea what the configure script of this software tries to do. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/658fd087/attachment.pgp From laforge at netfilter.org Wed Apr 12 12:48:24 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 13:05:22 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <20060412083835.GN31616@sunbeam.de.gnumonks.org> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> <44381584.4020109@trash.net> <20060412083835.GN31616@sunbeam.de.gnumonks.org> Message-ID: <20060412104824.GU31616@sunbeam.de.gnumonks.org> On Wed, Apr 12, 2006 at 10:38:36AM +0200, Harald Welte wrote: > not for the bit, but in general we would need one, otherwise we have an > (extremely large) timer entry per conntrack... Sorry, I read the wrong version of the patch. Ignore that comment ;) I don't think we need a config option, but actually could enable this statically. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/2cb19b18/attachment.pgp From laforge at netfilter.org Wed Apr 12 15:10:09 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 15:27:14 2006 Subject: Could you please update the Netfilter Extensions HOWTO ? In-Reply-To: References: Message-ID: <20060412131009.GF31616@sunbeam.de.gnumonks.org> On Wed, Apr 12, 2006 at 02:34:54PM +0200, Ing. BcA. Ivan Dolezal wrote: > this may sound stupid but could you please update the Netfilter > Extensions HOWTO? It says something about using CVS which doesn't work. I > found somewhere in a mailing list that I should use Subversion. When I > downloaded the stuff, I was confused from more patch-o-matics. It all made > me quite disgusted... > > I do appreciate your work, but its usefulness goes down with smoothness > of usage. The extensions HOWTO (which was contributed to netfilter.org) was abandoned by its original author, as it seems. A volunteer project lives from contributions by volunteers. The netfilter core team is mostly busy with development tasks and with keeping the project running. There's no time left for any kind of documentation, I fear. We don't even have a webmaster - the core developers themselves are taking care of that (involuntarily). The only non-technical project member we have is Travis, our listmaster. > Did you guys think of transfering docs to wiki? A wiki needs somebody who takes care of the maintenance. Otherwise you get problems with inaccurate information, spam and the like. So whether a wiki or old-style HOWTOS: Somebody needs to take care. Unless we see more people volunteering in the area of documentation, I don't think this is going to change, sorry. Cheers, -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/8219dc62/attachment.pgp From varun at rocsys.com Wed Apr 12 15:54:47 2006 From: varun at rocsys.com (varun) Date: Wed Apr 12 16:04:39 2006 Subject: iptables doubt Message-ID: <443D06A7.1060504@rocsys.com> Hi all, Iam new to netfilters and iam trying to play around to understand a few things. By default when no policies are specified then it allows all traffic to go out and in to the n/w. I want to change this to default as deny. That is when there is no policy all should be default deny. So in order to achieve that i tried to change the code a little. In the file iptable_filter.c there is a variable called static int forward = NF_ACCEPT I changed this to NF_DROP and when i compiled and used it sure i was not able to send any or recv any packets but even after i give a policy like iptables -t filter -A INPUT -j ACCEPT Nothing changes. So achieve what i want what should i do? And where do i change? Another thing is that in normally when i put a policy like iptables -t filter -A OUTPUT -j REJECT Even my own self IP doesnt ping? Why should this happen? Isint it ok to ping local ip and loopback ip? If i want such implementation where i should be able to ping to self and local but not any other ip? Is it possible? I dont want to add policies rather is it possible just by changing the iptables kernel code? Please help me on this? Varun From laforge at netfilter.org Wed Apr 12 16:34:27 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Apr 12 16:51:28 2006 Subject: Could you please update the Netfilter Extensions HOWTO ? In-Reply-To: References: <20060412131009.GF31616@sunbeam.de.gnumonks.org> Message-ID: <20060412143427.GK31616@sunbeam.de.gnumonks.org> On Wed, Apr 12, 2006 at 03:39:57PM +0200, Ing. BcA. Ivan Dolezal wrote: > Do you think there is something that a total non-developer can do for the > documentatiton project (in exchange for the prestigious e-mail > @netfilter.org) ? well, documentation can actually be written by any user who has managed to successfully use the particular to-be-documented software. So every (power-)user is a potential candidate for writing/maintaining/updating documentation. Patches against the XML/SGLM master documents in the 'documentation' subtree of svn.netfilter.org are _always_ welcome. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060412/ffdaa5cc/attachment.pgp From kaber at trash.net Wed Apr 12 20:14:13 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 12 20:33:49 2006 Subject: [RFC: 2.6 patch] the overdue removal of ip{,6}_queue In-Reply-To: <20060411182624.GD31616@sunbeam.de.gnumonks.org> References: <20060409180105.GK8454@stusta.de> <44395505.1070608@trash.net> <20060411090139.GI5167@rama.linbit> <443BC06A.8020103@trash.net> <20060411182624.GD31616@sunbeam.de.gnumonks.org> Message-ID: <443D4375.2060105@trash.net> Harald Welte wrote: > On Tue, Apr 11, 2006 at 04:42:50PM +0200, Patrick McHardy wrote: > >>I think we need to do two things: >> >>- make libipq_compat a drop-in replacement that doesn't require >> recompilation > > > libipq is not distributed as a shared library (at least not by us), so I > don't see any purpose for doing so. Do you think anyone is going to > re-link statically linked code against the new lib I wasn't aware of that. That makes it even worse, old applications will break and we can't do anything about it. I think this is normally considered not acceptable. From kaber at trash.net Wed Apr 12 20:30:59 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 12 20:50:39 2006 Subject: [PATCH 4/4] first conntrack ID must be 1 not 2 In-Reply-To: <443CA579.3030908@ufomechanic.net> References: <43F43FA9.4000906@trash.net> <43F4426D.9060807@trash.net> <43F4DBDF.9010008@trash.net> <442B9765.2020105@ufomechanic.net> <442C81A6.3040501@trash.net> <442D78A8.4050300@trash.net> <20060401193138.GG11031@sunbeam.de.gnumonks.org> <4434F53A.2030302@trash.net> <443BD4BB.7090806@ufomechanic.net> <443BD6B3.8020607@trash.net> <443CA579.3030908@ufomechanic.net> Message-ID: <443D4763.40903@trash.net> Amin Azez wrote: > Patrick McHardy wrote: > >>> It's no longer the entry of the next conntrack but the entry of the last >>> conntrack by the time it gets deleted then...? Or have I misunderstood >>> the way in which the loop would occur? >>> >> >> >> Yes, the loop is interrupted when the skb is full and continued when >> userspace issues the next recvmsg(). The reference is kept to find >> the point where to continue. >> >> > Did you mean "yes, you misunderstood" or "yes, good idea"? Yes, you misunderstood :) > I thought that what would theoretically cause the problem if the > next-conntrack is deleted was the fact that conntrack-put is called > before ctnetlink_fill_info. Its only a marker, once we have found it in the list we don't need that reference anymore. > The problem may not be entirely theoretical if the conntrack is being > deleted by a userspace conntrack client in response to what it reads > when enumerating conntracks. (The conntrack may spring back into > existance as an resurrected established connection - and also may > therefore be likely in the case of a full contrack table where > connections flip-flop their resurrected conntrack entry, > Rather than issue warnings to conntrack developers to avoid certain > kinds of design, it would be better to avoid this. The marker points to the next entry that beed dumped yet, so enumerate-and-delete won't affect it. It is also not the ID of the connection but the pointer to the conntrack entry that is used, so resurrections don't affect it in any way. The problem is in my opinion purely theoretical so far: - the bucket beeing dumped must contain enough entries to exceed the size of a single netlink message (very unlikely) - when continuing to dump, the entry we wanted to dump next must be gone - and there must still be enough entries in the bucket to exceed the skb. For an endless loop we must have a steady refill of the bucket with new conntrack entries, otherwise at some point it won't exceed the skb anymore and we can move on to the next bucket. The jenkins hash should prevent this situation. From kaber at trash.net Wed Apr 12 20:57:49 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 12 21:17:26 2006 Subject: nth, random and fuzzy match In-Reply-To: <20060412084719.GP31616@sunbeam.de.gnumonks.org> References: <4435559A.60904@trash.net> <20060412084719.GP31616@sunbeam.de.gnumonks.org> Message-ID: <443D4DAD.4040908@trash.net> Harald Welte wrote: > On Thu, Apr 06, 2006 at 07:53:30PM +0200, Patrick McHardy wrote: > >>So my questions to the nth users: is anyone using the nth >>match in a way that can't be done by just matching on every >>nth packet with an optional starting point? > > > I suggest posting this to the users mailinglist, since the question is > addressed to users :) I already decided for myself, the functionality is not affected by removing the shared counters, it just needs to be used slightly different in some cases. From kaber at trash.net Wed Apr 12 21:06:54 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Apr 12 21:26:30 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <20060412104824.GU31616@sunbeam.de.gnumonks.org> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> <44381584.4020109@trash.net> <20060412083835.GN31616@sunbeam.de.gnumonks.org> <20060412104824.GU31616@sunbeam.de.gnumonks.org> Message-ID: <443D4FCE.2030802@trash.net> Harald Welte wrote: > I don't think we need a config option, but actually could enable this > statically. OK, I'm going to queue this for 2.6.18 then. Eric, can you please add nf_conntrack support and repost the entire patchset? Thanks. From jay.hester at khaletech.com Wed Apr 12 23:03:11 2006 From: jay.hester at khaletech.com (Jay Hester) Date: Wed Apr 12 23:20:15 2006 Subject: c++ linking problems Message-ID: <443D6B0F.3050206@khaletech.com> Hello, This is probably something easy that i'm overlooking, but how do you link in netfilter_queue in to a c++ program? I've lightly modified the code in libnetfilter_queue-/utils/nfqnl_test.c to build a test program. When I try to compile the program i'm getting lots of linking errors like this: [jbhester@sidewinder src]$ make cd .. && /bin/sh /home/jbhester/projects/midevil/missing --run automake-1.9 --gnu src/Makefile cd .. && /bin/sh ./config.status src/Makefile depfiles config.status: creating src/Makefile config.status: executing depfiles commands g++ -g -O2 -o nfq_test nfq_test.o -lnetfilter_queue -lnfnetlink nfq_test.o: In function `main':/home/jbhester/projects/midevil/src/nfq_test.cpp:41: undefined reference to `nfq_open()' :/home/jbhester/projects/midevil/src/nfq_test.cpp:47: undefined reference to `nfq_unbind_pf(nfq_handle*, unsigned short)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:52: undefined reference to `nfq_bind_pf(nfq_handle*, unsigned short)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:57: undefined reference to `nfq_create_queue(nfq_handle*, unsigned short, int (*)(nfq_q_handle*, nfgenmsg*, nfq_data*, void*), void*)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:63: undefined reference to `nfq_set_mode(nfq_q_handle*, unsigned char, unsigned int)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:68: undefined reference to `nfq_nfnlh(nfq_handle*)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:69: undefined reference to `nfnl_fd(nfnl_handle*)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:73: undefined reference to `nfq_handle_packet(nfq_handle*, char*, int)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:77: undefined reference to `nfq_destroy_queue(nfq_q_handle*)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:80: undefined reference to `nfq_close(nfq_handle*)' nfq_test.o: In function `process':/home/jbhester/projects/midevil/src/nfq_test.cpp:19: undefined reference to `nfq_get_msg_packet_hdr(nfq_data*)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:24: undefined reference to `nfq_get_payload(nfq_data*, char**)' :/home/jbhester/projects/midevil/src/nfq_test.cpp:28: undefined reference to `nfq_set_verdict(nfq_q_handle*, unsigned int, unsigned int, unsigned int, unsigned char*)' collect2: ld returned 1 exit status make: *** [nfq_test] Error 1 I've tried lots of things like adding "nfq_test_LDADD = /usr/local/lib/libnetfilter_queue.[a|so]", and using the dynamic linking as a dso object, but nothing is working. Thanks ahead of time for the help. Jay From m at rtij.nl Thu Apr 13 08:44:04 2006 From: m at rtij.nl (Martijn Lievaart) Date: Thu Apr 13 09:01:09 2006 Subject: c++ linking problems In-Reply-To: <443D6B0F.3050206@khaletech.com> References: <443D6B0F.3050206@khaletech.com> Message-ID: <443DF334.1070705@rtij.nl> Jay Hester wrote: > Hello, > This is probably something easy that i'm overlooking, but how do > you link in netfilter_queue in to a c++ program? > > I've lightly modified the code in > libnetfilter_queue-/utils/nfqnl_test.c to build a test program. > When I try to compile the program i'm getting lots of linking errors > like this: > If you did: extern C { #include "netfilter_queue.h" // Or whatever C header #include "another_C_header.h" } I think it should work. M4 From laforge at netfilter.org Thu Apr 13 10:07:31 2006 From: laforge at netfilter.org (Harald Welte) Date: Thu Apr 13 10:24:34 2006 Subject: [PATCH] ip_queue: Print warning when deprecated interface is being used Message-ID: <20060413080731.GF22448@sunbeam.de.gnumonks.org> Hi Patrick! I better submit this via you, since I don't want to clash with what you have in your queue for DaveM... [NETFILTER] ip_queue: Print warning when deprecated interface is being used Every time a process binds to ip_queue, this will print a KERN_WARNING message to inform the user that the process is using a deprecated interface, and that it should migrate to the new nfnetlink_queue interface. Also, we extend the deadline for ip_queue removal till December 2006. Signed-off-by: Harald Welte --- commit 73719a89c574bcda13d13cbec3aba672219988bb tree 850bb876c175642cb86ee603cb05962f5b4bfae0 parent 3599bbbe2873942dcc68bc50dec7a91868373654 author Harald Welte Thu, 13 Apr 2006 10:05:56 +0200 committer Harald Welte Thu, 13 Apr 2006 10:05:56 +0200 Documentation/feature-removal-schedule.txt | 2 +- net/ipv4/netfilter/ip_queue.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 293fed1..2ed657c 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -97,7 +97,7 @@ Who: Dominik Brodowski --------------------------- What: ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue) -When: December 2005 +When: December 2006 Why: This interface has been obsoleted by the new layer3-independent "nfnetlink_queue". The Kernel interface is compatible, so the old ip[6]tables "QUEUE" targets still work and will transparently handle diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c index b93f049..d58d5d6 100644 --- a/net/ipv4/netfilter/ip_queue.c +++ b/net/ipv4/netfilter/ip_queue.c @@ -520,6 +520,9 @@ ipq_rcv_skb(struct sk_buff *skb) } else { net_enable_timestamp(); peer_pid = pid; + printk(KERN_WARNING "process with PID %u uses deprecated " + "ip_queue interface. Please migrate to " + "nfnetlink_queue\n", pid); } write_unlock_bh(&queue_lock); -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- 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/20060413/a4e1ab0d/attachment.pgp From standel at info.ucl.ac.be Thu Apr 13 12:14:28 2006 From: standel at info.ucl.ac.be (Sebastien Tandel) Date: Thu Apr 13 12:31:55 2006 Subject: iptables doubt Message-ID: <443E2484.6020301@info.ucl.ac.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, varun wrote: > Hi all, > > Iam new to netfilters and iam trying to play around to > understand a few things. By default when no policies are specified then > it allows all traffic to go out and in to the n/w. I want to change this > to default as deny. > That is when there is no policy all should be default deny. > > So in order to achieve that i tried to change the code a little. > In the file iptable_filter.c there is a variable called > static int forward = NF_ACCEPT > I changed this to NF_DROP and when i compiled and used it > sure i was not able to send any or recv any packets I think you made the right change in your code in order to have a DROP policy by default in your netfilter. the problem is just after ... > but even after i give a policy like iptables -t filter -A > INPUT -j ACCEPT > Nothing changes. So achieve what i want what should i do? > And where do i change? It is quiet normal as you told netfilter to accept incoming packets but you did not configure netfilter to accept *outgoing* packets ... iptables -t filter -A OUTPUT -j ACCEPT > > Another thing is that in normally when i put a policy like > iptables -t filter -A OUTPUT -j REJECT > Even my own self IP doesnt ping? Why should this happen? > Isint it ok to ping local ip and loopback ip? > If i want such implementation where i should be able to > ping to self and local but not any other ip? > Is it possible? lo is the interface allotted to your local interface (i.e. your host)! You must therefore create two rules in order to let netfilter accept outgoing and incoming packets from and arriving to your local interface. iptables -A INPOUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT > I dont want to add policies rather is it possible just by > changing the iptables kernel code? You have to initialize netfilter by adding two static rules implementing the ones described here above. sta -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPiSEw76McB8jGxkRAhzNAJoCC6FwR6PvmEJG8IzNXeod29u8jQCdFPY7 N9fguzx+i6R9s+sCpz+AHfc= =120L -----END PGP SIGNATURE----- From yasuyuki.kozakai at toshiba.co.jp Thu Apr 13 14:00:50 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Apr 13 14:18:09 2006 Subject: [PATCH 0/2] cleanup for nf_conntrack Message-ID: <200604131200.k3DC0pv0028042@toshiba.co.jp> Hi, Patrick, Please consider to apply following patches on top of previous patch for refcount. [PATCH 1/2] nf_conntrack: kill nf_ct_cache_mutex [PATCH 2/2] nf_conntrack: kill unused callback init_conntrack -- Yasuyuki Kozakai From yasuyuki.kozakai at toshiba.co.jp Thu Apr 13 14:01:34 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Apr 13 14:18:45 2006 Subject: [PATCH 1/2] nf_conntrack: kill nf_ct_cache_mutex Message-ID: <200604131201.k3DC1ZME006314@toshiba.co.jp> [NETFILTER] nf_conntrack: kill nf_ct_cache_mutex This kills the mutex 'nf_ct_cache_mutex' which prevents creating slab caches simultaneously. Instead, the spinlock 'nf_ct_cache_lock' can prevent registering them simultaneously. The loser to get spinlock have to free slab cache, but it isn't so bad because it's rare case that multiple helper are loaded simultaneously. Signed-off-by: Yasuyuki Kozakai --- commit 9fdf8935c0caf14b90cd1061ec15e35fcdb85c3d tree da3bb945b9704f9843dea2c3d313a7867d43aedc parent 4d28baa8a1bdf97cb19dc633624d1a2715ef5d3e author Thu, 13 Apr 2006 20:24:27 +0900 committer Thu, 13 Apr 2006 20:24:27 +0900 net/netfilter/nf_conntrack_core.c | 60 +++++++++++++++---------------------- 1 files changed, 24 insertions(+), 36 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -186,9 +186,6 @@ static struct { /* protect members of nf_ct_cache except of "use" */ DEFINE_RWLOCK(nf_ct_cache_lock); -/* This avoids calling kmem_cache_create() with same name simultaneously */ -static DEFINE_MUTEX(nf_ct_cache_mutex); - extern struct nf_conntrack_protocol nf_conntrack_generic_protocol; struct nf_conntrack_protocol * __nf_ct_proto_find(u_int16_t l3proto, u_int8_t protocol) @@ -305,27 +302,6 @@ int nf_conntrack_register_cache(u_int32_ return -EINVAL; } - mutex_lock(&nf_ct_cache_mutex); - - write_lock_bh(&nf_ct_cache_lock); - /* e.g: multiple helpers are loaded */ - if (nf_ct_cache[features].use > 0) { - DEBUGP("nf_conntrack_register_cache: already resisterd.\n"); - if ((!strncmp(nf_ct_cache[features].name, name, - NF_CT_FEATURES_NAMELEN)) - && nf_ct_cache[features].size == size) { - DEBUGP("nf_conntrack_register_cache: reusing.\n"); - nf_ct_cache[features].use++; - ret = 0; - } else - ret = -EBUSY; - - write_unlock_bh(&nf_ct_cache_lock); - mutex_unlock(&nf_ct_cache_mutex); - return ret; - } - write_unlock_bh(&nf_ct_cache_lock); - /* * The memory space for name of slab cache must be alive until * cache is destroyed. @@ -333,8 +309,7 @@ int nf_conntrack_register_cache(u_int32_ cache_name = kmalloc(sizeof(char)*NF_CT_FEATURES_NAMELEN, GFP_ATOMIC); if (cache_name == NULL) { DEBUGP("nf_conntrack_register_cache: can't alloc cache_name\n"); - ret = -ENOMEM; - goto out_up_mutex; + return -ENOMEM; } if (strlcpy(cache_name, name, NF_CT_FEATURES_NAMELEN) @@ -344,8 +319,7 @@ int nf_conntrack_register_cache(u_int32_ goto out_free_name; } - cachep = kmem_cache_create(cache_name, size, 0, 0, - NULL, NULL); + cachep = kmem_cache_create(cache_name, size, 0, 0, NULL, NULL); if (!cachep) { printk("nf_conntrack_register_cache: Can't create slab cache " "for the features = 0x%x\n", features); @@ -354,18 +328,37 @@ int nf_conntrack_register_cache(u_int32_ } write_lock_bh(&nf_ct_cache_lock); + + /* e.g: multiple helpers are loaded */ + if (nf_ct_cache[features].use > 0) { + DEBUGP("nf_conntrack_register_cache: already resisterd.\n"); + if ((!strncmp(nf_ct_cache[features].name, name, + NF_CT_FEATURES_NAMELEN)) + && nf_ct_cache[features].size == size) { + DEBUGP("nf_conntrack_register_cache: reusing.\n"); + nf_ct_cache[features].use++; + ret = 0; + } else + ret = -EBUSY; + + write_unlock_bh(&nf_ct_cache_lock); + goto out_free_cache; + } + nf_ct_cache[features].use = 1; nf_ct_cache[features].size = size; nf_ct_cache[features].cachep = cachep; nf_ct_cache[features].name = cache_name; + write_unlock_bh(&nf_ct_cache_lock); - goto out_up_mutex; + return 0; +out_free_cache: + kmem_cache_destroy(cachep); out_free_name: kfree(cache_name); -out_up_mutex: - mutex_unlock(&nf_ct_cache_mutex); + return ret; } @@ -380,12 +373,10 @@ void nf_conntrack_unregister_cache(u_int * slab cache. */ DEBUGP("nf_conntrack_unregister_cache: 0x%04x\n", features); - mutex_lock(&nf_ct_cache_mutex); write_lock_bh(&nf_ct_cache_lock); if (--nf_ct_cache[features].use > 0) { write_unlock_bh(&nf_ct_cache_lock); - mutex_unlock(&nf_ct_cache_mutex); return; } cachep = nf_ct_cache[features].cachep; @@ -399,8 +390,6 @@ void nf_conntrack_unregister_cache(u_int kmem_cache_destroy(cachep); kfree(name); - - mutex_unlock(&nf_ct_cache_mutex); } int @@ -1435,7 +1424,6 @@ void __nf_ct_refresh_acct(struct nf_conn #include #include -#include /* Generic function for tcp/udp/sctp/dccp and alike. This needs to be From yasuyuki.kozakai at toshiba.co.jp Thu Apr 13 14:01:47 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Apr 13 14:19:00 2006 Subject: [PATCH 2/2] nf_conntrack: kill unused callback init_conntrack Message-ID: <200604131201.k3DC1m4I028628@toshiba.co.jp> [NETFILTER] nf_conntrack: kill unused callback init_conntrack Signed-off-by: Yasuyuki Kozakai --- commit f1564c6e1adcdc14d7e1ab29bafcb9938dc505ea tree bfb20cb9067537f117785eff788f806d0c3da0a0 parent 783e57517c558ae41171d71496035c08f2e9613c author Yasuyuki Kozakai Thu, 06 Apr 2006 19:00:12 +0900 committer Yasuyuki Kozakai Thu, 13 Apr 2006 15:05:26 +0900 net/netfilter/nf_conntrack_core.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 9a2410d..cb423c3 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -178,9 +178,6 @@ static struct { /* allocated slab cache + modules which uses this slab cache */ int use; - /* Initialization */ - int (*init_conntrack)(struct nf_conn *, u_int32_t); - } nf_ct_cache[NF_CT_F_NUM]; /* protect members of nf_ct_cache except of "use" */ From julien.valiente at objectif-software.com Wed Apr 12 23:23:13 2006 From: julien.valiente at objectif-software.com (Julien VALIENTE) Date: Thu Apr 13 14:19:47 2006 Subject: c++ linking problems In-Reply-To: <443D6B0F.3050206@khaletech.com> Message-ID: Hi, I met this kind of problem. I solved it with the use of a c++ 'extern C' around my include (tested with iptables-1.2.6a): extern "C" { #include #include } Regards, J. Valiente > -----Message d'origine----- > De : netfilter-devel-bounces@lists.netfilter.org > [mailto:netfilter-devel-bounces@lists.netfilter.org]De la part de Jay > Hester > Envoy? : mercredi 12 avril 2006 23:03 > ? : netfilter-devel@lists.netfilter.org > Objet : c++ linking problems > > > Hello, > This is probably something easy that i'm overlooking, but how do > you link in netfilter_queue in to a c++ program? > > I've lightly modified the code in > libnetfilter_queue-/utils/nfqnl_test.c to build a test program. > When I try to compile the program i'm getting lots of linking errors > like this: > > [jbhester@sidewinder src]$ make > cd .. && /bin/sh /home/jbhester/projects/midevil/missing --run > automake-1.9 --gnu src/Makefile > cd .. && /bin/sh ./config.status src/Makefile depfiles > config.status: creating src/Makefile > config.status: executing depfiles commands > g++ -g -O2 -o nfq_test nfq_test.o -lnetfilter_queue -lnfnetlink > nfq_test.o: In function > `main':/home/jbhester/projects/midevil/src/nfq_test.cpp:41: undefined > reference to `nfq_open()' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:47: undefined > reference to `nfq_unbind_pf(nfq_handle*, unsigned short)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:52: undefined > reference to `nfq_bind_pf(nfq_handle*, unsigned short)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:57: undefined > reference to `nfq_create_queue(nfq_handle*, unsigned short, int > (*)(nfq_q_handle*, nfgenmsg*, nfq_data*, void*), void*)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:63: undefined > reference to `nfq_set_mode(nfq_q_handle*, unsigned char, unsigned int)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:68: undefined > reference to `nfq_nfnlh(nfq_handle*)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:69: undefined > reference to `nfnl_fd(nfnl_handle*)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:73: undefined > reference to `nfq_handle_packet(nfq_handle*, char*, int)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:77: undefined > reference to `nfq_destroy_queue(nfq_q_handle*)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:80: undefined > reference to `nfq_close(nfq_handle*)' > nfq_test.o: In function > `process':/home/jbhester/projects/midevil/src/nfq_test.cpp:19: undefined > reference to `nfq_get_msg_packet_hdr(nfq_data*)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:24: undefined > reference to `nfq_get_payload(nfq_data*, char**)' > :/home/jbhester/projects/midevil/src/nfq_test.cpp:28: undefined > reference to `nfq_set_verdict(nfq_q_handle*, unsigned int, unsigned int, > unsigned int, unsigned char*)' > collect2: ld returned 1 exit status > make: *** [nfq_test] Error 1 > > > I've tried lots of things like adding "nfq_test_LDADD = > /usr/local/lib/libnetfilter_queue.[a|so]", and using the dynamic linking > as a dso object, but nothing is working. > > Thanks ahead of time for the help. > > Jay > > > From yasuyuki.kozakai at toshiba.co.jp Thu Apr 13 14:19:35 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Apr 13 14:36:43 2006 Subject: [PATCH 1/2] nf_conntrack: kill nf_ct_cache_mutex In-Reply-To: <200604131201.k3DC1ZME006314@toshiba.co.jp> References: <200604131201.k3DC1ZME006314@toshiba.co.jp> Message-ID: <200604131219.k3DCJZTO026135@toshiba.co.jp> Sorry, I cannot do this becase kmem_cache_create() with same name brings oops instead returning error. Please ignore this. -- Yasuyuki Kozakai From: Yasuyuki KOZAKAI Date: Thu, 13 Apr 2006 21:01:34 +0900 (JST) > [NETFILTER] nf_conntrack: kill nf_ct_cache_mutex > > This kills the mutex 'nf_ct_cache_mutex' which prevents creating > slab caches simultaneously. Instead, the spinlock 'nf_ct_cache_lock' can > prevent registering them simultaneously. > > The loser to get spinlock have to free slab cache, but it isn't so bad > because it's rare case that multiple helper are loaded simultaneously. > > Signed-off-by: Yasuyuki Kozakai > > --- > commit 9fdf8935c0caf14b90cd1061ec15e35fcdb85c3d > tree da3bb945b9704f9843dea2c3d313a7867d43aedc > parent 4d28baa8a1bdf97cb19dc633624d1a2715ef5d3e > author Thu, 13 Apr 2006 20:24:27 +0900 > committer Thu, 13 Apr 2006 20:24:27 +0900 > > net/netfilter/nf_conntrack_core.c | 60 +++++++++++++++---------------------- > 1 files changed, 24 insertions(+), 36 deletions(-) > > diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c > --- a/net/netfilter/nf_conntrack_core.c > +++ b/net/netfilter/nf_conntrack_core.c > @@ -186,9 +186,6 @@ static struct { > /* protect members of nf_ct_cache except of "use" */ > DEFINE_RWLOCK(nf_ct_cache_lock); > > -/* This avoids calling kmem_cache_create() with same name simultaneously */ > -static DEFINE_MUTEX(nf_ct_cache_mutex); > - > extern struct nf_conntrack_protocol nf_conntrack_generic_protocol; > struct nf_conntrack_protocol * > __nf_ct_proto_find(u_int16_t l3proto, u_int8_t protocol) > @@ -305,27 +302,6 @@ int nf_conntrack_register_cache(u_int32_ > return -EINVAL; > } > > - mutex_lock(&nf_ct_cache_mutex); > - > - write_lock_bh(&nf_ct_cache_lock); > - /* e.g: multiple helpers are loaded */ > - if (nf_ct_cache[features].use > 0) { > - DEBUGP("nf_conntrack_register_cache: already resisterd.\n"); > - if ((!strncmp(nf_ct_cache[features].name, name, > - NF_CT_FEATURES_NAMELEN)) > - && nf_ct_cache[features].size == size) { > - DEBUGP("nf_conntrack_register_cache: reusing.\n"); > - nf_ct_cache[features].use++; > - ret = 0; > - } else > - ret = -EBUSY; > - > - write_unlock_bh(&nf_ct_cache_lock); > - mutex_unlock(&nf_ct_cache_mutex); > - return ret; > - } > - write_unlock_bh(&nf_ct_cache_lock); > - > /* > * The memory space for name of slab cache must be alive until > * cache is destroyed. > @@ -333,8 +309,7 @@ int nf_conntrack_register_cache(u_int32_ > cache_name = kmalloc(sizeof(char)*NF_CT_FEATURES_NAMELEN, GFP_ATOMIC); > if (cache_name == NULL) { > DEBUGP("nf_conntrack_register_cache: can't alloc cache_name\n"); > - ret = -ENOMEM; > - goto out_up_mutex; > + return -ENOMEM; > } > > if (strlcpy(cache_name, name, NF_CT_FEATURES_NAMELEN) > @@ -344,8 +319,7 @@ int nf_conntrack_register_cache(u_int32_ > goto out_free_name; > } > > - cachep = kmem_cache_create(cache_name, size, 0, 0, > - NULL, NULL); > + cachep = kmem_cache_create(cache_name, size, 0, 0, NULL, NULL); > if (!cachep) { > printk("nf_conntrack_register_cache: Can't create slab cache " From standel at info.ucl.ac.be Thu Apr 13 14:24:06 2006 From: standel at info.ucl.ac.be (Sebastien Tandel) Date: Thu Apr 13 14:41:15 2006 Subject: iptables doubt In-Reply-To: <443E341F.1080206@rocsys.com> References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> Message-ID: <443E42E6.2010405@info.ucl.ac.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 varun wrote: > Hi Sebastien, > > Thanx for the reply. Actually i did figure > out some things. It seems to work fine but iam not sure if may lead to > any problem. This is what i have done. > Instead of adding static routes what i have done is added this small > code in the function ipt_do_table. > > if(in == NULL) > goto jump; > if(memcmp(in->name,"lo",2) == 0) > { > verdict = NF_ACCEPT; > return verdict; > } > > jump: > * We handle fragments by dealing with the first fragment as > * if it was a normal packet. All other fragments are treated > * normally, except that they will NEVER match rules that ask > * things we don't know, ie. tcp syn flag or ports). If the > * rule is also a fragment-specific rule, non-fragments won't > * match it. */ > offset = ntohs(ip->frag_off) & IP_OFFSET; It seems "good" modulo these changes to be more concise ... if (in != NULL && memcmp(in->name, "lo", 2) == 0) return NF_ACCEPT; * We handle fragments by dealing with the first fragment as * if it was a normal packet. All other fragments are treated * normally, except that they will NEVER match rules that ask * things we don't know, ie. tcp syn flag or ports). If the * rule is also a fragment-specific rule, non-fragments won't * match it. */ offset = ntohs(ip->frag_off) & IP_OFFSET; Note that you have done a shortcut that does not test the outgoing interface. It means that you can receive packets from another interface and going to the loopback address ... > With this every time a packet comes with IN dev as lo i would simply > accept. It seems ok and works well but is there any problem with it if i > do so? > IMHO, there is no pblm doing this way except that : 1) you have hardcoded the "rule" (half-hardcoded see remark here above) 2) there is no more option to change the behavior of the "rule" you just added (i.e. we can't reject anymore a packet going through the loopback interface) > Varun > > > > > > > > > Sebastien Tandel wrote: > > Hi, > varun wrote: > > >>>> Hi all, >>>> >>>> Iam new to netfilters and iam trying to play around to >>>> understand a few things. By default when no policies are specified then >>>> it allows all traffic to go out and in to the n/w. I want to change this >>>> to default as deny. >>>> That is when there is no policy all should be default deny. >>>> >>>> So in order to achieve that i tried to change the code a >>>> little. >>>> In the file iptable_filter.c there is a variable called >>>> static int forward = NF_ACCEPT >>>> I changed this to NF_DROP and when i compiled and used it >>>> sure i was not able to send any or recv any packets >>>> > > I think you made the right change in your code in order to have a DROP > policy by default in your netfilter. the problem is just after ... > > > >>>> but even after i give a policy like iptables -t filter -A >>>> INPUT -j ACCEPT >>>> Nothing changes. So achieve what i want what should i do? >>>> And where do i change? >>>> > > > It is quiet normal as you told netfilter to accept incoming packets but > you did not configure netfilter to accept *outgoing* packets ... > iptables -t filter -A OUTPUT -j ACCEPT > > > >>>> Another thing is that in normally when i put a policy like >>>> iptables -t filter -A OUTPUT -j REJECT >>>> Even my own self IP doesnt ping? Why should this happen? >>>> Isint it ok to ping local ip and loopback ip? >>>> If i want such implementation where i should be able to >>>> ping to self and local but not any other ip? >>>> Is it possible? >>>> > > > lo is the interface allotted to your local interface (i.e. your host)! > You must therefore create two rules in order to let netfilter accept > outgoing and incoming packets from and arriving to your local interface. > iptables -A INPOUT -i lo -j ACCEPT > iptables -A OUTPUT -o lo -j ACCEPT > > > > >>>> I dont want to add policies rather is it possible just by >>>> changing the iptables kernel code? >>>> > > > You have to initialize netfilter by adding two static rules implementing > the ones described here above. > > sta >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPkLmw76McB8jGxkRAsN0AJ4jZP6mhN2vk+/L93qy5uhC8WSJVwCfQpun Fc4d8NMUJo6M64QBMPTO/dg= =c7ol -----END PGP SIGNATURE----- From varun at rocsys.com Thu Apr 13 15:01:30 2006 From: varun at rocsys.com (varun) Date: Thu Apr 13 15:11:32 2006 Subject: iptables doubt In-Reply-To: <443E42E6.2010405@info.ucl.ac.be> References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> <443E42E6.2010405@info.ucl.ac.be> Message-ID: <443E4BAA.3020607@rocsys.com> Hi Sebastien, Thanx again. Yeah i cannot set a rule for lo. Though it is not necessary in my case i would like have that option. So is static rule only the way? Another thing is i want to implement rule priority. That is after the rules are set when a packet arrives it needs to search the rule chain. I want that to searched with respect to priority. So even the user can change the priority of already set rule as he likes. Is it already implemented in iptables or is it needed to be implemented? I also want to maintain unique rule id. That is say i declair unsigned int i; So for any rule be it nat or anything this is global rule id that is assigned to any policy added. By this say if a user added a rule whose id i give as 15. And then he deletes it then after adding another policy he will get policy id of 16 and not 15. rule no 15 will be given only after full size of unsigned int is completed, i mean one full circle (i = 0 to i=4294967295). So to do it how should i go about it? Any suggestions? Varun Sebastien Tandel wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >varun wrote: > > >>Hi Sebastien, >> >> Thanx for the reply. Actually i did figure >>out some things. It seems to work fine but iam not sure if may lead to >>any problem. This is what i have done. >>Instead of adding static routes what i have done is added this small >>code in the function ipt_do_table. >> >> if(in == NULL) >> goto jump; >> if(memcmp(in->name,"lo",2) == 0) >> { >> verdict = NF_ACCEPT; >> return verdict; >> } >> >>jump: >>* We handle fragments by dealing with the first fragment as >> * if it was a normal packet. All other fragments are treated >> * normally, except that they will NEVER match rules that ask >> * things we don't know, ie. tcp syn flag or ports). If the >> * rule is also a fragment-specific rule, non-fragments won't >> * match it. */ >> offset = ntohs(ip->frag_off) & IP_OFFSET; >> >> > >It seems "good" modulo these changes to be more concise ... > > if (in != NULL && memcmp(in->name, "lo", 2) == 0) > return NF_ACCEPT; > * We handle fragments by dealing with the first fragment as > * if it was a normal packet. All other fragments are treated > * normally, except that they will NEVER match rules that ask > * things we don't know, ie. tcp syn flag or ports). If the > * rule is also a fragment-specific rule, non-fragments won't > * match it. */ > offset = ntohs(ip->frag_off) & IP_OFFSET; > >Note that you have done a shortcut that does not test the outgoing >interface. It means that you can receive packets from another interface >and going to the loopback address ... > > > >>With this every time a packet comes with IN dev as lo i would simply >>accept. It seems ok and works well but is there any problem with it if i >>do so? >> >> >> > >IMHO, there is no pblm doing this way except that : > 1) you have hardcoded the "rule" (half-hardcoded see remark here above) > 2) there is no more option to change the behavior of the "rule" you >just added (i.e. we can't reject anymore a packet going through the >loopback interface) > > > > >>Varun >> >> >> >> >> >> >> >> >>Sebastien Tandel wrote: >> >>Hi, >>varun wrote: >> >> >> >> >>>>>Hi all, >>>>> >>>>> Iam new to netfilters and iam trying to play around to >>>>>understand a few things. By default when no policies are specified then >>>>>it allows all traffic to go out and in to the n/w. I want to change this >>>>>to default as deny. >>>>> That is when there is no policy all should be default deny. >>>>> >>>>> So in order to achieve that i tried to change the code a >>>>>little. >>>>> In the file iptable_filter.c there is a variable called >>>>>static int forward = NF_ACCEPT >>>>> I changed this to NF_DROP and when i compiled and used it >>>>>sure i was not able to send any or recv any packets >>>>> >>>>> >>>>> >>I think you made the right change in your code in order to have a DROP >>policy by default in your netfilter. the problem is just after ... >> >> >> >> >> >>>>> but even after i give a policy like iptables -t filter -A >>>>>INPUT -j ACCEPT >>>>> Nothing changes. So achieve what i want what should i do? >>>>>And where do i change? >>>>> >>>>> >>>>> >>It is quiet normal as you told netfilter to accept incoming packets but >>you did not configure netfilter to accept *outgoing* packets ... >>iptables -t filter -A OUTPUT -j ACCEPT >> >> >> >> >> >>>>> Another thing is that in normally when i put a policy like >>>>>iptables -t filter -A OUTPUT -j REJECT >>>>> Even my own self IP doesnt ping? Why should this happen? >>>>> Isint it ok to ping local ip and loopback ip? >>>>> If i want such implementation where i should be able to >>>>>ping to self and local but not any other ip? >>>>> Is it possible? >>>>> >>>>> >>>>> >>lo is the interface allotted to your local interface (i.e. your host)! >>You must therefore create two rules in order to let netfilter accept >>outgoing and incoming packets from and arriving to your local interface. >>iptables -A INPOUT -i lo -j ACCEPT >>iptables -A OUTPUT -o lo -j ACCEPT >> >> >> >> >> >> >>>>> I dont want to add policies rather is it possible just by >>>>>changing the iptables kernel code? >>>>> >>>>> >>>>> >>You have to initialize netfilter by adding two static rules implementing >>the ones described here above. >> >>sta >> >> > > > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.2 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFEPkLmw76McB8jGxkRAsN0AJ4jZP6mhN2vk+/L93qy5uhC8WSJVwCfQpun >Fc4d8NMUJo6M64QBMPTO/dg= >=c7ol >-----END PGP SIGNATURE----- > > > From standel at info.ucl.ac.be Thu Apr 13 15:16:36 2006 From: standel at info.ucl.ac.be (Sebastien Tandel) Date: Thu Apr 13 15:33:55 2006 Subject: iptables doubt In-Reply-To: <443E4BAA.3020607@rocsys.com> References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> <443E42E6.2010405@info.ucl.ac.be> <443E4BAA.3020607@rocsys.com> Message-ID: <443E4F34.10206@info.ucl.ac.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 varun wrote: > Hi Sebastien, > > Thanx again. Yeah i cannot set a rule for lo. > Though it is not necessary in my case i would like have that option. So > is static rule only the way? I think so ... Why do you want to code it directly in netfilter instead of using the init.d scripts? > Another thing is i want to implement rule > priority. > That is after the rules are set when a packet > arrives it needs to search the rule chain. I want that to searched with > respect to priority. So even the user can change the priority of already > set rule as he likes. Is it already implemented in iptables or is it > needed to be implemented? > > I also want to maintain unique rule id. That > is say i declair unsigned int i; > So for any rule be it nat or anything this > is global rule id that is assigned to any policy added. > By this say if a user added a rule whose id i > give as 15. And then he deletes it then after adding another policy he > will get policy id of 16 and not 15. rule no 15 will be given only after > full size of unsigned int is completed, i mean one full circle (i = 0 to > i=4294967295). So to do it how should i go about it? Any suggestions? > > Varun It is clearly not implemented and I haven't any clue for you on this matter but ... What will be the benefit of it? > Sebastien Tandel wrote: > > > varun wrote: > > >>>> Hi Sebastien, >>>> >>>> Thanx for the reply. Actually i did figure >>>> out some things. It seems to work fine but iam not sure if may lead to >>>> any problem. This is what i have done. >>>> Instead of adding static routes what i have done is added this small >>>> code in the function ipt_do_table. >>>> >>>> if(in == NULL) >>>> goto jump; >>>> if(memcmp(in->name,"lo",2) == 0) >>>> { >>>> verdict = NF_ACCEPT; >>>> return verdict; >>>> } >>>> >>>> jump: >>>> * We handle fragments by dealing with the first fragment as >>>> * if it was a normal packet. All other fragments are treated >>>> * normally, except that they will NEVER match rules that ask >>>> * things we don't know, ie. tcp syn flag or ports). If the >>>> * rule is also a fragment-specific rule, non-fragments won't >>>> * match it. */ >>>> offset = ntohs(ip->frag_off) & IP_OFFSET; >>>> > > > It seems "good" modulo these changes to be more concise ... > > if (in != NULL && memcmp(in->name, "lo", 2) == 0) > return NF_ACCEPT; > * We handle fragments by dealing with the first fragment as > * if it was a normal packet. All other fragments are treated > * normally, except that they will NEVER match rules that ask > * things we don't know, ie. tcp syn flag or ports). If the > * rule is also a fragment-specific rule, non-fragments won't > * match it. */ > offset = ntohs(ip->frag_off) & IP_OFFSET; > > Note that you have done a shortcut that does not test the outgoing > interface. It means that you can receive packets from another interface > and going to the loopback address ... > > > >>>> With this every time a packet comes with IN dev as lo i would simply >>>> accept. It seems ok and works well but is there any problem with it if i >>>> do so? >>>> >>>> > > > IMHO, there is no pblm doing this way except that : > 1) you have hardcoded the "rule" (half-hardcoded see remark here > above) > 2) there is no more option to change the behavior of the "rule" you > just added (i.e. we can't reject anymore a packet going through the > loopback interface) > > > > >>>> Varun >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Sebastien Tandel wrote: >>>> >>>> Hi, >>>> varun wrote: >>>> >>>> >>>> >>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Iam new to netfilters and iam trying to play around to >>>>>>> understand a few things. By default when no policies are specified >>>>>>> then >>>>>>> it allows all traffic to go out and in to the n/w. I want to >>>>>>> change this >>>>>>> to default as deny. >>>>>>> That is when there is no policy all should be default deny. >>>>>>> >>>>>>> So in order to achieve that i tried to change the code a >>>>>>> little. >>>>>>> In the file iptable_filter.c there is a variable called >>>>>>> static int forward = NF_ACCEPT >>>>>>> I changed this to NF_DROP and when i compiled and used it >>>>>>> sure i was not able to send any or recv any packets >>>>>>> >>>>>>> >>>> >>>> I think you made the right change in your code in order to have a DROP >>>> policy by default in your netfilter. the problem is just after ... >>>> >>>> >>>> >>>> >>>> >>>>>>> but even after i give a policy like iptables -t filter -A >>>>>>> INPUT -j ACCEPT >>>>>>> Nothing changes. So achieve what i want what should i do? >>>>>>> And where do i change? >>>>>>> >>>>>>> >>>> >>>> It is quiet normal as you told netfilter to accept incoming packets but >>>> you did not configure netfilter to accept *outgoing* packets ... >>>> iptables -t filter -A OUTPUT -j ACCEPT >>>> >>>> >>>> >>>> >>>> >>>>>>> Another thing is that in normally when i put a policy like >>>>>>> iptables -t filter -A OUTPUT -j REJECT >>>>>>> Even my own self IP doesnt ping? Why should this happen? >>>>>>> Isint it ok to ping local ip and loopback ip? >>>>>>> If i want such implementation where i should be able to >>>>>>> ping to self and local but not any other ip? >>>>>>> Is it possible? >>>>>>> >>>>>>> >>>> >>>> lo is the interface allotted to your local interface (i.e. your host)! >>>> You must therefore create two rules in order to let netfilter accept >>>> outgoing and incoming packets from and arriving to your local interface. >>>> iptables -A INPOUT -i lo -j ACCEPT >>>> iptables -A OUTPUT -o lo -j ACCEPT >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>> I dont want to add policies rather is it possible >>>>>>> just by >>>>>>> changing the iptables kernel code? >>>>>>> >>>>>>> >>>> >>>> You have to initialize netfilter by adding two static rules implementing >>>> the ones described here above. >>>> >>>> sta >>>> > > > > > > >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPk80w76McB8jGxkRAjzkAJ9v7l94tGG8mRCSq6MM5Fxf+K0zlQCglRX3 B3HeNfHiKBlHbUxNwgnqBzM= =9D0f -----END PGP SIGNATURE----- From varun at rocsys.com Thu Apr 13 15:53:42 2006 From: varun at rocsys.com (varun) Date: Thu Apr 13 16:03:46 2006 Subject: iptables doubt In-Reply-To: <443E4F34.10206@info.ucl.ac.be> References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> <443E42E6.2010405@info.ucl.ac.be> <443E4BAA.3020607@rocsys.com> <443E4F34.10206@info.ucl.ac.be> Message-ID: <443E57E6.8080005@rocsys.com> Hi Sebastien, Well i do not want to use policy from user space because , the very need for me to do this activity is to play around and get to understand netfilter iptables. The features i want to implement like that priority for policy is that imagine a scenario where user added some policies and then for some reason wants one policy to be checked before checking others then he would have to add the policy again and delete the old policy isint it? By the thanx for the help man and can you suggest me some good mailing list which deal with iptables development where newbies like me could get some help. This mailing list does not seem to help newbies much. Varun Sebastien Tandel wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >varun wrote: > > >>Hi Sebastien, >> >> Thanx again. Yeah i cannot set a rule for lo. >>Though it is not necessary in my case i would like have that option. So >>is static rule only the way? >> >> > >I think so ... > >Why do you want to code it directly in netfilter instead of using the >init.d scripts? > > > >> Another thing is i want to implement rule >>priority. >> That is after the rules are set when a packet >>arrives it needs to search the rule chain. I want that to searched with >>respect to priority. So even the user can change the priority of already >>set rule as he likes. Is it already implemented in iptables or is it >>needed to be implemented? >> >> I also want to maintain unique rule id. That >>is say i declair unsigned int i; >> So for any rule be it nat or anything this >>is global rule id that is assigned to any policy added. >> By this say if a user added a rule whose id i >>give as 15. And then he deletes it then after adding another policy he >>will get policy id of 16 and not 15. rule no 15 will be given only after >>full size of unsigned int is completed, i mean one full circle (i = 0 to >>i=4294967295). So to do it how should i go about it? Any suggestions? >> >>Varun >> >> > >It is clearly not implemented and I haven't any clue for you on this >matter but ... What will be the benefit of it? > > > >>Sebastien Tandel wrote: >> >> >>varun wrote: >> >> >> >> >>>>>Hi Sebastien, >>>>> >>>>> Thanx for the reply. Actually i did figure >>>>>out some things. It seems to work fine but iam not sure if may lead to >>>>>any problem. This is what i have done. >>>>>Instead of adding static routes what i have done is added this small >>>>>code in the function ipt_do_table. >>>>> >>>>> if(in == NULL) >>>>> goto jump; >>>>> if(memcmp(in->name,"lo",2) == 0) >>>>> { >>>>> verdict = NF_ACCEPT; >>>>> return verdict; >>>>> } >>>>> >>>>>jump: >>>>>* We handle fragments by dealing with the first fragment as >>>>> * if it was a normal packet. All other fragments are treated >>>>> * normally, except that they will NEVER match rules that ask >>>>> * things we don't know, ie. tcp syn flag or ports). If the >>>>> * rule is also a fragment-specific rule, non-fragments won't >>>>> * match it. */ >>>>> offset = ntohs(ip->frag_off) & IP_OFFSET; >>>>> >>>>> >>>>> >>It seems "good" modulo these changes to be more concise ... >> >> if (in != NULL && memcmp(in->name, "lo", 2) == 0) >> return NF_ACCEPT; >> * We handle fragments by dealing with the first fragment as >> * if it was a normal packet. All other fragments are treated >> * normally, except that they will NEVER match rules that ask >> * things we don't know, ie. tcp syn flag or ports). If the >> * rule is also a fragment-specific rule, non-fragments won't >> * match it. */ >> offset = ntohs(ip->frag_off) & IP_OFFSET; >> >>Note that you have done a shortcut that does not test the outgoing >>interface. It means that you can receive packets from another interface >>and going to the loopback address ... >> >> >> >> >> >>>>>With this every time a packet comes with IN dev as lo i would simply >>>>>accept. It seems ok and works well but is there any problem with it if i >>>>>do so? >>>>> >>>>> >>>>> >>>>> >>IMHO, there is no pblm doing this way except that : >> 1) you have hardcoded the "rule" (half-hardcoded see remark here >>above) >> 2) there is no more option to change the behavior of the "rule" you >>just added (i.e. we can't reject anymore a packet going through the >>loopback interface) >> >> >> >> >> >> >>>>>Varun >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>Sebastien Tandel wrote: >>>>> >>>>>Hi, >>>>>varun wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>>Hi all, >>>>>>>> >>>>>>>> Iam new to netfilters and iam trying to play around to >>>>>>>>understand a few things. By default when no policies are specified >>>>>>>>then >>>>>>>>it allows all traffic to go out and in to the n/w. I want to >>>>>>>>change this >>>>>>>>to default as deny. >>>>>>>> That is when there is no policy all should be default deny. >>>>>>>> >>>>>>>> So in order to achieve that i tried to change the code a >>>>>>>>little. >>>>>>>> In the file iptable_filter.c there is a variable called >>>>>>>>static int forward = NF_ACCEPT >>>>>>>> I changed this to NF_DROP and when i compiled and used it >>>>>>>>sure i was not able to send any or recv any packets >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>I think you made the right change in your code in order to have a DROP >>>>>policy by default in your netfilter. the problem is just after ... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>> but even after i give a policy like iptables -t filter -A >>>>>>>>INPUT -j ACCEPT >>>>>>>> Nothing changes. So achieve what i want what should i do? >>>>>>>>And where do i change? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>It is quiet normal as you told netfilter to accept incoming packets but >>>>>you did not configure netfilter to accept *outgoing* packets ... >>>>>iptables -t filter -A OUTPUT -j ACCEPT >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>> Another thing is that in normally when i put a policy like >>>>>>>>iptables -t filter -A OUTPUT -j REJECT >>>>>>>> Even my own self IP doesnt ping? Why should this happen? >>>>>>>> Isint it ok to ping local ip and loopback ip? >>>>>>>> If i want such implementation where i should be able to >>>>>>>>ping to self and local but not any other ip? >>>>>>>> Is it possible? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>lo is the interface allotted to your local interface (i.e. your host)! >>>>>You must therefore create two rules in order to let netfilter accept >>>>>outgoing and incoming packets from and arriving to your local interface. >>>>>iptables -A INPOUT -i lo -j ACCEPT >>>>>iptables -A OUTPUT -o lo -j ACCEPT >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>> I dont want to add policies rather is it possible >>>>>>>>just by >>>>>>>>changing the iptables kernel code? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>You have to initialize netfilter by adding two static rules implementing >>>>>the ones described here above. >>>>> >>>>>sta >>>>> >>>>> >>>>> >> >> >> >> >> >> > > > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.2 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFEPk80w76McB8jGxkRAjzkAJ9v7l94tGG8mRCSq6MM5Fxf+K0zlQCglRX3 >B3HeNfHiKBlHbUxNwgnqBzM= >=9D0f >-----END PGP SIGNATURE----- > > > From standel at info.ucl.ac.be Thu Apr 13 16:16:27 2006 From: standel at info.ucl.ac.be (Sebastien Tandel) Date: Thu Apr 13 16:33:39 2006 Subject: iptables doubt In-Reply-To: <443E57E6.8080005@rocsys.com> References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> <443E42E6.2010405@info.ucl.ac.be> <443E4BAA.3020607@rocsys.com> <443E4F34.10206@info.ucl.ac.be> <443E57E6.8080005@rocsys.com> Message-ID: <443E5D3B.7000608@info.ucl.ac.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, varun wrote: > Hi Sebastien, > > Well i do not want to use policy from user space > because , the very need for me to do this activity is to play around and > get to understand netfilter iptables. ok ... that's the point :) > > The features i want to implement like that > priority for policy is that imagine a scenario where user added some > policies and then for some reason wants one policy to be checked before > checking others then he would have to add the policy again and delete > the old policy isint it? Yes it is correct ... even if this may seem curious I think it is not the worth to add such a mechanism to netfilter. IMHO, a switch option '-M' (MOVE) would be sufficient but not with all these unique-id's ... I fear that with the time this number list would be completely fragmented and human-unreadable I don't know wether it had already been discussed on this mailing-list. IMHO, it is not a strong requirement for iptables/netfilter and this situation may be handled in a semi-automatic way with a user script (with the danger, however, of having a race condition with another user script changing netfilter too). Of course, if it is another exercise to play with netfilter do it and have fun ;) > By the thanx for the help man and can you > suggest me some good mailing list which deal with iptables development > where newbies like me could get some help. This mailing list does not > seem to help newbies much. Unfortunately, I don't know any other mailing list devoted to netfilter. :-/ sta -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPl07w76McB8jGxkRAi5cAJ0TPTCHg3ENQtf/7OMS8NQvlfqglgCfUkJp GMvcI8Bety73ooSHNMQM/3I= =ztZe -----END PGP SIGNATURE----- From haegar at sdinet.de Thu Apr 13 18:04:41 2006 From: haegar at sdinet.de (Sven-Haegar Koch) Date: Thu Apr 13 18:21:47 2006 Subject: iptables doubt In-Reply-To: <443E57E6.8080005@rocsys.com> References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> <443E42E6.2010405@info.ucl.ac.be> <443E4BAA.3020607@rocsys.com> <443E4F34.10206@info.ucl.ac.be> <443E57E6.8080005@rocsys.com> Message-ID: On Thu, 13 Apr 2006, varun wrote: > The features i want to implement like that priority > for policy is that imagine a scenario where user added some policies and then > for some reason wants one policy to be checked before checking others then he > would have to add the policy again and delete the old policy isint it? Every iptables rule change is loading the whole ruleset into userspace, modifying it, and copying the result back into kernelspace. So you should be able to fetch the rules (f.e. with iptables-save), modify them as you like, and push them back (iptables-restore). c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) From eric at inl.fr Thu Apr 13 18:17:46 2006 From: eric at inl.fr (Eric Leblond) Date: Thu Apr 13 18:34:55 2006 Subject: [PATCH 1/3] [kernel patch] fixed duration connection In-Reply-To: <443D4FCE.2030802@trash.net> References: <1144139619.5186.24.camel@localhost.localdomain> <4433CCBF.6060103@trash.net> <4436DF6B.4060208@inl.fr> <4436E03E.9030402@inl.fr> <44381584.4020109@trash.net> <20060412083835.GN31616@sunbeam.de.gnumonks.org> <20060412104824.GU31616@sunbeam.de.gnumonks.org> <443D4FCE.2030802@trash.net> Message-ID: <56883.194.167.18.244.1144945066.squirrel@mail.inl.fr> > Harald Welte wrote: >> I don't think we need a config option, but actually could enable this >> statically. > > OK, I'm going to queue this for 2.6.18 then. That's a GREAT news, I've already found peoples that love this new feature. > > Eric, can you please add nf_conntrack support and repost the entire > patchset? Thanks. Here it is. I've done if (test_bit(IPS_FIXED_TIMEOUT_BIT, &ct->status)){ write_unlock_bh(&ip_conntrack_lock); return; } to unlock before leaving the function. Best regards, -- Eric Leblond -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed_timeout-flag.patch Type: text/x-patch Size: 2117 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20060413/cab17396/fixed_timeout-flag.bin From standel at info.ucl.ac.be Thu Apr 13 18:57:20 2006 From: standel at info.ucl.ac.be (Sebastien Tandel) Date: Thu Apr 13 19:14:30 2006 Subject: iptables doubt Message-ID: <443E82F0.5020102@info.ucl.ac.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sven-Haegar Koch wrote: > On Thu, 13 Apr 2006, varun wrote: > >> The features i want to implement like that >> priority for policy is that imagine a scenario where user added some >> policies and then for some reason wants one policy to be checked >> before checking others then he would have to add the policy again and >> delete the old policy isint it? > > > Every iptables rule change is loading the whole ruleset into userspace, > modifying it, and copying the result back into kernelspace. > > So you should be able to fetch the rules (f.e. with iptables-save), > modify them as you like, and push them back (iptables-restore). > > c'ya > sven > which is not robust when competing with another user script doing some change to netfilter ... i.e. there is no function doing an atomic move. sta -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPoLww76McB8jGxkRAs7AAJ9ICzjiB1J/V82UIOsqyKT9AyeGMQCgjiMd Maq9ku/nKaaXv81wdGd+zU8= =2j+D -----END PGP SIGNATURE----- From standel at info.ucl.ac.be Thu Apr 13 19:13:49 2006 From: standel at info.ucl.ac.be (Sebastien Tandel) Date: Thu Apr 13 19:30:56 2006 Subject: HOWTO Translation : netfilter double NAT [french] Message-ID: <443E86CD.5070609@info.ucl.ac.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I've translated the netfilter Double NAT mini-howto in french ... see you, sta -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPobNw76McB8jGxkRAtMTAJ46wfWYN5HCQS0E0MGN8hDMyIRfwgCeP5+B iSFIypgyMV10B1mw1nP9j/g= =Fmea -----END PGP SIGNATURE----- From standel at info.ucl.ac.be Thu Apr 13 19:15:06 2006 From: standel at info.ucl.ac.be (Sebastien Tandel) Date: Thu Apr 13 19:32:17 2006 Subject: HOWTO Translation : netfilter double NAT [french] [with attach] :) Message-ID: <443E871A.3050009@info.ucl.ac.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I've translated the netfilter Double NAT mini-howto in french ... see you, sta -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPocaw76McB8jGxkRAim7AKCEr/eZs9KdicFS/ZjHZT9oLxtXKQCfZe7r vUFRw7xHi8SOmi+EovQn/2I= =Xx8m -----END PGP SIGNATURE----- From yasuyuki.kozakai at toshiba.co.jp Fri Apr 14 03:02:00 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 14 03:19:30 2006 Subject: [PATCH 2/4] kill manually comparing protocol name with "ipv6-icmp" In-Reply-To: <443A493A.5030307@ufomechanic.net> References: <200604071131.k37BVY3F025271@toshiba.co.jp> <443A493A.5030307@ufomechanic.net> Message-ID: <200604140102.k3E121Xd027817@toshiba.co.jp> From: Amin Azez Date: Mon, 10 Apr 2006 13:02:02 +0100 > Yasuyuki KOZAKAI wrote: > > [IP6TABLES] kill manually comparing protocol name with "ipv6-icmp" > > > > This adds "ipv6-icmp" to chain_protos[] and kill manually comparing > > the argument of '-p' with it. > > > > chain_protos[] has the "icmpv6" with the same protocol number, but it's > > OK because proto_to_name() returns the firstly matched entry "icmpv6" > > as ever. > > I'm uncomfortable with having proto names in source code anyway, to me > it clashes horribly with getprotobyname and friends which for historical > and bizarre reasons might be looked up centrally (using nss) via ldap !! > > However I guess history also shows that protocol names have been stable > over the years :-) so what can I say? For ease to use and to avoid confusing, I'm comfortable with having protocol names until stable name of them are spread widely. For example, /etc/protocols in Fedora Core 5 is based on RFC1340, which was obsoleted (Currently protocol name list is published by IANA: http://www.iana.org). It includes "ipv6-crypt" and "ipv6-auth", they ware replaced with "esp" and "ah" in IANA list. On the other hand, I heard Debian has later names (correct ?). It's better to push distributors to update /etc/protocols if people want to use later names without hard coding in the future. About other protocol names (tcp, udp, ...), I don't know detail reason to keep them in iptables. I imagine it's such as guarantee of usability. -- Yasuyuki Kozakai From yasuyuki.kozakai at toshiba.co.jp Fri Apr 14 03:50:41 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Apr 14 04:07:55 2006 Subject: [PATCH IP{, 6}TABLES 0/4] fix loading icmpv6 module and minor changes In-Reply-To: <20060412104318.GS31616@sunbeam.de.gnumonks.org> References: <200604071130.k37BUBa3009024@toshiba.co.jp> <20060412104318.GS31616@sunbeam.de.gnumonks.org> Message-ID: <200604140150.k3E1ogT9004197@toshiba.co.jp> From: Harald Welte Date: Wed, 12 Apr 2006 12:43:18 +0200 > ah, ok. pleaes ignore my comment from a couple of minutes ago. Please > commit at least simple fixes like this immediately in the future. > > The changes are visible in the changelog (netfilter-cvslog mailinglist), > and if there really are any problems with a change, we can always fix > it incrementally. OK, and thanks for some commits. -- Yasuyuki Kozakai From varun at rocsys.com Fri Apr 14 05:33:46 2006 From: varun at rocsys.com (varun) Date: Fri Apr 14 05:43:50 2006 Subject: iptables doubt In-Reply-To: References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> <443E42E6.2010405@info.ucl.ac.be> <443E4BAA.3020607@rocsys.com> <443E4F34.10206@info.ucl.ac.be> <443E57E6.8080005@rocsys.com> Message-ID: <443F181A.6070506@rocsys.com> Yeah it is true but this can done only after safe but not dynamically? Is there a way to do dynamically? Varun Sven-Haegar Koch wrote: > On Thu, 13 Apr 2006, varun wrote: > >> The features i want to implement like that >> priority for policy is that imagine a scenario where user added some >> policies and then for some reason wants one policy to be checked >> before checking others then he would have to add the policy again and >> delete the old policy isint it? > > > Every iptables rule change is loading the whole ruleset into > userspace, modifying it, and copying the result back into kernelspace. > > So you should be able to fetch the rules (f.e. with iptables-save), > modify them as you like, and push them back (iptables-restore). > > c'ya > sven > From varun at rocsys.com Fri Apr 14 05:42:24 2006 From: varun at rocsys.com (varun) Date: Fri Apr 14 05:52:21 2006 Subject: iptables doubt In-Reply-To: <443E5D3B.7000608@info.ucl.ac.be> References: <443D06A7.1060504@rocsys.com> <443E21C1.9090508@info.ucl.ac.be> <443E341F.1080206@rocsys.com> <443E42E6.2010405@info.ucl.ac.be> <443E4BAA.3020607@rocsys.com> <443E4F34.10206@info.ucl.ac.be> <443E57E6.8080005@rocsys.com> <443E5D3B.7000608@info.ucl.ac.be> Message-ID: <443F1A20.4060301@rocsys.com> Hi, By the way can you tell me which is the structure that holds the rule ie when i give iptables -t filter -A FORWARD -j REJECT Which struct in kernel which holds the rule and which is the function that adds the rule from user space to the list in kernel? I assume that we are maintaing stack implementation for holding rules on one table am i right? Varun Sebastien Tandel wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, > >varun wrote: > > >>Hi Sebastien, >> >> Well i do not want to use policy from user space >>because , the very need for me to do this activity is to play around and >>get to understand netfilter iptables. >> >> > >ok ... that's the point :) > > > >> The features i want to implement like that >>priority for policy is that imagine a scenario where user added some >>policies and then for some reason wants one policy to be checked before >>checking others then he would have to add the policy again and delete >>the old policy isint it? >> >> > >Yes it is correct ... even if this may seem curious I think it is not >the worth to add such a mechanism to netfilter. IMHO, a switch option >'-M' (MOVE) would be sufficient but not with all these unique-id's ... I >fear that with the time this number list would be completely fragmented >and human-unreadable >I don't know wether it had already been discussed on this mailing-list. >IMHO, it is not a strong requirement for iptables/netfilter and this >situation may be handled in a semi-automatic way with a user script >(with the danger, however, of having a race condition with another user >script changing netfilter too). >Of course, if it is another exercise to play with netfilter do it and >have fun ;) > > > >> By the thanx for the help man and can you >>suggest me some good mailing list which deal with iptables development >>where newbies like me could get some help. This mailing list does not >>seem to help newbies much. >> >> > >Unfortunately, I don't know any other mailing list devoted to netfilter. :-/ > >sta >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.2 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFEPl07w76McB8jGxkRAi5cAJ0TPTCHg3ENQtf/7OMS8NQvlfqglgCfUkJp >GMvcI8Bety73ooSHNMQM/3I= >=ztZe >-----END PGP SIGNATURE----- > > > From robb.bossley at gmail.com Thu Apr 13 16:43:33 2006 From: robb.bossley at gmail.com (Robb Bossley) Date: Fri Apr 14 14:22:12 2006 Subject: Could you please update the Netfilter Extensions HOWTO ? In-Reply-To: <20060412143427.GK31616@sunbeam.de.gnumonks.org> References: <20060412131009.GF31616@sunbeam.de.gnumonks.org> <20060412143427.GK31616@sunbeam.de.gnumonks.org> Message-ID: <5c6851530604130743r1b09c42fwdba43759cb031964@mail.gmail.com> I would be willing to help some. I am no expert at programming, but I usually can figure things out with a little time and effort. (And I use netfilter with a couple of extensions.) Just point me in the right direction and I would be glad to help as I get time. Robb Bossley On 4/12/06, Harald Welte wrote: > > Do you think there is something that a total non-developer can do for the > > documentatiton project (in exchange for the prestigious e-mail > > @netfilter.org) ? > > well, documentation can actually be written by any user who has managed > to successfully use the particular to-be-documented software. From paolo.cerrito at tin.it Fri Apr 14 11:20:33 2006 From: paolo.cerrito at tin.it (Paolo Cerrito) Date: Fri Apr 14 14:22:13 2006 Subject: Request help Message-ID: Hy, my name is paolo, i have to develop an application who extracts packets from netfilter_queue, using netlink, process the packets and reinject packets. Can onyone help me, on where i can find api references for netfilter_queue? Or how i can i do? Please excuse me for my english, i will glad you if can help me. -- Creato con il rivoluzionario client e-mail di Opera: http://www.opera.com/mail/ From eric at inl.fr Fri Apr 14 14:10:22 2006 From: eric at inl.fr (Eric Leblond) Date: Fri Apr 14 14:27:39 2006 Subject: Request help In-Reply-To: References: Message-ID: <60616.194.167.18.244.1145016622.squirrel@mail.inl.fr> > Hy, > my name is paolo, i have to develop an application who extracts packets > from netfilter_queue, using netlink, process the packets and reinject > packets. > Can onyone help me, on where i can find api references for > netfilter_queue? You can find beta man pages here : http://archives.free.net.ph/message/20060208.171235.186dce08.en.html > Or how i can i do? For usage example, you can have a look at the NuFW project : http://www.nufw.org/ Code under src/nufw is the interesting part. BR, -- Eric Leblond From schwab at suse.de Fri Apr 14 19:12:20 2006 From: schwab at suse.de (Andreas Schwab) Date: Sat Apr 15 13:58:22 2006 Subject: compat_xt_counters is not compatible Message-ID: struct compat_xt_counters uses uint32_t[4], which has 4 byte alignment, but userspace uses uint64_t[2], which has 8 byte alignment. This breaks iptables in 2.6.17-rc1. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From kaber at trash.net Sat Apr 15 18:37:22 2006 From: kaber at trash.net (Patrick McHardy) Date: Sat Apr 15 18:57:25 2006 Subject: compat_xt_counters is not compatible In-Reply-To: References: Message-ID: <44412142.9070409@trash.net> Andreas Schwab wrote: > struct compat_xt_counters uses uint32_t[4], which has 4 byte alignment, > but userspace uses uint64_t[2], which has 8 byte alignment. This breaks > iptables in 2.6.17-rc1. Did you actually see the breakage? gcc on x86 uses 8 byte alignment for u_int64_t, but 4 byte alignment for structures with embedded u_int64_t members. It appears to work just fine on my x86_64. From kaber at trash.net Sat Apr 15 19:52:01 2006 From: kaber at trash.net (Patrick McHardy) Date: Sat Apr 15 20:12:02 2006 Subject: compat_xt_counters is not compatible In-Reply-To: References: <44412142.9070409@trash.net> Message-ID: <444132C1.1020604@trash.net> Andreas Schwab wrote: > Patrick McHardy writes: > > >>Andreas Schwab wrote: >> >>>struct compat_xt_counters uses uint32_t[4], which has 4 byte alignment, >>>but userspace uses uint64_t[2], which has 8 byte alignment. This breaks >>>iptables in 2.6.17-rc1. >> >>Did you actually see the breakage? > > > Of course. > > >>gcc on x86 > > > Not all the worlds an x86. Well, then how about providing the necessary information, starting with the architecture? From davem at davemloft.net Sun Apr 16 09:24:36 2006 From: davem at davemloft.net (David S. Miller) Date: Sun Apr 16 09:43:09 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <444132C1.1020604@trash.net> References: <44412142.9070409@trash.net> <444132C1.1020604@trash.net> Message-ID: <20060416.002436.108421304.davem@davemloft.net> From: Patrick McHardy Date: Sat, 15 Apr 2006 19:52:01 +0200 > Well, then how about providing the necessary information, starting > with the architecture? A struct containing a u64 has to be 64-bit aligned on at least sparc64 and ppc64, both of which use the compat layer for 32-bit programs, so I think it's quite clear this will have to be implemented differently. From kaber at trash.net Sun Apr 16 17:07:26 2006 From: kaber at trash.net (Patrick McHardy) Date: Sun Apr 16 17:27:37 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <20060416.002436.108421304.davem@davemloft.net> References: <44412142.9070409@trash.net> <444132C1.1020604@trash.net> <20060416.002436.108421304.davem@davemloft.net> Message-ID: <44425DAE.3040007@trash.net> David S. Miller wrote: > A struct containing a u64 has to be 64-bit aligned on at least sparc64 > and ppc64, both of which use the compat layer for 32-bit programs, so > I think it's quite clear this will have to be implemented differently. Do these alignment requirements also hold for 32bit compiled programms? This is what we need to match with compat_xt_counters. Or in other words: we need a type that when compiled for 64bit has the same alignment requirements as structures with embedded u_int64_t members compiled for 32bit on all architectures supporting CONFIG_COMPAT. I don't think such a type exists, so I guess we'll have to use different types depending on the architecture. I'll send a patch to do that if there are no better suggestions. From eric at inl.fr Sun Apr 16 23:45:45 2006 From: eric at inl.fr (Eric Leblond) Date: Mon Apr 17 00:03:18 2006 Subject: [PATCH] Transmit mark to userspace during conntrack event Message-ID: <1145223945.5659.4.camel@porky> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20060417/ef919f0f/attachment-0001.pgp From davem at davemloft.net Mon Apr 17 07:24:35 2006 From: davem at davemloft.net (David S. Miller) Date: Mon Apr 17 07:44:48 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <44425DAE.3040007@trash.net> References: <444132C1.1020604@trash.net> <20060416.002436.108421304.davem@davemloft.net> <44425DAE.3040007@trash.net> Message-ID: <20060416.222435.02924300.davem@davemloft.net> From: Patrick McHardy Date: Sun, 16 Apr 2006 17:07:26 +0200 > David S. Miller wrote: > > A struct containing a u64 has to be 64-bit aligned on at least sparc64 > > and ppc64, both of which use the compat layer for 32-bit programs, so > > I think it's quite clear this will have to be implemented differently. > > Do these alignment requirements also hold for 32bit compiled programms? Yes, it does. > This is what we need to match with compat_xt_counters. This issue is exactly why the compat layer requirements are so wildly different between "x86_64/ia64 --> ia32" and all other compat situations. ia32 doesn't have the 64-bit alignment requirement for structures containing u64 objects, whereas every other 32-bit platform does. From dim at openvz.org Mon Apr 17 12:59:09 2006 From: dim at openvz.org (Dmitry Mishin) Date: Mon Apr 17 13:17:05 2006 Subject: [RFC][PATCH] compat_uint64_t type In-Reply-To: <20060416.222435.02924300.davem@davemloft.net> References: <444132C1.1020604@trash.net> <44425DAE.3040007@trash.net> <20060416.222435.02924300.davem@davemloft.net> Message-ID: <200604171459.13312.dim@openvz.org> This patch introduces compat_uint64_t type, which is required for proper handling different alignment of structures, containing u64 objects, on compatible with ia32 64bit platforms and others. Signed-off-by: Dmitry Mishin Acked-of-by: Kirill Korotaev On Monday 17 April 2006 09:24, David S. Miller wrote: > From: Patrick McHardy > Date: Sun, 16 Apr 2006 17:07:26 +0200 > > > David S. Miller wrote: > > > A struct containing a u64 has to be 64-bit aligned on at least sparc64 > > > and ppc64, both of which use the compat layer for 32-bit programs, so > > > I think it's quite clear this will have to be implemented differently. > > > > Do these alignment requirements also hold for 32bit compiled programms? > > Yes, it does. > > > This is what we need to match with compat_xt_counters. > > This issue is exactly why the compat layer requirements are so wildly > different between "x86_64/ia64 --> ia32" and all other compat > situations. > > ia32 doesn't have the 64-bit alignment requirement for structures > containing u64 objects, whereas every other 32-bit platform does. -- Thanks, Dmitry. -------------- next part -------------- diff --git a/include/asm-ia64/compat.h b/include/asm-ia64/compat.h index 40d01d8..3e6417b 100644 --- a/include/asm-ia64/compat.h +++ b/include/asm-ia64/compat.h @@ -34,6 +34,8 @@ typedef s32 compat_long_t; typedef u32 compat_uint_t; typedef u32 compat_ulong_t; +typedef u64 __attribute__((aligned(4))) compat_uint64_t; + struct compat_timespec { compat_time_t tv_sec; s32 tv_nsec; diff --git a/include/asm-mips/compat.h b/include/asm-mips/compat.h index 986511d..f95640f 100644 --- a/include/asm-mips/compat.h +++ b/include/asm-mips/compat.h @@ -38,6 +38,8 @@ typedef s32 compat_long_t; typedef u32 compat_uint_t; typedef u32 compat_ulong_t; +typedef u64 compat_uint64_t; + struct compat_timespec { compat_time_t tv_sec; s32 tv_nsec; diff --git a/include/asm-parisc/compat.h b/include/asm-parisc/compat.h index 289624d..312829d 100644 --- a/include/asm-parisc/compat.h +++ b/include/asm-parisc/compat.h @@ -33,6 +33,8 @@ typedef s32 compat_long_t; typedef u32 compat_uint_t; typedef u32 compat_ulong_t; +typedef u64 compat_uint64_t; + struct compat_timespec { compat_time_t tv_sec; s32 tv_nsec; diff --git a/include/asm-powerpc/compat.h b/include/asm-powerpc/compat.h index aacaabd..e90fa22 100644 --- a/include/asm-powerpc/compat.h +++ b/include/asm-powerpc/compat.h @@ -36,6 +36,8 @@ typedef s32 compat_long_t; typedef u32 compat_uint_t; typedef u32 compat_ulong_t; +typedef u64 compat_uint64_t; + struct compat_timespec { compat_time_t tv_sec; s32 tv_nsec; diff --git a/include/asm-s390/compat.h b/include/asm-s390/compat.h index 356a0b1..1b8c7f7 100644 --- a/include/asm-s390/compat.h +++ b/include/asm-s390/compat.h @@ -35,6 +35,8 @@ typedef s32 compat_long_t; typedef u32 compat_uint_t; typedef u32 compat_ulong_t; +typedef u64 compat_uint64_t; + struct compat_timespec { compat_time_t tv_sec; s32 tv_nsec; diff --git a/include/asm-sparc64/compat.h b/include/asm-sparc64/compat.h index c73935d..6adc10c 100644 --- a/include/asm-sparc64/compat.h +++ b/include/asm-sparc64/compat.h @@ -34,6 +34,8 @@ typedef s32 compat_long_t; typedef u32 compat_uint_t; typedef u32 compat_ulong_t; +typedef u64 compat_uint64_t; + struct compat_timespec { compat_time_t tv_sec; s32 tv_nsec; diff --git a/include/asm-x86_64/compat.h b/include/asm-x86_64/compat.h index b37ab82..4d7eb9c 100644 --- a/include/asm-x86_64/compat.h +++ b/include/asm-x86_64/compat.h @@ -36,6 +36,8 @@ typedef s32 compat_long_t; typedef u32 compat_uint_t; typedef u32 compat_ulong_t; +typedef u64 __attribute__((aligned(4))) compat_uint64_t; + struct compat_timespec { compat_time_t tv_sec; s32 tv_nsec; diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h index f6bdef8..558125c 100644 --- a/include/linux/netfilter/x_tables.h +++ b/include/linux/netfilter/x_tables.h @@ -361,7 +361,7 @@ struct compat_xt_entry_target struct compat_xt_counters { - u_int32_t cnt[4]; + compat_uint64_t pcnt, bcnt; }; struct compat_xt_counters_info From dim at openvz.org Mon Apr 17 13:14:01 2006 From: dim at openvz.org (Dmitry Mishin) Date: Mon Apr 17 13:31:37 2006 Subject: [PATCH] table->lock initialization move Message-ID: <200604171514.02014.dim@openvz.org> xt_table->lock should be initialized before xt_replace_table() call, which uses it. This patch removes strict requirement, that table should define lock before registering. Signed-off-by: Dmitry Mishin Signed-off-by: Kirill Korotaev -- Thanks, Dmitry. -------------- next part -------------- diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index 00cf0a4..17abf60 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -529,6 +529,7 @@ int xt_register_table(struct xt_table *t /* Simplifies replace_table code. */ table->private = bootstrap; + rwlock_init(&table->lock); if (!xt_replace_table(table, 0, newinfo, &ret)) goto unlock; @@ -538,7 +539,6 @@ int xt_register_table(struct xt_table *t /* save number of initial entries */ private->initial_entries = private->number; - rwlock_init(&table->lock); list_prepend(&xt[table->af].tables, table); ret = 0; From dim at sw.ru Sat Apr 15 16:11:53 2006 From: dim at sw.ru (Dmitry Mishin) Date: Mon Apr 17 14:20:56 2006 Subject: compat_xt_counters is not compatible In-Reply-To: References: Message-ID: <200604151811.54013.dim@sw.ru> compat_xt_counters should be used only for 32bit processes, which has 4 byte alignment. On Friday 14 April 2006 21:12, Andreas Schwab wrote: > struct compat_xt_counters uses uint32_t[4], which has 4 byte alignment, > but userspace uses uint64_t[2], which has 8 byte alignment. This breaks > iptables in 2.6.17-rc1. > > Andreas. -- Thanks, Dmitry. From schwab at suse.de Sat Apr 15 16:16:33 2006 From: schwab at suse.de (Andreas Schwab) Date: Mon Apr 17 14:20:57 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <200604151811.54013.dim@sw.ru> (Dmitry Mishin's message of "Sat, 15 Apr 2006 18:11:53 +0400") References: <200604151811.54013.dim@sw.ru> Message-ID: Dmitry Mishin writes: > compat_xt_counters should be used only for 32bit processes, which has 4 byte > alignment. This is wrong. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From dim at sw.ru Sat Apr 15 18:14:45 2006 From: dim at sw.ru (Dmitry Mishin) Date: Mon Apr 17 14:20:58 2006 Subject: compat_xt_counters is not compatible In-Reply-To: References: <200604151811.54013.dim@sw.ru> Message-ID: <200604152014.45923.dim@sw.ru> Could you give more details on what's wrong? dim@dhcp0-24:~> cat test.c #include struct x { __u64 ptr; __u32 ptr2; }; int main(int argc, char *argv[]) { printf("%d\n", sizeof(struct x)); return 0; } dim@dhcp0-24:~> gcc -m32 -o test test.c dim@dhcp0-24:~> ./test 12 dim@dhcp0-24:~> gcc -o test test.c dim@dhcp0-24:~> ./test 16 dim@dhcp0-24:~> uname -p x86_64 On Saturday 15 April 2006 18:16, Andreas Schwab wrote: > Dmitry Mishin writes: > > compat_xt_counters should be used only for 32bit processes, which has 4 > > byte alignment. > > This is wrong. > > Andreas. -- Thanks, Dmitry. From schwab at suse.de Sat Apr 15 19:31:54 2006 From: schwab at suse.de (Andreas Schwab) Date: Mon Apr 17 14:20:59 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <44412142.9070409@trash.net> (Patrick McHardy's message of "Sat, 15 Apr 2006 18:37:22 +0200") References: <44412142.9070409@trash.net> Message-ID: Patrick McHardy writes: > Andreas Schwab wrote: >> struct compat_xt_counters uses uint32_t[4], which has 4 byte alignment, >> but userspace uses uint64_t[2], which has 8 byte alignment. This breaks >> iptables in 2.6.17-rc1. > > Did you actually see the breakage? Of course. > gcc on x86 Not all the worlds an x86. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From schwab at suse.de Sat Apr 15 19:32:54 2006 From: schwab at suse.de (Andreas Schwab) Date: Mon Apr 17 14:21:00 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <200604152014.45923.dim@sw.ru> (Dmitry Mishin's message of "Sat, 15 Apr 2006 20:14:45 +0400") References: <200604151811.54013.dim@sw.ru> <200604152014.45923.dim@sw.ru> Message-ID: Dmitry Mishin writes: > Could you give more details on what's wrong? Your claim that long long has 4 byte alignment. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From dim at sw.ru Sat Apr 15 20:38:37 2006 From: dim at sw.ru (Dmitry Mishin) Date: Mon Apr 17 14:21:01 2006 Subject: compat_xt_counters is not compatible In-Reply-To: References: <200604152014.45923.dim@sw.ru> Message-ID: <200604152238.37403.dim@sw.ru> I believes, that on 32 bit arch any alignment <= 4 bytes. Could you point out the cases, where it is not true? On Saturday 15 April 2006 21:32, Andreas Schwab wrote: > Dmitry Mishin writes: > > Could you give more details on what's wrong? > > Your claim that long long has 4 byte alignment. > > Andreas. -- Thanks, Dmitry. From schwab at suse.de Sun Apr 16 00:09:24 2006 From: schwab at suse.de (Andreas Schwab) Date: Mon Apr 17 14:21:02 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <200604152238.37403.dim@sw.ru> (Dmitry Mishin's message of "Sat, 15 Apr 2006 22:38:37 +0400") References: <200604152014.45923.dim@sw.ru> <200604152238.37403.dim@sw.ru> Message-ID: Dmitry Mishin writes: > I believes, that on 32 bit arch any alignment <= 4 bytes. Why do you think so? > Could you point out the cases, where it is not true? Almost every architecture has alignment = size for basic types. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From dim at sw.ru Sun Apr 16 08:28:38 2006 From: dim at sw.ru (Dmitry Mishin) Date: Mon Apr 17 14:21:03 2006 Subject: compat_xt_counters is not compatible In-Reply-To: References: <200604152238.37403.dim@sw.ru> Message-ID: <200604161028.38614.dim@sw.ru> > > Almost every architecture has alignment = size for basic types. > > Andreas. I mean structures. I don't see a bug still. Can you point out wrong code? -- Thanks, Dmitry. From schwab at suse.de Sun Apr 16 13:41:47 2006 From: schwab at suse.de (Andreas Schwab) Date: Mon Apr 17 14:21:04 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <200604161028.38614.dim@sw.ru> (Dmitry Mishin's message of "Sun, 16 Apr 2006 10:28:38 +0400") References: <200604152238.37403.dim@sw.ru> <200604161028.38614.dim@sw.ru> Message-ID: Dmitry Mishin writes: >> >> Almost every architecture has alignment = size for basic types. >> >> Andreas. > I mean structures. So do I. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From schwab at suse.de Mon Apr 17 13:51:55 2006 From: schwab at suse.de (Andreas Schwab) Date: Mon Apr 17 14:21:05 2006 Subject: [RFC][PATCH] compat_uint64_t type In-Reply-To: <200604171459.13312.dim@openvz.org> (Dmitry Mishin's message of "Mon, 17 Apr 2006 14:59:09 +0400") References: <444132C1.1020604@trash.net> <44425DAE.3040007@trash.net> <20060416.222435.02924300.davem@davemloft.net> <200604171459.13312.dim@openvz.org> Message-ID: Dmitry Mishin writes: > diff --git a/include/asm-ia64/compat.h b/include/asm-ia64/compat.h > index 40d01d8..3e6417b 100644 > --- a/include/asm-ia64/compat.h > +++ b/include/asm-ia64/compat.h > @@ -34,6 +34,8 @@ typedef s32 compat_long_t; > typedef u32 compat_uint_t; > typedef u32 compat_ulong_t; > > +typedef u64 __attribute__((aligned(4))) compat_uint64_t; The aligned attribute cannot decrease alignment. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From dim at openvz.org Mon Apr 17 14:04:17 2006 From: dim at openvz.org (Dmitry Mishin) Date: Mon Apr 17 14:21:58 2006 Subject: [RFC][PATCH] compat_uint64_t type In-Reply-To: References: <444132C1.1020604@trash.net> <200604171459.13312.dim@openvz.org> Message-ID: <200604171604.18471.dim@openvz.org> On Monday 17 April 2006 15:51, Andreas Schwab wrote: > Dmitry Mishin writes: > > diff --git a/include/asm-ia64/compat.h b/include/asm-ia64/compat.h > > index 40d01d8..3e6417b 100644 > > --- a/include/asm-ia64/compat.h > > +++ b/include/asm-ia64/compat.h > > @@ -34,6 +34,8 @@ typedef s32 compat_long_t; > > typedef u32 compat_uint_t; > > typedef u32 compat_ulong_t; > > > > +typedef u64 __attribute__((aligned(4))) compat_uint64_t; > > The aligned attribute cannot decrease alignment. With my gcc (3.3.5) it can. Which solution do you propose? __attribute__((packed, aligned(4)))? Or #ifdef ARCH_HAS_FUNNY_ALIGNMENT struct compat_xt_counters { uint32_t cnt[4]; } #else #define compat_xt_counters xt_counters #endif ? > > Andreas. -- Thanks, Dmitry. From kaber at trash.net Mon Apr 17 17:47:14 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Apr 17 18:07:37 2006 Subject: [RFC][PATCH] compat_uint64_t type In-Reply-To: <200604171459.13312.dim@openvz.org> References: <444132C1.1020604@trash.net> <44425DAE.3040007@trash.net> <20060416.222435.02924300.davem@davemloft.net> <200604171459.13312.dim@openvz.org> Message-ID: <4443B882.70203@trash.net> Dmitry Mishin wrote: > This patch introduces compat_uint64_t type, which is required for proper > handling different alignment of structures, containing u64 objects, on > compatible with ia32 64bit platforms and others. > > diff --git a/include/asm-ia64/compat.h b/include/asm-ia64/compat.h > index 40d01d8..3e6417b 100644 > --- a/include/asm-ia64/compat.h > +++ b/include/asm-ia64/compat.h > @@ -34,6 +34,8 @@ typedef s32 compat_long_t; > typedef u32 compat_uint_t; > typedef u32 compat_ulong_t; > > +typedef u64 __attribute__((aligned(4))) compat_uint64_t; > + > struct compat_timespec { > compat_time_t tv_sec; > s32 tv_nsec; I'm not sure if we should really introduce this new type, it is misleading for at least x86. IIRC the situation there is: - gcc < 4.0 always aligns u64 types to 4byte - gcc >= 4.0 aligns basic u64 types to 8byte, u64's embedded in structures to 4 byte So there is no one compat_uint64_t type, but it depends on the situation. From kaber at trash.net Mon Apr 17 18:03:39 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Apr 17 18:23:51 2006 Subject: [RFC][PATCH] compat_uint64_t type In-Reply-To: <4443B882.70203@trash.net> References: <444132C1.1020604@trash.net> <44425DAE.3040007@trash.net> <20060416.222435.02924300.davem@davemloft.net> <200604171459.13312.dim@openvz.org> <4443B882.70203@trash.net> Message-ID: <4443BC5B.9000407@trash.net> Patrick McHardy wrote: > Dmitry Mishin wrote: > >>This patch introduces compat_uint64_t type, which is required for proper >>handling different alignment of structures, containing u64 objects, on >>compatible with ia32 64bit platforms and others. This is my proposed alternative. It assumes all architectures besides x86 use native alignment for basic types. -------------- next part -------------- [NETFILTER]: Fix compat_xt_counters alignment for non-x86 Some (?) non-x86 architectures require 8byte alignment for u_int64_t even when compiled for 32bit, using u_int32_t in compat_xt_counters breaks on these architectures, use u_int64_t for everything but x86. Reported by Andreas Schwab . Signed-off-by: Patrick McHardy --- commit 2666afe70fb68b9b884f6d3fa7e4236183818028 tree 65eac95933d59a455853245f7442cbb38dc9f19c parent 2ceefa038e908d5da21aefedae02da4eab1b2787 author Patrick McHardy Mon, 17 Apr 2006 18:04:37 +0200 committer Patrick McHardy Mon, 17 Apr 2006 18:04:37 +0200 include/linux/netfilter/x_tables.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h index f6bdef8..3870145 100644 --- a/include/linux/netfilter/x_tables.h +++ b/include/linux/netfilter/x_tables.h @@ -361,7 +361,11 @@ struct compat_xt_entry_target struct compat_xt_counters { +#if defined(CONFIG_X86_64) || defined(CONFIG_IA64) u_int32_t cnt[4]; +#else + u_int64_t cnt[2]; +#endif }; struct compat_xt_counters_info From kaber at trash.net Mon Apr 17 19:12:21 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Apr 17 19:32:33 2006 Subject: [RFC][PATCH] compat_uint64_t type In-Reply-To: References: <444132C1.1020604@trash.net> <44425DAE.3040007@trash.net> <20060416.222435.02924300.davem@davemloft.net> <200604171459.13312.dim@openvz.org> <4443B882.70203@trash.net> Message-ID: <4443CC75.4040703@trash.net> Andreas Schwab wrote: > Patrick McHardy writes: > >>I'm not sure if we should really introduce this new type, it is >>misleading for at least x86. IIRC the situation there is: >> >>- gcc < 4.0 always aligns u64 types to 4byte > > > Are you sure about that? I can't reproduce that with gcc 3.3.3. I mixed up the versions, the change was between 2.x and 3.x: gcc-2.95 -O2: basic type: align 4 embedded type: align 4 gcc-3.3 -O2: basic type: align 8 embedded type: align 4 It only shows with optimization, with -O0 gcc-2.95 also uses 8 for the basic type. >>So there is no one compat_uint64_t type, but it depends on the >>situation. > > > The alignment of standalone objects is uninteresting, what is important is > getting compatible layout of aggregates. I couldn't come up with a realistic example where people would make mistakes because of this, so I guess I have to agree, although my feeling still disagrees :) From davem at davemloft.net Mon Apr 17 22:13:25 2006 From: davem at davemloft.net (David S. Miller) Date: Mon Apr 17 22:31:14 2006 Subject: compat_xt_counters is not compatible In-Reply-To: <200604161028.38614.dim@sw.ru> References: <200604152238.37403.dim@sw.ru> <200604161028.38614.dim@sw.ru> Message-ID: <20060417.131325.123750237.davem@davemloft.net> From: Dmitry Mishin Date: Sun, 16 Apr 2006 10:28:38 +0400 > > > > Almost every architecture has alignment = size for basic types. > > > > Andreas. > I mean structures. I don't see a bug still. Can you point out wrong code? I can't believe such a conversation even gets this far. :( LOOK! struct { int x; unsigned long long y; }; This structure requires 64-bit alignment on 32-bit Sparc and 32-bit PPC and 32-bit MIPS and 32-bit .... It is x86, and only x86, that has only a 32-bit alignment requirement for this structure. From davem at davemloft.net Mon Apr 17 22:20:26 2006 From: davem at davemloft.net (David S. Miller) Date: Mon Apr 17 22:38:13 2006 Subject: [RFC][PATCH] compat_uint64_t type In-Reply-To: <4443BC5B.9000407@trash.net> References: <200604171459.13312.dim@openvz.org> <4443B882.70203@trash.net> <4443BC5B.9000407@trash.net> Message-ID: <20060417.132026.72299574.davem@davemloft.net> From: Patrick McHardy Date: Mon, 17 Apr 2006 18:03:39 +0200 > Patrick McHardy wrote: > > Dmitry Mishin wrote: > > > >>This patch introduces compat_uint64_t type, which is required for proper > >>handling different alignment of structures, containing u64 objects, on > >>compatible with ia32 64bit platforms and others. > > This is my proposed alternative. It assumes all architectures besides > x86 use native alignment for basic types. Ok. Perhaps we can eventually define a CONFIG_* object for this. From m at rtij.nl Mon Apr 17 23:46:58 2006 From: m at rtij.nl (Martijn Lievaart) Date: Tue Apr 18 00:04:33 2006 Subject: Strange MASQUERADING behaviour, bug or feature? Message-ID: <44440CD2.6060006@rtij.nl> Hi, [ Long story, better to much information than to little ] I encountered some non-intuitive behaviour with MASQUERADE. I wrote a dial-on-demand utility, that uses a tun interface. When it sees packets, it brings up the real interface. However, packets are masqueraded with the ip address of the tun interface, jus