From hdemir at metu.edu.tr Tue May 1 09:17:12 2007 From: hdemir at metu.edu.tr (husnu demir) Date: Tue May 1 10:17:07 2007 Subject: ftp.netfilter.org has a problem. Message-ID: <20070501071712.GA1601756@metu.edu.tr> Hi, I noticed that ftp side had some problems, or something changed. After "Apr 14", the files have zero sizes and it is the same almost all snapshots, pom-ng, ipset etc. I do not know who responsible. So I wrote here. Thanks. hdemir. /pub/iptables/snapshot> ls -ltr -rw-r--r-- 1 ftpuser ftpgroup 66 Apr 14 21:55 iptables-1.3.7-20070414.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 171246 Apr 14 21:55 iptables-1.3.7-20070414.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 15 21:55 iptables--20070415.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 15 21:55 iptables--20070415.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 16 21:55 iptables--20070416.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 16 21:55 iptables--20070416.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 17 21:55 iptables--20070417.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 17 21:55 iptables--20070417.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 18 21:55 iptables--20070418.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 18 21:55 iptables--20070418.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 19 21:55 iptables--20070419.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 19 21:55 iptables--20070419.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 20 21:55 iptables--20070420.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 20 21:55 iptables--20070420.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 21 21:55 iptables--20070421.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 21 21:55 iptables--20070421.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 22 21:55 iptables--20070422.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 22 21:55 iptables--20070422.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 23 21:55 iptables--20070423.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 23 21:55 iptables--20070423.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 24 21:55 iptables--20070424.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 24 21:55 iptables--20070424.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 25 21:55 iptables--20070425.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 25 21:55 iptables--20070425.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 26 21:55 iptables--20070426.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 26 21:55 iptables--20070426.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 27 21:55 iptables--20070427.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 27 21:55 iptables--20070427.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 28 21:55 iptables--20070428.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 28 21:55 iptables--20070428.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 29 21:55 iptables--20070429.tar.bz2 -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 29 21:55 iptables--20070429.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 61 Apr 30 21:55 iptables--20070430.tar.bz2.md5sum -rw-r--r-- 1 ftpuser ftpgroup 46 Apr 30 21:55 iptables--20070430.tar.bz2 From kernel at linuxace.com Wed May 2 01:08:05 2007 From: kernel at linuxace.com (Phil Oester) Date: Wed May 2 02:08:02 2007 Subject: [PATCH] update quota manpage for SMP Message-ID: <20070501230805.GA21022@linuxace.com> The quota match works fine on SMP, so update the manpage to reflect this. Closes bugzilla #564. Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-quota.man Type: application/x-troff-man Size: 266 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20070502/0f493b29/patch-quota.man From clenggenhager at gmail.com Wed May 2 08:14:07 2007 From: clenggenhager at gmail.com (Christoph Lenggenhager) Date: Wed May 2 09:14:07 2007 Subject: State of the conntrack match In-Reply-To: References: Message-ID: Hi I would like to use a conntrack match (i.e. -m conntrack --ctorigdst ...), but I miss the ability to filter for the original source and destination ports. When going through the archives of netfilter-devel, I see that the conntrack match has originally been developed by Marc Boucher. Back in 2002, Henrik Nordstr?m wrote a patch to it that would precisely fit my needs. (cf. http://lists.netfilter.org/pipermail/netfilter-devel/2002-July/008382.html) Unfortunately, this effort seems to have died with the advise from Harald Welte to contact Marc Boucher directly. My questions are now: - What is the status of the conntrack match? Is it just "there" to be used, but nobody ever wants to touch it again? - Would it be appreciated to take up Henrik's (old) ideas? Is there a chance to take such changes into the main tree? Since I do not know better: Is this a "good" idea or does it make you scream and run away? Well, this is more a user-related question: - Assuming conntrack match is too old and out-dated, is there an alternative way to filter based on the original data (addresses and ports) of a packet? Thanks for any reply. Kind regards, christoph PS: If this is a repost, please excuse, but I couldn't find my message in the archives, so I resent it. Sorry for any inconveniences. From henrik at henriknordstrom.net Wed May 2 11:18:46 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Wed May 2 12:19:00 2007 Subject: State of the conntrack match In-Reply-To: References: Message-ID: <1178097526.15170.3.camel@henriknordstrom.net> ons 2007-05-02 klockan 08:14 +0200 skrev Christoph Lenggenhager: > When going through the archives of netfilter-devel, I see that the > conntrack match has originally been developed by Marc Boucher. > Back in 2002, Henrik Nordstr?m wrote a patch to it that would precisely > fit my needs. > (cf. http://lists.netfilter.org/pipermail/netfilter-devel/2002-July/008382.html) > Unfortunately, this effort seems to have died with the advise from > Harald Welte to contact Marc Boucher directly. It mainly died due to the troubles in extending existing matches at the time, which has since then been solved with the extension versioning. So it should be pretty straight forward to extend the conntrack match with the needed functionality today. See for example xt_multiport for an example how to extend an existing match. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070502/1633541c/attachment.pgp From fhartman at hsr.ch Wed May 2 11:24:40 2007 From: fhartman at hsr.ch (Fabian Hartmann) Date: Wed May 2 12:24:56 2007 Subject: clusterip used on a router/firewall Message-ID: <1178097880.3727.54.camel@fbe-desktop> Hello everyone We were trying to get clusterip running as a cluster-router/firewall. We had to patch the kernel + iptables because clusterip needed a destination IP for the cluster. While it is working as a router it is not necessary, because of course the traffic is forwarded through the cluster. So we introduced a new parameter in the iptables clusterip command and adapted the kernel-code, where we save the clusterip in the config-struct. The patch already works for UDP-connections, but it doesn't work with ICMP because of problems with icmp_conntrack. TCP hasn't been tested so far. Now we would like to hear your opinion about our patches. Do you think we are approaching the right way or is there another maybe even simpler solution? Thx in advance Fabian Hartmann Marco Gruber Have a look at the patches (iptables 1.3.7 + kernel 2.6.21) below: diff -Naur iptables-1.3.7-orig/extensions/libipt_CLUSTERIP.c iptables-1.3.7-new/extensions/libipt_CLUSTERIP.c --- iptables-1.3.7-orig/extensions/libipt_CLUSTERIP.c 2007-04-25 09:58:04.000000000 +0200 +++ iptables-1.3.7-new/extensions/libipt_CLUSTERIP.c 2007-04-25 10:07:38.000000000 +0200 @@ -8,6 +8,7 @@ #include #include #include +#include #if defined(__GLIBC__) && __GLIBC__ == 2 #include @@ -30,6 +31,7 @@ " sourceip-sourceport\n" " sourceip-sourceport-destport\n" " --clustermac Set clusterIP MAC address\n" +" --clusterip Set clusterIP IP address\n" " --total-nodes Set number of total nodes in cluster\n" " --local-node Set the local node number\n" " --hash-init Set init value of the Jenkins hash\n" @@ -43,6 +45,7 @@ #define PARAM_TOTALNODE 0x0008 #define PARAM_LOCALNODE 0x0010 #define PARAM_HASHINIT 0x0020 +#define PARAM_IP 0x0040 static struct option opts[] = { { "new", 0, 0, '1' }, @@ -51,6 +54,7 @@ { "total-nodes", 1, 0, '4' }, { "local-node", 1, 0, '5' }, { "hash-init", 1, 0, '6' }, + { "clusterip", 1, 0, '7' }, { 0 } }; @@ -83,6 +87,18 @@ } } +static __be32 +parse_ip(const char *ip) +{ + struct in_addr virtualIP; + if (inet_aton(ip, &virtualIP)==0) { + exit_error(PARAMETER_PROBLEM, + "Bad virtual IP address `%s'", ip); + } + + return (__be32)virtualIP.s_addr; +} + static int parse(int c, char **argv, int invert, unsigned int *flags, const struct ipt_entry *entry, @@ -156,6 +172,14 @@ cipinfo->hash_initval = num; *flags |= PARAM_HASHINIT; break; + case '7': + if (!(*flags & PARAM_NEW)) + exit_error(PARAMETER_PROBLEM, "Can only specify virtual IP combined with `--new'\n"); + if (*flags & PARAM_IP) + exit_error(PARAMETER_PROBLEM, "Can only specify virtual IP once\n"); + cipinfo->clusterip = parse_ip(optarg); + *flags |= PARAM_IP; + break; default: return 0; } @@ -169,8 +193,8 @@ if (flags == 0) return; - if ((flags & (PARAM_NEW|PARAM_HMODE|PARAM_MAC|PARAM_TOTALNODE| PARAM_LOCALNODE)) - == (PARAM_NEW|PARAM_HMODE|PARAM_MAC|PARAM_TOTALNODE|PARAM_LOCALNODE)) + if ((flags & (PARAM_NEW|PARAM_HMODE|PARAM_MAC|PARAM_IP| PARAM_TOTALNODE|PARAM_LOCALNODE)) + == (PARAM_NEW|PARAM_HMODE|PARAM_MAC|PARAM_IP|PARAM_TOTALNODE| PARAM_LOCALNODE)) return; exit_error(PARAMETER_PROBLEM, "CLUSTERIP target: Invalid parameter combination\n"); @@ -203,7 +227,13 @@ mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); return buf; } - + +static char *ip2str(const __be32 ip) +{ + struct in_addr vip; + vip.s_addr = ip; + return inet_ntoa( vip ); +} /* Prints out the targinfo. */ static void @@ -219,9 +249,10 @@ return; } - printf("CLUSTERIP hashmode=%s clustermac=%s total_nodes=%u local_node= %u hash_init=%u", + printf("CLUSTERIP hashmode=%s clustermac=%s clusterip=%s total_nodes=% u local_node=%u hash_init=%u", hashmode2str(cipinfo->hash_mode), mac2str(cipinfo->clustermac), + ip2str(cipinfo->clusterip), cipinfo->num_total_nodes, cipinfo->local_nodes[0], cipinfo->hash_initval); @@ -239,9 +270,10 @@ if (!cipinfo->flags & CLUSTERIP_FLAG_NEW) return; - printf("--new --hashmode %s --clustermac %s --total-nodes %d --local-node %d --hash-init %u", + printf("--new --hashmode %s --clustermac %s --clusterip %s --total-nodes %d --local-node %d --hash-init %u", hashmode2str(cipinfo->hash_mode), mac2str(cipinfo->clustermac), + ip2str(cipinfo->clusterip), cipinfo->num_total_nodes, cipinfo->local_nodes[0], cipinfo->hash_initval); diff -Naur iptables-1.3.7-orig/extensions/libipt_CLUSTERIP.man iptables-1.3.7-new/extensions/libipt_CLUSTERIP.man --- iptables-1.3.7-orig/extensions/libipt_CLUSTERIP.man 2007-04-25 09:58:04.000000000 +0200 +++ iptables-1.3.7-new/extensions/libipt_CLUSTERIP.man 2007-04-25 10:00:21.000000000 +0200 @@ -14,6 +14,9 @@ .BI "--clustermac " "mac" Specify the ClusterIP MAC address. Has to be a link-layer multicast address .TP +.BI "--clusterip " "ip" +Specify the ClusterIP IP address. +.TP .BI "--total-nodes " "num" Number of total nodes within this cluster. .TP diff -Naur iptables-1.3.7-orig/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h iptables-1.3.7-new/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h --- iptables-1.3.7-orig/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h 2007-04-25 09:58:04.000000000 +0200 +++ iptables-1.3.7-new/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h 2007-04-25 09:59:49.000000000 +0200 @@ -21,17 +21,14 @@ /* only relevant for new ones */ u_int8_t clustermac[6]; + __be32 clusterip; u_int16_t num_total_nodes; u_int16_t num_local_nodes; u_int16_t local_nodes[CLUSTERIP_MAX_NODES]; enum clusterip_hashmode hash_mode; u_int32_t hash_initval; - -#ifdef KERNEL_64_USERSPACE_32 - u_int64_t config; -#else + struct clusterip_config *config; -#endif }; #endif /*_IPT_CLUSTERIP_H_target*/ ----------------------------- kernel-patch ----------------------------- diff -Naur linux-2.6.21.1/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h linux-2.6.21.1_new/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h --- linux-2.6.21.1/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h 2007-04-27 23:49:26.000000000 +0200 +++ linux-2.6.21.1_new/include/linux/netfilter_ipv4/ipt_CLUSTERIP.h 2007-05-02 11:20:43.000000000 +0200 @@ -21,6 +21,7 @@ /* only relevant for new ones */ u_int8_t clustermac[6]; + __be32 clusterip; u_int16_t num_total_nodes; u_int16_t num_local_nodes; u_int16_t local_nodes[CLUSTERIP_MAX_NODES]; diff -Naur linux-2.6.21.1/net/ipv4/netfilter/ipt_CLUSTERIP.c linux-2.6.21.1_new/net/ipv4/netfilter/ipt_CLUSTERIP.c --- linux-2.6.21.1/net/ipv4/netfilter/ipt_CLUSTERIP.c 2007-04-27 23:49:26.000000000 +0200 +++ linux-2.6.21.1_new/net/ipv4/netfilter/ipt_CLUSTERIP.c 2007-05-02 11:19:40.000000000 +0200 @@ -313,6 +313,25 @@ enum ip_conntrack_info ctinfo; u_int32_t *mark, hash; + + + // Empfaenger MAC des Netzwerkpacketes + u_int8_t* pmac = (*pskb)->mac.raw; + + // Cluster-MAC aus der Config + u_int8_t *cmac = cipinfo->config->clustermac; + + //DEBUGP( "\nDestination MAC: %X:%X:%X:%X:%X:%X\n", pmac[0], pmac[1], pmac[2], pmac[3], pmac[4], pmac[5]); + //DEBUGP( "Cluster MAC : %X:%X:%X:%X:%X:%X\n", cmac[0], cmac[1], cmac[2], cmac[3], cmac[4], cmac[5]); + + // Test ob Netzwerkpacket an Cluster MAC geschickt worden ist + // -> Ev Packet an eine andere IP des gleichen Interfaces + if ( memcmp(cmac, pmac, 6) != 0 ) { + return IPT_CONTINUE; + } + + + /* don't need to clusterip_config_get() here, since refcount * is only decremented by destroy() - and ip_tables guarantees * that the ->target() function isn't called after ->destroy() */ @@ -359,6 +378,7 @@ DUMP_TUPLE(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); #endif DEBUGP("hash=%u ct_hash=%u ", hash, *mark); + if (!clusterip_responsible(cipinfo->config, hash)) { DEBUGP("not responsible\n"); return NF_DROP; @@ -392,15 +412,16 @@ return 0; } - if (e->ip.dmsk.s_addr != htonl(0xffffffff) - || e->ip.dst.s_addr == 0) { - printk(KERN_ERR "CLUSTERIP: Please specify destination IP\n"); + + if(cipinfo->clusterip == 0) { + printk(KERN_ERR "CLUSTERIP: Please specify Virtual IP \n"); return 0; } + /* FIXME: further sanity checks */ - config = clusterip_config_find_get(e->ip.dst.s_addr, 1); + config = clusterip_config_find_get(cipinfo->clusterip, 1); if (config) { if (cipinfo->config != NULL) { /* Case A: This is an entry that gets reloaded, since @@ -436,7 +457,7 @@ } config = clusterip_config_init(cipinfo, - e->ip.dst.s_addr, dev); + cipinfo->clusterip, dev); if (!config) { printk(KERN_WARNING "CLUSTERIP: cannot allocate config\n"); dev_put(dev); From kaber at trash.net Wed May 2 14:21:18 2007 From: kaber at trash.net (Patrick McHardy) Date: Wed May 2 15:22:57 2007 Subject: [PATCH] update quota manpage for SMP In-Reply-To: <20070501230805.GA21022@linuxace.com> References: <20070501230805.GA21022@linuxace.com> Message-ID: <4638823E.6020502@trash.net> Phil Oester wrote: > The quota match works fine on SMP, so update the manpage to reflect > this. Closes bugzilla #564. Applied, thanks Phil. From kaber at trash.net Wed May 2 14:25:27 2007 From: kaber at trash.net (Patrick McHardy) Date: Wed May 2 15:27:01 2007 Subject: [PATCH] xx_nat_proto_gre: do not modify/corrupt GREv0 packets thought NAT In-Reply-To: <00ef01c788c1$e32a62e0$061010ac@intranet.dti2.net> References: <00c501c7829e$6209edd0$061010ac@intranet.dti2.net> <462DFD1D.1060706@trash.net> <101c01c78829$24a70230$061010ac@intranet.dti2.net> <4631DCA3.4020701@trash.net> <00ef01c788c1$e32a62e0$061010ac@intranet.dti2.net> Message-ID: <46388337.3060800@trash.net> Jorge Boncompte [DTI2] wrote: > While porting some changes of the 2.6.21-rc7 pptp/proto_gre conntrack > and nat modules to a 2.4.32 kernel I noticed that the gre_key function > returns a wrong pointer to the GRE key of a version 0 packet thus > corrupting > the packet payload. > The intended behaviour for GREv0 packets is to act like > nf_conntrack_proto_generic/nf_nat_proto_unknown so I have ripped the > offending functions (not used anymore) and modified the xx_nat_proto_gre > modules to not touch version 0 (non PPTP) packets. Applied, thanks. I removed the FIXME though since its the intended behaviour and not something that needs to be fixed. I'll push it to -stable as well. From jorge at dti2.net Wed May 2 15:21:01 2007 From: jorge at dti2.net (Jorge Boncompte [DTI2]) Date: Wed May 2 16:21:06 2007 Subject: [PATCH] xx_nat_proto_gre: do not modify/corrupt GREv0 packets thought NAT References: <00c501c7829e$6209edd0$061010ac@intranet.dti2.net> <462DFD1D.1060706@trash.net> <101c01c78829$24a70230$061010ac@intranet.dti2.net> <4631DCA3.4020701@trash.net> <00ef01c788c1$e32a62e0$061010ac@intranet.dti2.net> <46388337.3060800@trash.net> Message-ID: <027301c78cbc$baff1cd0$061010ac@intranet.dti2.net> ----- Original Message ----- From: "Patrick McHardy" To: "Jorge Boncompte [DTI2]" Cc: Sent: Wednesday, May 02, 2007 2:25 PM Subject: Re: [PATCH] xx_nat_proto_gre: do not modify/corrupt GREv0 packets thought NAT > Applied, thanks. I removed the FIXME though since its the intended > behaviour and not something that needs to be fixed. I'll push it > to -stable as well. Well, I don't have an opinion on the comment. My only intention was to reflect the fact that we do not NAT those packets as the comment states. Just for the records: The code can be made to NAT GREv0 packets with a key, at least if the orig and repl direction use the same key. This is the normal behaviour when you configure GRE tunnels on Cisco gears, Linux "ip tunnel" allows to use different keys for transmitting and receiving. I have tested that SNAT tracks the packets and that I can use several tunnels between the same endpoints with different keys, it did require only some minor modifications but to do it right it will need some more changes like to expand the key field to a 32bit type again all over the code. If someone ever needs it, just ask. Best regards, -Jorge ============================================================== Jorge Boncompte - Ingenieria y Gestion de RED DTI2 - Desarrollo de la Tecnologia de las Comunicaciones -------------------------------------------------------------- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 ============================================================== - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be made. ============================================================== From kaber at trash.net Wed May 2 15:23:34 2007 From: kaber at trash.net (Patrick McHardy) Date: Wed May 2 16:25:11 2007 Subject: [PATCH] xx_nat_proto_gre: do not modify/corrupt GREv0 packets thought NAT In-Reply-To: <027301c78cbc$baff1cd0$061010ac@intranet.dti2.net> References: <00c501c7829e$6209edd0$061010ac@intranet.dti2.net> <462DFD1D.1060706@trash.net> <101c01c78829$24a70230$061010ac@intranet.dti2.net> <4631DCA3.4020701@trash.net> <00ef01c788c1$e32a62e0$061010ac@intranet.dti2.net> <46388337.3060800@trash.net> <027301c78cbc$baff1cd0$061010ac@intranet.dti2.net> Message-ID: <463890D6.9060605@trash.net> Jorge Boncompte [DTI2] wrote: > ----- Original Message ----- From: "Patrick McHardy" >> Applied, thanks. I removed the FIXME though since its the intended >> behaviour and not something that needs to be fixed. I'll push it >> to -stable as well. > > > Well, I don't have an opinion on the comment. My only intention was > to reflect the fact that we do not NAT those packets as the comment states. Yes, I left that part intact, I just removed the FIXME. > Just for the records: > The code can be made to NAT GREv0 packets with a key, at least if the > orig and repl direction use the same key. This is the normal behaviour > when you configure GRE tunnels on Cisco gears, Linux "ip tunnel" allows > to use different keys for transmitting and receiving. I have tested that > SNAT tracks the packets and that I can use several tunnels between the > same endpoints with different keys, it did require only some minor > modifications but to do it right it will need some more changes like to > expand the key field to a 32bit type again all over the code. > If someone ever needs it, just ask. I think the problem with this is that we don't know whether both keys are identical at connection setup time and thus might fail to even track the connection if they are not. If thats not correct feel free to send a patch on top of the previous one :) From jorge at dti2.net Wed May 2 15:48:29 2007 From: jorge at dti2.net (Jorge Boncompte [DTI2]) Date: Wed May 2 16:48:33 2007 Subject: [PATCH] xx_nat_proto_gre: do not modify/corrupt GREv0 packets thought NAT References: <00c501c7829e$6209edd0$061010ac@intranet.dti2.net> <462DFD1D.1060706@trash.net> <101c01c78829$24a70230$061010ac@intranet.dti2.net> <4631DCA3.4020701@trash.net> <00ef01c788c1$e32a62e0$061010ac@intranet.dti2.net> <46388337.3060800@trash.net> <027301c78cbc$baff1cd0$061010ac@intranet.dti2.net> <463890D6.9060605@trash.net> Message-ID: <029801c78cc0$91179600$061010ac@intranet.dti2.net> ----- Original Message ----- From: "Patrick McHardy" To: "Jorge Boncompte [DTI2]" Cc: Sent: Wednesday, May 02, 2007 3:23 PM Subject: Re: [PATCH] xx_nat_proto_gre: do not modify/corrupt GREv0 packets thought NAT >> The code can be made to NAT GREv0 packets with a key, at least if the >> orig and repl direction use the same key. This is the normal behaviour >> when you configure GRE tunnels on Cisco gears, Linux "ip tunnel" allows >> to use different keys for transmitting and receiving. I have tested that >> SNAT tracks the packets and that I can use several tunnels between the >> same endpoints with different keys, it did require only some minor >> modifications but to do it right it will need some more changes like to >> expand the key field to a 32bit type again all over the code. >> If someone ever needs it, just ask. > > > I think the problem with this is that we don't know whether both keys > are identical at connection setup time and thus might fail to even > track the connection if they are not. > > If thats not correct feel free to send a patch on top of the previous > one :) Yes, you are right, we don't know if both keys are identical as there is nothing like a "key exchange" before. So we will only support, as I stated, the connections that have the same key. And I even did not try to DNAT the packets. I have not thinked much about it but for a "full"(only connections with same key) solution we would need something alongside the xt_tcpudp.c (and userspace code) where we could match different keys to allow the DNAT code to redirect the connections to different hosts. The SNAT part only should be easy but I don't know if that is likely to be accepted. What's your opinion? -Jorge ============================================================== Jorge Boncompte - Ingenieria y Gestion de RED DTI2 - Desarrollo de la Tecnologia de las Comunicaciones -------------------------------------------------------------- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 ============================================================== - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be made. ============================================================== From kaber at trash.net Wed May 2 15:52:56 2007 From: kaber at trash.net (Patrick McHardy) Date: Wed May 2 16:54:31 2007 Subject: [PATCH] xx_nat_proto_gre: do not modify/corrupt GREv0 packets thought NAT In-Reply-To: <029801c78cc0$91179600$061010ac@intranet.dti2.net> References: <00c501c7829e$6209edd0$061010ac@intranet.dti2.net> <462DFD1D.1060706@trash.net> <101c01c78829$24a70230$061010ac@intranet.dti2.net> <4631DCA3.4020701@trash.net> <00ef01c788c1$e32a62e0$061010ac@intranet.dti2.net> <46388337.3060800@trash.net> <027301c78cbc$baff1cd0$061010ac@intranet.dti2.net> <463890D6.9060605@trash.net> <029801c78cc0$91179600$061010ac@intranet.dti2.net> Message-ID: <463897B8.1090306@trash.net> Jorge Boncompte [DTI2] wrote: > ----- Original Message ----- From: "Patrick McHardy" >> I think the problem with this is that we don't know whether both keys >> are identical at connection setup time and thus might fail to even >> track the connection if they are not. > > > Yes, you are right, we don't know if both keys are identical as there > is nothing like a "key exchange" before. So we will only support, as I > stated, the connections that have the same key. And I even did not try > to DNAT the packets. The problem is that this at the same time causes us *not* to work properly anymore with connections with different keys, right? > I have not thinked much about it but for a "full"(only connections > with same key) solution we would need something alongside the > xt_tcpudp.c (and userspace code) where we could match different keys to > allow the DNAT code to redirect the connections to different hosts. > The SNAT part only should be easy but I don't know if that is likely > to be accepted. What's your opinion? I'll take it a patch if doesn't break something else (like connections with different keys). From jengelh at linux01.gwdg.de Wed May 2 19:50:59 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Wed May 2 20:51:17 2007 Subject: State of the conntrack match In-Reply-To: References: Message-ID: On Apr 30 2007 15:31, Christoph Lenggenhager wrote: > I would like to use a conntrack match (i.e. -m conntrack --ctorigdst > ...), but I miss the ability to filter for the original source and > destination ports. > > When going through the archives of netfilter-devel, I see that the > conntrack match has originally been developed by Marc Boucher. > Back in 2002, Henrik Norstr?m wrote a patch to it that would precisely > fit my needs. > (cf. > http://lists.netfilter.org/pipermail/netfilter-devel/2002-July/008382.html) > Unfortunately, this effort seems to have died with the advise from > Harald Welte to contact Marc Boucher directly. > > My questions are now: > - What is the status of the conntrack match? Is it just "there" to be > used, but nobody ever wants to touch it again? The xt_conntrack match is not outdated. In fact, it ought to replace xt_state, but xt_state has yet to be removed from the kernel. (xt_state is not even tagged deprecated/obsolete, maybe we should notify R.Day) > - Would it be appreciated to take up Henrik's (old) ideas? Is there a > chance to take such changes into the main tree? Since I do not know > better: Is this a "good" idea or does it make you scream and run away? > > Well, this is more a user-related question: > - Assuming conntrack match is too old and out-dated, is there an > alternative way to filter based on the original data (addresses and > ports) of a packet? > > Thanks for any reply. > > Kind regards, > christoph Jan -- From mike at it-loops.com Wed May 2 22:04:23 2007 From: mike at it-loops.com (Michael Guntsche) Date: Wed May 2 23:04:28 2007 Subject: RTSP support for kernels >= 2.6.20 [patchomatic patch] In-Reply-To: <462C9BAE.8010001@trash.net> References: <39DCB6E6-58AA-4994-8530-16BB8FC85704@it-loops.com> <46228193.1040707@trash.net> <92EB4CD4-15DB-4C30-8EBD-774546F5B697@it-loops.com> <2AFE2224-4F76-4199-9D41-F9AB48A57E9E@it-loops.com> <46238CB4.3050504@trash.net> <46259FAD.5040401@trash.net> <21896397-CBCD-4316-8C36-84BE051395ED@it-loops.com> <72A36DB9-BC11-48B7-B450-96F701631709@it-loops.com> <462C9BAE.8010001@trash.net> Message-ID: <68F6B0B3-7A63-4933-86B0-50E73E03B227@it-loops.com> On Apr 23, 2007, at 13:42, Patrick McHardy wrote: > Would you be interested in maintaining this in an external repository? > That should save both of us work, you don't need to submit patches, > I don't need to apply them :) Just a heads up. The patch is available at http://mike.it-loops.com/rtsp I'll try to keep it up to date with newer kernel versions. Kind regards, Michael From frozenspot at gmail.com Thu May 3 01:06:05 2007 From: frozenspot at gmail.com (fender) Date: Thu May 3 02:06:19 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA Message-ID: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> Hi, We hope that this project can be added to the p-o-m, as netfilter experimental part. (*) Abstract The PortKnockO Project implements Port Knocking and SPA (Simple Packet Authentication) in kernel space, as a netfilter match extension. For instance, this can be used to avoid brute force attacks to ssh or ftp services. It allows you to send messages from the kernel module to a user application. For instance, this would enable to start up an application (as a web server), after a peer has knocked the ports specified in a port knocking rule. Pros: + You can configure Port Knocking or SPA rules with the iptables syntax. + It does not require any daemons running in background. + You do not need to know a new syntax depending on an application. + The netfilter module can send messages to an user application through netlink sockets. (*) Status This project is in beta version and it is still under development. (*) You can check the source code out here: svn checkout svn://svn.berlios.de/portknocko/trunk (*) More information at http://portknocko.berlios.de/ Any feedback is welcome! Regards, -- J. Federico Hernandez -------------- next part -------------- A non-text attachment was scrubbed... Name: pknock-0.3.tar.gz Type: application/x-gzip Size: 20648 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20070503/c5b7267f/pknock-0.3.tar-0001.bin From kaber at trash.net Thu May 3 03:25:56 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 3 04:26:27 2007 Subject: [NETFILTER 00/04]: Netfilter update Message-ID: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> Hi Dave, these patches include Herbert's SIP fix, the GRE memory corruption fix, a change to the DNAT target to accept the port randomization option and some small bridge netfilter cleanup. Please apply, thanks. include/linux/netfilter/nf_conntrack_proto_gre.h | 18 --- include/linux/netfilter_bridge.h | 25 ++-- net/bridge/br_netfilter.c | 138 ++++++----------------- net/ipv4/netfilter/nf_nat_proto_gre.c | 20 +-- net/ipv4/netfilter/nf_nat_rule.c | 4 net/ipv4/netfilter/nf_nat_sip.c | 26 ++++ 6 files changed, 89 insertions(+), 142 deletions(-) Herbert Xu (1): [NETFILTER]: sip: Fix RTP address NAT Jorge Boncompte (1): [NETFILTER]: nf_nat_proto_gre: do not modify/corrupt GREv0 packets through NAT Patrick McHardy (2): [NETFILTER]: ipt_DNAT: accept port randomization option [NETFILTER]: bridge netfilter: consolidate header pushing/pulling code From kaber at trash.net Thu May 3 03:25:57 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 3 04:26:32 2007 Subject: [NETFILTER 01/04]: ipt_DNAT: accept port randomization option In-Reply-To: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> Message-ID: <20070503012439.12818.28836.sendpatchset@localhost.localdomain> [NETFILTER]: ipt_DNAT: accept port randomization option Also accept the --random option for DNAT to allow randomly selecting a destination port from the given range. Signed-off-by: Patrick McHardy --- commit 316258f1e782f387bcd01fd81d673aaeec24b8dc tree 99e75850f1927d958ee195cb9294f8b6b15302f9 parent dc87c3985e9b442c60994308a96f887579addc39 author Patrick McHardy Wed, 02 May 2007 16:17:22 +0200 committer Patrick McHardy Wed, 02 May 2007 16:17:22 +0200 net/ipv4/netfilter/nf_nat_rule.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/net/ipv4/netfilter/nf_nat_rule.c b/net/ipv4/netfilter/nf_nat_rule.c index 2a28339..2534f71 100644 --- a/net/ipv4/netfilter/nf_nat_rule.c +++ b/net/ipv4/netfilter/nf_nat_rule.c @@ -226,10 +226,6 @@ static int ipt_dnat_checkentry(const char *tablename, printk("DNAT: multiple ranges no longer supported\n"); return 0; } - if (mr->range[0].flags & IP_NAT_RANGE_PROTO_RANDOM) { - printk("DNAT: port randomization not supported\n"); - return 0; - } return 1; } From kaber at trash.net Thu May 3 03:25:59 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 3 04:26:33 2007 Subject: [NETFILTER 02/04]: nf_nat_proto_gre: do not modify/corrupt GREv0 packets through NAT In-Reply-To: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> Message-ID: <20070503012440.12818.75627.sendpatchset@localhost.localdomain> [NETFILTER]: nf_nat_proto_gre: do not modify/corrupt GREv0 packets through NAT While porting some changes of the 2.6.21-rc7 pptp/proto_gre conntrack and nat modules to a 2.4.32 kernel I noticed that the gre_key function returns a wrong pointer to the GRE key of a version 0 packet thus corrupting the packet payload. The intended behaviour for GREv0 packets is to act like nf_conntrack_proto_generic/nf_nat_proto_unknown so I have ripped the offending functions (not used anymore) and modified the nf_nat_proto_gre modules to not touch version 0 (non PPTP) packets. Signed-off-by: Jorge Boncompte Signed-off-by: Patrick McHardy --- commit 08130cb0faa275f6a8290a39942e58c18cec3533 tree 01dab60a8b7759c68701292b636000bc063492d3 parent 316258f1e782f387bcd01fd81d673aaeec24b8dc author Jorge Boncompte Wed, 02 May 2007 16:17:31 +0200 committer Patrick McHardy Thu, 03 May 2007 02:51:46 +0200 include/linux/netfilter/nf_conntrack_proto_gre.h | 18 ------------------ net/ipv4/netfilter/nf_nat_proto_gre.c | 20 ++++++++------------ 2 files changed, 8 insertions(+), 30 deletions(-) diff --git a/include/linux/netfilter/nf_conntrack_proto_gre.h b/include/linux/netfilter/nf_conntrack_proto_gre.h index 4e6bbce..535e421 100644 --- a/include/linux/netfilter/nf_conntrack_proto_gre.h +++ b/include/linux/netfilter/nf_conntrack_proto_gre.h @@ -87,24 +87,6 @@ int nf_ct_gre_keymap_add(struct nf_conn *ct, enum ip_conntrack_dir dir, /* delete keymap entries */ void nf_ct_gre_keymap_destroy(struct nf_conn *ct); -/* get pointer to gre key, if present */ -static inline __be32 *gre_key(struct gre_hdr *greh) -{ - if (!greh->key) - return NULL; - if (greh->csum || greh->routing) - return (__be32 *)(greh+sizeof(*greh)+4); - return (__be32 *)(greh+sizeof(*greh)); -} - -/* get pointer ot gre csum, if present */ -static inline __sum16 *gre_csum(struct gre_hdr *greh) -{ - if (!greh->csum) - return NULL; - return (__sum16 *)(greh+sizeof(*greh)); -} - extern void nf_ct_gre_keymap_flush(void); extern void nf_nat_need_gre(void); diff --git a/net/ipv4/netfilter/nf_nat_proto_gre.c b/net/ipv4/netfilter/nf_nat_proto_gre.c index e5a34c1..af8ba79 100644 --- a/net/ipv4/netfilter/nf_nat_proto_gre.c +++ b/net/ipv4/netfilter/nf_nat_proto_gre.c @@ -72,6 +72,11 @@ gre_unique_tuple(struct nf_conntrack_tuple *tuple, __be16 *keyptr; unsigned int min, i, range_size; + /* If there is no master conntrack we are not PPTP, + do not change tuples */ + if (!conntrack->master) + return 0; + if (maniptype == IP_NAT_MANIP_SRC) keyptr = &tuple->src.u.gre.key; else @@ -122,18 +127,9 @@ gre_manip_pkt(struct sk_buff **pskb, unsigned int iphdroff, if (maniptype != IP_NAT_MANIP_DST) return 1; switch (greh->version) { - case 0: - if (!greh->key) { - DEBUGP("can't nat GRE w/o key\n"); - break; - } - if (greh->csum) { - /* FIXME: Never tested this code... */ - nf_proto_csum_replace4(gre_csum(greh), *pskb, - *(gre_key(greh)), - tuple->dst.u.gre.key, 0); - } - *(gre_key(greh)) = tuple->dst.u.gre.key; + case GRE_VERSION_1701: + /* We do not currently NAT any GREv0 packets. + * Try to behave like "nf_nat_proto_unknown" */ break; case GRE_VERSION_PPTP: DEBUGP("call_id -> 0x%04x\n", ntohs(tuple->dst.u.gre.key)); From kaber at trash.net Thu May 3 03:26:00 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 3 04:26:38 2007 Subject: [NETFILTER 03/04]: sip: Fix RTP address NAT In-Reply-To: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> Message-ID: <20070503012441.12818.26845.sendpatchset@localhost.localdomain> [NETFILTER]: sip: Fix RTP address NAT I needed to use this recently to talk to a Cisco server. In my case I only did SNAT while the Cisco server used a different address for RTP traffic than the one for SIP. I discovered that nf_nat_sip NATed the RTP address to the SIP one which was unnecessary but OK. However, in doing so it did not DNAT the destination address on the RTP traffic to the Cisco back to the original RTP address. This patch corrects this by noting down the RTP address and using it when the expectation fires. Signed-off-by: Herbert Xu Signed-off-by: Patrick McHardy --- commit 63ce4c4edbf300cf7c5b1d219feca1e687bdbc4b tree 105983a8043f83a79b0149eb8acc2c189217288d parent 08130cb0faa275f6a8290a39942e58c18cec3533 author Herbert Xu Wed, 02 May 2007 16:17:39 +0200 committer Patrick McHardy Thu, 03 May 2007 02:51:50 +0200 net/ipv4/netfilter/nf_nat_sip.c | 26 +++++++++++++++++++++++++- 1 files changed, 25 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/nf_nat_sip.c b/net/ipv4/netfilter/nf_nat_sip.c index bfd88e4..fac97cf 100644 --- a/net/ipv4/netfilter/nf_nat_sip.c +++ b/net/ipv4/netfilter/nf_nat_sip.c @@ -222,6 +222,29 @@ static unsigned int mangle_sdp(struct sk_buff **pskb, return mangle_content_len(pskb, ctinfo, ct, dptr); } +static void ip_nat_sdp_expect(struct nf_conn *ct, + struct nf_conntrack_expect *exp) +{ + struct nf_nat_range range; + + /* This must be a fresh one. */ + BUG_ON(ct->status & IPS_NAT_DONE_MASK); + + /* Change src to where master sends to */ + range.flags = IP_NAT_RANGE_MAP_IPS; + range.min_ip = range.max_ip + = ct->master->tuplehash[!exp->dir].tuple.dst.u3.ip; + /* hook doesn't matter, but it has to do source manip */ + nf_nat_setup_info(ct, &range, NF_IP_POST_ROUTING); + + /* For DST manip, map port here to where it's expected. */ + range.flags = (IP_NAT_RANGE_MAP_IPS | IP_NAT_RANGE_PROTO_SPECIFIED); + range.min = range.max = exp->saved_proto; + range.min_ip = range.max_ip = exp->saved_ip; + /* hook doesn't matter, but it has to do destination manip */ + nf_nat_setup_info(ct, &range, NF_IP_PRE_ROUTING); +} + /* So, this packet has hit the connection tracking matching code. Mangle it, and change the expectation to match the new version. */ static unsigned int ip_nat_sdp(struct sk_buff **pskb, @@ -239,13 +262,14 @@ static unsigned int ip_nat_sdp(struct sk_buff **pskb, /* Connection will come from reply */ newip = ct->tuplehash[!dir].tuple.dst.u3.ip; + exp->saved_ip = exp->tuple.dst.u3.ip; exp->tuple.dst.u3.ip = newip; exp->saved_proto.udp.port = exp->tuple.dst.u.udp.port; exp->dir = !dir; /* When you see the packet, we need to NAT it the same as the this one. */ - exp->expectfn = nf_nat_follow_master; + exp->expectfn = ip_nat_sdp_expect; /* Try to get same port: if not, try to change it. */ for (port = ntohs(exp->saved_proto.udp.port); port != 0; port++) { From kaber at trash.net Thu May 3 03:26:01 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 3 04:26:39 2007 Subject: [NETFILTER 04/04]: bridge netfilter: consolidate header pushing/pulling code In-Reply-To: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> Message-ID: <20070503012443.12818.98754.sendpatchset@localhost.localdomain> [NETFILTER]: bridge netfilter: consolidate header pushing/pulling code Consolidate the common push/pull sequences into a few helper functions. Signed-off-by: Patrick McHardy --- commit e439550c01bb8fa2eff00a2dfb4cfd26a966e8ce tree 43331213cbcf138328638dce0075cbedb20e5ba3 parent 63ce4c4edbf300cf7c5b1d219feca1e687bdbc4b author Patrick McHardy Wed, 02 May 2007 16:17:51 +0200 committer Patrick McHardy Thu, 03 May 2007 02:51:50 +0200 include/linux/netfilter_bridge.h | 25 ++++--- net/bridge/br_netfilter.c | 138 +++++++++++--------------------------- 2 files changed, 56 insertions(+), 107 deletions(-) diff --git a/include/linux/netfilter_bridge.h b/include/linux/netfilter_bridge.h index 1906003..533ee35 100644 --- a/include/linux/netfilter_bridge.h +++ b/include/linux/netfilter_bridge.h @@ -55,18 +55,25 @@ static inline int nf_bridge_maybe_copy_header(struct sk_buff *skb) return 0; } +static inline unsigned int nf_bridge_encap_header_len(const struct sk_buff *skb) +{ + switch (skb->protocol) { + case __constant_htons(ETH_P_8021Q): + return VLAN_HLEN; + case __constant_htons(ETH_P_PPP_SES): + return PPPOE_SES_HLEN; + default: + return 0; + } +} + /* This is called by the IP fragmenting code and it ensures there is * enough room for the encapsulating header (if there is one). */ -static inline int nf_bridge_pad(const struct sk_buff *skb) +static inline unsigned int nf_bridge_pad(const struct sk_buff *skb) { - int padding = 0; - - if (skb->nf_bridge && skb->protocol == htons(ETH_P_8021Q)) - padding = VLAN_HLEN; - else if (skb->nf_bridge && skb->protocol == htons(ETH_P_PPP_SES)) - padding = PPPOE_SES_HLEN; - - return padding; + if (skb->nf_bridge) + return nf_bridge_encap_header_len(skb); + return 0; } struct bridge_skb_cb { diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c index 9b2986b..fa77987 100644 --- a/net/bridge/br_netfilter.c +++ b/net/bridge/br_netfilter.c @@ -142,14 +142,33 @@ static inline struct nf_bridge_info *nf_bridge_alloc(struct sk_buff *skb) return skb->nf_bridge; } -static inline void nf_bridge_save_header(struct sk_buff *skb) +static inline void nf_bridge_push_encap_header(struct sk_buff *skb) +{ + unsigned int len = nf_bridge_encap_header_len(skb); + + skb_push(skb, len); + skb->network_header -= len; +} + +static inline void nf_bridge_pull_encap_header(struct sk_buff *skb) { - int header_size = ETH_HLEN; + unsigned int len = nf_bridge_encap_header_len(skb); + + skb_pull(skb, len); + skb->network_header += len; +} - if (skb->protocol == htons(ETH_P_8021Q)) - header_size += VLAN_HLEN; - else if (skb->protocol == htons(ETH_P_PPP_SES)) - header_size += PPPOE_SES_HLEN; +static inline void nf_bridge_pull_encap_header_rcsum(struct sk_buff *skb) +{ + unsigned int len = nf_bridge_encap_header_len(skb); + + skb_pull_rcsum(skb, len); + skb->network_header += len; +} + +static inline void nf_bridge_save_header(struct sk_buff *skb) +{ + int header_size = ETH_HLEN + nf_bridge_encap_header_len(skb); skb_copy_from_linear_data_offset(skb, -header_size, skb->nf_bridge->data, header_size); @@ -162,12 +181,7 @@ static inline void nf_bridge_save_header(struct sk_buff *skb) int nf_bridge_copy_header(struct sk_buff *skb) { int err; - int header_size = ETH_HLEN; - - if (skb->protocol == htons(ETH_P_8021Q)) - header_size += VLAN_HLEN; - else if (skb->protocol == htons(ETH_P_PPP_SES)) - header_size += PPPOE_SES_HLEN; + int header_size = ETH_HLEN + nf_bridge_encap_header_len(skb); err = skb_cow(skb, header_size); if (err) @@ -175,11 +189,7 @@ int nf_bridge_copy_header(struct sk_buff *skb) skb_copy_to_linear_data_offset(skb, -header_size, skb->nf_bridge->data, header_size); - - if (skb->protocol == htons(ETH_P_8021Q)) - __skb_push(skb, VLAN_HLEN); - else if (skb->protocol == htons(ETH_P_PPP_SES)) - __skb_push(skb, PPPOE_SES_HLEN); + __skb_push(skb, nf_bridge_encap_header_len(skb)); return 0; } @@ -200,13 +210,7 @@ static int br_nf_pre_routing_finish_ipv6(struct sk_buff *skb) dst_hold(skb->dst); skb->dev = nf_bridge->physindev; - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_push(skb, VLAN_HLEN); - skb->network_header -= VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_push(skb, PPPOE_SES_HLEN); - skb->network_header -= PPPOE_SES_HLEN; - } + nf_bridge_push_encap_header(skb); NF_HOOK_THRESH(PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL, br_handle_frame_finish, 1); @@ -284,13 +288,7 @@ static int br_nf_pre_routing_finish_bridge(struct sk_buff *skb) if (!skb->dev) kfree_skb(skb); else { - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_pull(skb, VLAN_HLEN); - skb->network_header += VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_pull(skb, PPPOE_SES_HLEN); - skb->network_header += PPPOE_SES_HLEN; - } + nf_bridge_pull_encap_header(skb); skb->dst->output(skb); } return 0; @@ -356,15 +354,7 @@ bridged_dnat: * bridged frame */ nf_bridge->mask |= BRNF_BRIDGED_DNAT; skb->dev = nf_bridge->physindev; - if (skb->protocol == - htons(ETH_P_8021Q)) { - skb_push(skb, VLAN_HLEN); - skb->network_header -= VLAN_HLEN; - } else if(skb->protocol == - htons(ETH_P_PPP_SES)) { - skb_push(skb, PPPOE_SES_HLEN); - skb->network_header -= PPPOE_SES_HLEN; - } + nf_bridge_push_encap_header(skb); NF_HOOK_THRESH(PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL, br_nf_pre_routing_finish_bridge, @@ -380,13 +370,7 @@ bridged_dnat: } skb->dev = nf_bridge->physindev; - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_push(skb, VLAN_HLEN); - skb->network_header -= VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_push(skb, PPPOE_SES_HLEN); - skb->network_header -= PPPOE_SES_HLEN; - } + nf_bridge_push_encap_header(skb); NF_HOOK_THRESH(PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL, br_handle_frame_finish, 1); @@ -536,14 +520,7 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff **pskb, #endif if ((skb = skb_share_check(*pskb, GFP_ATOMIC)) == NULL) goto out; - - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_pull_rcsum(skb, VLAN_HLEN); - skb->network_header += VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_pull_rcsum(skb, PPPOE_SES_HLEN); - skb->network_header += PPPOE_SES_HLEN; - } + nf_bridge_pull_encap_header_rcsum(skb); return br_nf_pre_routing_ipv6(hook, skb, in, out, okfn); } #ifdef CONFIG_SYSCTL @@ -557,14 +534,7 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff **pskb, if ((skb = skb_share_check(*pskb, GFP_ATOMIC)) == NULL) goto out; - - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_pull_rcsum(skb, VLAN_HLEN); - skb->network_header += VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_pull_rcsum(skb, PPPOE_SES_HLEN); - skb->network_header += PPPOE_SES_HLEN; - } + nf_bridge_pull_encap_header_rcsum(skb); if (!pskb_may_pull(skb, sizeof(struct iphdr))) goto inhdr_error; @@ -642,13 +612,7 @@ static int br_nf_forward_finish(struct sk_buff *skb) } else { in = *((struct net_device **)(skb->cb)); } - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_push(skb, VLAN_HLEN); - skb->network_header -= VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_push(skb, PPPOE_SES_HLEN); - skb->network_header -= PPPOE_SES_HLEN; - } + nf_bridge_push_encap_header(skb); NF_HOOK_THRESH(PF_BRIDGE, NF_BR_FORWARD, skb, in, skb->dev, br_forward_finish, 1); return 0; @@ -682,13 +646,7 @@ static unsigned int br_nf_forward_ip(unsigned int hook, struct sk_buff **pskb, else pf = PF_INET6; - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_pull(*pskb, VLAN_HLEN); - (*pskb)->network_header += VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_pull(*pskb, PPPOE_SES_HLEN); - (*pskb)->network_header += PPPOE_SES_HLEN; - } + nf_bridge_pull_encap_header(*pskb); nf_bridge = skb->nf_bridge; if (skb->pkt_type == PACKET_OTHERHOST) { @@ -722,15 +680,12 @@ static unsigned int br_nf_forward_arp(unsigned int hook, struct sk_buff **pskb, if (skb->protocol != htons(ETH_P_ARP)) { if (!IS_VLAN_ARP(skb)) return NF_ACCEPT; - skb_pull(*pskb, VLAN_HLEN); - (*pskb)->network_header += VLAN_HLEN; + nf_bridge_pull_encap_header(*pskb); } if (arp_hdr(skb)->ar_pln != 4) { - if (IS_VLAN_ARP(skb)) { - skb_push(*pskb, VLAN_HLEN); - (*pskb)->network_header -= VLAN_HLEN; - } + if (IS_VLAN_ARP(skb)) + nf_bridge_push_encap_header(*pskb); return NF_ACCEPT; } *d = (struct net_device *)in; @@ -777,13 +732,7 @@ static unsigned int br_nf_local_out(unsigned int hook, struct sk_buff **pskb, skb->pkt_type = PACKET_OTHERHOST; nf_bridge->mask ^= BRNF_PKT_TYPE; } - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_push(skb, VLAN_HLEN); - skb->network_header -= VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_push(skb, PPPOE_SES_HLEN); - skb->network_header -= PPPOE_SES_HLEN; - } + nf_bridge_push_encap_header(skb); NF_HOOK(PF_BRIDGE, NF_BR_FORWARD, skb, realindev, skb->dev, br_forward_finish); @@ -848,14 +797,7 @@ static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb, nf_bridge->mask |= BRNF_PKT_TYPE; } - if (skb->protocol == htons(ETH_P_8021Q)) { - skb_pull(skb, VLAN_HLEN); - skb->network_header += VLAN_HLEN; - } else if (skb->protocol == htons(ETH_P_PPP_SES)) { - skb_pull(skb, PPPOE_SES_HLEN); - skb->network_header += PPPOE_SES_HLEN; - } - + nf_bridge_pull_encap_header(skb); nf_bridge_save_header(skb); #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) From davem at davemloft.net Thu May 3 12:34:13 2007 From: davem at davemloft.net (David Miller) Date: Thu May 3 13:34:21 2007 Subject: [NETFILTER 01/04]: ipt_DNAT: accept port randomization option In-Reply-To: <20070503012439.12818.28836.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> <20070503012439.12818.28836.sendpatchset@localhost.localdomain> Message-ID: <20070503.033413.130139791.davem@davemloft.net> From: Patrick McHardy Date: Thu, 3 May 2007 03:25:57 +0200 (MEST) > [NETFILTER]: ipt_DNAT: accept port randomization option > > Also accept the --random option for DNAT to allow randomly selecting a > destination port from the given range. > > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 3 12:34:59 2007 From: davem at davemloft.net (David Miller) Date: Thu May 3 13:35:07 2007 Subject: [NETFILTER 02/04]: nf_nat_proto_gre: do not modify/corrupt GREv0 packets through NAT In-Reply-To: <20070503012440.12818.75627.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> <20070503012440.12818.75627.sendpatchset@localhost.localdomain> Message-ID: <20070503.033459.75756192.davem@davemloft.net> From: Patrick McHardy Date: Thu, 3 May 2007 03:25:59 +0200 (MEST) > [NETFILTER]: nf_nat_proto_gre: do not modify/corrupt GREv0 packets through NAT > > While porting some changes of the 2.6.21-rc7 pptp/proto_gre conntrack > and nat modules to a 2.4.32 kernel I noticed that the gre_key function > returns a wrong pointer to the GRE key of a version 0 packet thus > corrupting the packet payload. > > The intended behaviour for GREv0 packets is to act like > nf_conntrack_proto_generic/nf_nat_proto_unknown so I have ripped the > offending functions (not used anymore) and modified the > nf_nat_proto_gre modules to not touch version 0 (non PPTP) packets. > > Signed-off-by: Jorge Boncompte > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 3 12:35:54 2007 From: davem at davemloft.net (David Miller) Date: Thu May 3 13:36:01 2007 Subject: [NETFILTER 03/04]: sip: Fix RTP address NAT In-Reply-To: <20070503012441.12818.26845.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> <20070503012441.12818.26845.sendpatchset@localhost.localdomain> Message-ID: <20070503.033554.15429628.davem@davemloft.net> From: Patrick McHardy Date: Thu, 3 May 2007 03:26:00 +0200 (MEST) > [NETFILTER]: sip: Fix RTP address NAT > > I needed to use this recently to talk to a Cisco server. In my case > I only did SNAT while the Cisco server used a different address for > RTP traffic than the one for SIP. I discovered that nf_nat_sip NATed > the RTP address to the SIP one which was unnecessary but OK. However, > in doing so it did not DNAT the destination address on the RTP traffic > to the Cisco back to the original RTP address. > > This patch corrects this by noting down the RTP address and using it > when the expectation fires. > > Signed-off-by: Herbert Xu > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 3 12:36:24 2007 From: davem at davemloft.net (David Miller) Date: Thu May 3 13:36:33 2007 Subject: [NETFILTER 04/04]: bridge netfilter: consolidate header pushing/pulling code In-Reply-To: <20070503012443.12818.98754.sendpatchset@localhost.localdomain> References: <20070503012437.12818.39126.sendpatchset@localhost.localdomain> <20070503012443.12818.98754.sendpatchset@localhost.localdomain> Message-ID: <20070503.033624.102931302.davem@davemloft.net> From: Patrick McHardy Date: Thu, 3 May 2007 03:26:01 +0200 (MEST) > [NETFILTER]: bridge netfilter: consolidate header pushing/pulling code > > Consolidate the common push/pull sequences into a few helper functions. > > Signed-off-by: Patrick McHardy Also applied, thanks. From kaber at trash.net Thu May 3 13:00:19 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 3 14:02:22 2007 Subject: RTSP support for kernels >= 2.6.20 [patchomatic patch] In-Reply-To: <68F6B0B3-7A63-4933-86B0-50E73E03B227@it-loops.com> References: <39DCB6E6-58AA-4994-8530-16BB8FC85704@it-loops.com> <46228193.1040707@trash.net> <92EB4CD4-15DB-4C30-8EBD-774546F5B697@it-loops.com> <2AFE2224-4F76-4199-9D41-F9AB48A57E9E@it-loops.com> <46238CB4.3050504@trash.net> <46259FAD.5040401@trash.net> <21896397-CBCD-4316-8C36-84BE051395ED@it-loops.com> <72A36DB9-BC11-48B7-B450-96F701631709@it-loops.com> <462C9BAE.8010001@trash.net> <68F6B0B3-7A63-4933-86B0-50E73E03B227@it-loops.com> Message-ID: <4639C0C3.10200@trash.net> Michael Guntsche wrote: > > On Apr 23, 2007, at 13:42, Patrick McHardy wrote: > >> Would you be interested in maintaining this in an external repository? >> That should save both of us work, you don't need to submit patches, >> I don't need to apply them :) > > > Just a heads up. > The patch is available at http://mike.it-loops.com/rtsp > I'll try to keep it up to date with newer kernel versions. If you'd add it in pom external repository format I could add it to the pomng sources.list. From kaber at trash.net Thu May 3 13:01:36 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 3 14:03:39 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> Message-ID: <4639C110.6000407@trash.net> fender wrote: > We hope that this project can be added to the p-o-m, as netfilter > experimental part. We don't add entirely externally developed things to pom anymore, but we could add an external repository to the sources.list. From davila at nicaraguaopensource.com Thu May 3 18:16:05 2007 From: davila at nicaraguaopensource.com (Jorge Davila) Date: Thu May 3 19:16:18 2007 Subject: [PATCH] Unspecified proto should print as "all" in iptables -L In-Reply-To: <20070430200930.GA8187@linuxace.com> References: <20070428220206.GA26272@linuxace.com> <463524E7.60107@netfilter.org> <20070430171317.GA6904@linuxace.com> <20070430173654.GB6904@linuxace.com> <20070430200930.GA8187@linuxace.com> Message-ID: Sorry for the delay in answering your question ... Well, it's because some users inside the internal networks under my administration visit http://www.grc.com/ and run the Shields Up! to see the open ports in the gateways and they see the port 0 open. That was the reason to apply the rule. Jorge. On Mon, 30 Apr 2007 13:09:30 -0700 Phil Oester wrote: > On Mon, Apr 30, 2007 at 12:17:13PM -0600, Jorge Davila wrote: >> I was trying to apply a rule >> >> iptables -p 0 -j DROP >> >> to block only the protocol 0. I know now why that rule was not working. >> >> I think that -p 0 must be a reference to the protocol 0 and not to all >> protocols. >> >> Jorge. > > Which application uses protocol 0? Or is this a custom app you wrote? > > Phil > Jorge Isaac Davila Lopez Nicaragua Open Source davila@nicaraguaopensource.com From c-d.hailfinger.devel.2006 at gmx.net Thu May 3 18:33:47 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu May 3 19:32:17 2007 Subject: [PATCH] Unspecified proto should print as "all" in iptables -L In-Reply-To: References: <20070428220206.GA26272@linuxace.com> <463524E7.60107@netfilter.org> <20070430171317.GA6904@linuxace.com> <20070430173654.GB6904@linuxace.com> <20070430200930.GA8187@linuxace.com> Message-ID: <463A0EEB.5050402@gmx.net> On 03.05.2007 18:16, Jorge Davila wrote: > Well, it's because some users inside the internal networks under my > administration visit http://www.grc.com/ and run the Shields Up! to see > the open ports in the gateways and they see the port 0 open. That was > the reason to apply the rule. Ah cool, that's another datapoint when trying to guess the firewall ruleset. Port 0 not filtered roughly means "default policy is ACCEPT". (Well, not quite. But close.) Regards, Carl-Daniel From mike at it-loops.com Thu May 3 19:18:37 2007 From: mike at it-loops.com (Michael Guntsche) Date: Thu May 3 20:18:46 2007 Subject: RTSP support for kernels >= 2.6.20 [patchomatic patch] In-Reply-To: <4639C0C3.10200@trash.net> References: <39DCB6E6-58AA-4994-8530-16BB8FC85704@it-loops.com> <46228193.1040707@trash.net> <92EB4CD4-15DB-4C30-8EBD-774546F5B697@it-loops.com> <2AFE2224-4F76-4199-9D41-F9AB48A57E9E@it-loops.com> <46238CB4.3050504@trash.net> <46259FAD.5040401@trash.net> <21896397-CBCD-4316-8C36-84BE051395ED@it-loops.com> <72A36DB9-BC11-48B7-B450-96F701631709@it-loops.com> <462C9BAE.8010001@trash.net> <68F6B0B3-7A63-4933-86B0-50E73E03B227@it-loops.com> <4639C0C3.10200@trash.net> Message-ID: <65BC6C0B-04E8-47EE-B534-2E7325044955@it-loops.com> Hi Patrick, On May 3, 2007, at 13:00, Patrick McHardy wrote: > If you'd add it in pom external repository format I could add it to > the pomng sources.list. > I prepared a repository but I am not sure how to package it. Should I add it to the existing rtsp-conntrack module, which does not work right now, since --download blames that rtsp-conntrack is not external, or should I leave the old module as is and add a new one called nf-rtsp-conntrack wich requires a kernel >= 2.6.20? Michael From kernel at linuxace.com Thu May 3 19:31:21 2007 From: kernel at linuxace.com (Phil Oester) Date: Thu May 3 20:31:31 2007 Subject: [PATCH] Unspecified proto should print as "all" in iptables -L In-Reply-To: <463A0EEB.5050402@gmx.net> References: <20070428220206.GA26272@linuxace.com> <463524E7.60107@netfilter.org> <20070430171317.GA6904@linuxace.com> <20070430173654.GB6904@linuxace.com> <20070430200930.GA8187@linuxace.com> <463A0EEB.5050402@gmx.net> Message-ID: <20070503173121.GA7998@linuxace.com> On Thu, May 03, 2007 at 06:33:47PM +0200, Carl-Daniel Hailfinger wrote: > On 03.05.2007 18:16, Jorge Davila wrote: > > Well, it's because some users inside the internal networks under my > > administration visit http://www.grc.com/ and run the Shields Up! to see > > the open ports in the gateways and they see the port 0 open. That was > > the reason to apply the rule. > > Ah cool, that's another datapoint when trying to guess the firewall > ruleset. Port 0 not filtered roughly means "default policy is ACCEPT". > (Well, not quite. But close.) Let's be clear here...we aren't talking about _PORT_ zero. We're talking about _PROTOCOL_ zero. Can you please elaborate on the specific need to filter _PROTOCOL_ zero? Phil From c-d.hailfinger.devel.2006 at gmx.net Thu May 3 19:45:19 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu May 3 20:43:47 2007 Subject: [PATCH] Unspecified proto should print as "all" in iptables -L In-Reply-To: <20070503173121.GA7998@linuxace.com> References: <20070428220206.GA26272@linuxace.com> <463524E7.60107@netfilter.org> <20070430171317.GA6904@linuxace.com> <20070430173654.GB6904@linuxace.com> <20070430200930.GA8187@linuxace.com> <463A0EEB.5050402@gmx.net> <20070503173121.GA7998@linuxace.com> Message-ID: <463A1FAF.5060207@gmx.net> On 03.05.2007 19:31, Phil Oester wrote: > On Thu, May 03, 2007 at 06:33:47PM +0200, Carl-Daniel Hailfinger wrote: >> On 03.05.2007 18:16, Jorge Davila wrote: >>> Well, it's because some users inside the internal networks under my >>> administration visit http://www.grc.com/ and run the Shields Up! to see >>> the open ports in the gateways and they see the port 0 open. That was >>> the reason to apply the rule. >> Ah cool, that's another datapoint when trying to guess the firewall >> ruleset. Port 0 not filtered roughly means "default policy is ACCEPT". >> (Well, not quite. But close.) > > Let's be clear here...we aren't talking about _PORT_ zero. We're talking > about _PROTOCOL_ zero. Can you please elaborate on the specific need > to filter _PROTOCOL_ zero? Sorry, my bad. There is no specific need on my side. It's just that some creative use of nmap enables me to learn more about target systems. I am entirely happy with the current situation. Regards, Carl-Daniel From frozenspot at gmail.com Thu May 3 20:01:49 2007 From: frozenspot at gmail.com (fender) Date: Thu May 3 21:01:57 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <4639C110.6000407@trash.net> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> Message-ID: <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> On 5/3/07, Patrick McHardy wrote: > fender wrote: > > We hope that this project can be added to the p-o-m, as netfilter > > experimental part. > > > We don't add entirely externally developed things to pom anymore, > but we could add an external repository to the sources.list. > Ok, that's a good news. What else should we do to be included there? Regards, -- Federico From oscar at ufomechanic.net Thu May 3 21:13:07 2007 From: oscar at ufomechanic.net (Oscar Mechanic) Date: Thu May 3 22:13:21 2007 Subject: libnetfilter-queue Message-ID: <1178219587.4261.31.camel@OSCARLAPLIN> Hi can anyone point me in the right direction for how to learn how to rewrite the packet using libnetfilter and then inject it. Is it as simple as grabbing the buffer from "nfq_get_payload" changing this and then setting the verdict, surely not. I know the checksums have to be changed then. If someone has an example that would be great. I have been all around netfilter/google/sourceforge/freshmeat and I still could not find any info. Thanks Oscar From kaber at trash.net Fri May 4 15:28:53 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 4 16:30:01 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> Message-ID: <463B3515.9090207@trash.net> fender wrote: > On 5/3/07, Patrick McHardy wrote: > >> fender wrote: >> > We hope that this project can be added to the p-o-m, as netfilter >> > experimental part. >> >> >> We don't add entirely externally developed things to pom anymore, >> but we could add an external repository to the sources.list. >> > > Ok, that's a good news. > > What else should we do to be included there? Nothing, just set up the repository and send me the link. From frozenspot at gmail.com Sat May 5 09:36:06 2007 From: frozenspot at gmail.com (fender) Date: Sat May 5 10:36:26 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <463B3515.9090207@trash.net> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> Message-ID: <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> On 5/4/07, Patrick McHardy wrote: > fender wrote: > > On 5/3/07, Patrick McHardy wrote: > > > >> fender wrote: > >> > We hope that this project can be added to the p-o-m, as netfilter > >> > experimental part. > >> > >> > >> We don't add entirely externally developed things to pom anymore, > >> but we could add an external repository to the sources.list. > >> > > > > Ok, that's a good news. > > > > What else should we do to be included there? > > > Nothing, just set up the repository and send me the link. > I'm sorry, I don't know what link of these will be the necessary: 1) http://portknocko.berlios.de/ ---> (project home page) 2) http://developer.berlios.de/project/showfiles.php?group_id=7093 ---> (.tar.gz files to download) 3) http://svn.berlios.de/svnroot/repos/portknocko/trunk Regards, -- J. Federico Hernandez From pablo at netfilter.org Sun May 6 17:37:03 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sun May 6 18:35:22 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> Message-ID: <463DF61F.50509@netfilter.org> fender wrote: > On 5/4/07, Patrick McHardy wrote: >> Nothing, just set up the repository and send me the link. > > I'm sorry, I don't know what link of these will be the necessary: > > 1) http://portknocko.berlios.de/ ---> (project home page) > > 2) http://developer.berlios.de/project/showfiles.php?group_id=7093 ---> > (.tar.gz files to download) > > 3) http://svn.berlios.de/svnroot/repos/portknocko/trunk No, Patrick means a link to your repository in pom-ng format. So everybody can get external patchlets via ./runme --download. 1) Create a tarball with your project in pom-ng format [1]. 2) Create a file called "index" that contains the name of your extension in the same directory where you have put the tarball 3) Send us the URL to add it to our sources.list file. [1] http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/ -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From jengelh at linux01.gwdg.de Sun May 6 18:37:44 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Sun May 6 19:40:42 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <463DF61F.50509@netfilter.org> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> Message-ID: On May 6 2007 17:37, Pablo Neira Ayuso wrote: >fender wrote: >> On 5/4/07, Patrick McHardy wrote: >>> Nothing, just set up the repository and send me the link. >> >> I'm sorry, I don't know what link of these will be the necessary: >> >> 1) http://portknocko.berlios.de/ ---> (project home page) >> >> 2) http://developer.berlios.de/project/showfiles.php?group_id=7093 ---> >> (.tar.gz files to download) >> >> 3) http://svn.berlios.de/svnroot/repos/portknocko/trunk > >No, Patrick means a link to your repository in pom-ng format. So >everybody can get external patchlets via ./runme --download. What bugs me with those external repositories is that there is no version control behind it. What's more, they can just "disappear" and in the worst case a module disappears (as in: web hoster killed the user), which is kinda sad. Not that it happened to me yet, but the chance is there. >1) Create a tarball with your project in pom-ng format [1]. >2) Create a file called "index" that contains the name of your extension > in the same directory where you have put the tarball >3) Send us the URL to add it to our sources.list file. > >[1] http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/ > >-- >The dawn of the fourth age of Linux firewalling is coming; a time of >great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris > Jan -- From pablo at netfilter.org Sun May 6 19:13:21 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sun May 6 20:11:38 2007 Subject: Nightly snapshots broken In-Reply-To: <46352233.2030508@netfilter.org> References: <20070429164325.GA29367@linuxace.com> <46352233.2030508@netfilter.org> Message-ID: <463E0CB1.7040104@netfilter.org> Pablo Neira Ayuso wrote: > Phil Oester wrote: >> Last iptables snapshot is dated 4/14. Can someone take a look? > > I'll look into this. Thanks Phil. JFYI: Now it works again. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Sun May 6 19:15:20 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sun May 6 20:13:37 2007 Subject: ftp.netfilter.org has a problem. In-Reply-To: <20070501071712.GA1601756@metu.edu.tr> References: <20070501071712.GA1601756@metu.edu.tr> Message-ID: <463E0D28.6040808@netfilter.org> husnu demir wrote: > I noticed that ftp side had some problems, or something changed. After "Apr 14", the files have zero sizes and it is the same almost all snapshots, pom-ng, ipset etc. > > I do not know who responsible. So I wrote here. Now it works again. Sorry for the inconvenience. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Mon May 7 02:39:22 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon May 7 03:37:49 2007 Subject: [ANNOUNCE] Netfilter Workshop 2007 in Karlsruhe, Germany Message-ID: <463E753A.4060300@netfilter.org> = Overview = Following the lastest successful workshop in Sevilla, Andalusia, Spain in september 2005. We are happy to announce the next edition in the workshop series. This year the event will be hosted in Karlsruhe, Germany from October 11th to 14th, 2007. For more information, please visit the official website of the workshop [1]. = Attendance = The attendance is free but requires an invitation. You may consider attending if you are involved in any aspect of the Netfilter development. Please, send us an email to coreteam@netfilter.org before July 7th, 2007 (strict deadline). We have a very limited number of invitations! = Call for Participants = Are you involved in any awesome third party Netfilter related project? If your answer is yes then you have a chance to come and show us your project during the workshop days. In case that you are interested, please send us a fast abstract before July 7th, 2007 (strict deadline) to coreteam@netfilter.org in latex, docbook or odt format. The abstract must have 1000 words maximum provinding an introduction, targets, solution proposed and experimental results if any. You must also provide the source code under a GPL-compatible free software license. The source code requirement is mandatory. The program committee will select two candidates from all applications received whose travel and accomodation expenses will be funded by our sponsors. Pablo, on behalf of the Netfilter core team [1] http://workshop.netfilter.org/2007/ -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Mon May 7 02:47:04 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon May 7 03:45:23 2007 Subject: [ANNOUNCE] Netfilter Workshop 2007 in Karlsruhe, Germany In-Reply-To: <463E753A.4060300@netfilter.org> References: <463E753A.4060300@netfilter.org> Message-ID: <463E7708.5020002@netfilter.org> Pablo Neira Ayuso wrote: > = Overview = > > Following the lastest successful workshop in Sevilla, Andalusia, Spain > in september 2005. We are happy to announce the next edition in the > workshop series. This year the event will be hosted in Karlsruhe, > Germany from October 11th to 14th, 2007. For more information, please > visit the official website of the workshop [1]. Wrong dates, sorry. I meant from september 11th to 14th, 2007. [1] http://workshop.netfilter.org/2007/ -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From yasuyuki.kozakai at toshiba.co.jp Mon May 7 04:59:38 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 06:00:26 2007 Subject: [PATCH 0/5]: kill unused stuff and fixes re-assigning helper Message-ID: <200705070259.l472xckY008224@toshiba.co.jp> Hi, They remove unused l3proto->destroy() and duplicated declarations, clear private area in 'struct nf_conn' for helper before reusing the area, and considers about unchanged helper when re-assigning helper. Patrick, please consider to apply them. -- Yasuyuki Kozakai From yasuyuki.kozakai at toshiba.co.jp Mon May 7 05:00:22 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 06:01:21 2007 Subject: [PATCH 1/5]: nf_nat: remove unused argument of function allocating binding Message-ID: <200705070300.l4730N38022064@toshiba.co.jp> nf_nat_rule_find, alloc_null_binding and alloc_null_binding_confirmed do not use the argument 'info', which is actually ct->nat.info. If they are necessary to access it again, we can use the argument 'ct' instead. Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_nat_rule.h | 11 +++-------- net/ipv4/netfilter/nf_nat_rule.c | 13 ++++--------- net/ipv4/netfilter/nf_nat_standalone.c | 11 +++-------- 3 files changed, 10 insertions(+), 25 deletions(-) diff --git a/include/net/netfilter/nf_nat_rule.h b/include/net/netfilter/nf_nat_rule.h index e765654..f974318 100644 --- a/include/net/netfilter/nf_nat_rule.h +++ b/include/net/netfilter/nf_nat_rule.h @@ -10,16 +10,11 @@ extern int nf_nat_rule_find(struct sk_bu unsigned int hooknum, const struct net_device *in, const struct net_device *out, - struct nf_conn *ct, - struct nf_nat_info *info); + struct nf_conn *ct); extern unsigned int -alloc_null_binding(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum); +alloc_null_binding(struct nf_conn *ct, unsigned int hooknum); extern unsigned int -alloc_null_binding_confirmed(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum); +alloc_null_binding_confirmed(struct nf_conn *ct, unsigned int hooknum); #endif /* _NF_NAT_RULE_H */ diff --git a/net/ipv4/netfilter/nf_nat_rule.c b/net/ipv4/netfilter/nf_nat_rule.c index 2a28339..36552f6 100644 --- a/net/ipv4/netfilter/nf_nat_rule.c +++ b/net/ipv4/netfilter/nf_nat_rule.c @@ -234,9 +234,7 @@ static int ipt_dnat_checkentry(const cha } inline unsigned int -alloc_null_binding(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum) +alloc_null_binding(struct nf_conn *ct, unsigned int hooknum) { /* Force range to this IP; let proto decide mapping for per-proto parts (hence not IP_NAT_RANGE_PROTO_SPECIFIED). @@ -255,9 +253,7 @@ alloc_null_binding(struct nf_conn *ct, } unsigned int -alloc_null_binding_confirmed(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum) +alloc_null_binding_confirmed(struct nf_conn *ct, unsigned int hooknum) { __be32 ip = (HOOK2MANIP(hooknum) == IP_NAT_MANIP_SRC @@ -279,8 +275,7 @@ int nf_nat_rule_find(struct sk_buff **ps unsigned int hooknum, const struct net_device *in, const struct net_device *out, - struct nf_conn *ct, - struct nf_nat_info *info) + struct nf_conn *ct) { int ret; @@ -289,7 +284,7 @@ int nf_nat_rule_find(struct sk_buff **ps if (ret == NF_ACCEPT) { if (!nf_nat_initialized(ct, HOOK2MANIP(hooknum))) /* NUL mapping */ - ret = alloc_null_binding(ct, info, hooknum); + ret = alloc_null_binding(ct, hooknum); } return ret; } diff --git a/net/ipv4/netfilter/nf_nat_standalone.c b/net/ipv4/netfilter/nf_nat_standalone.c index 64bbed2..55dac36 100644 --- a/net/ipv4/netfilter/nf_nat_standalone.c +++ b/net/ipv4/netfilter/nf_nat_standalone.c @@ -80,7 +80,6 @@ nf_nat_fn(unsigned int hooknum, struct nf_conn *ct; enum ip_conntrack_info ctinfo; struct nf_conn_nat *nat; - struct nf_nat_info *info; /* maniptype == SRC for postrouting. */ enum nf_nat_manip_type maniptype = HOOK2MANIP(hooknum); @@ -129,7 +128,6 @@ nf_nat_fn(unsigned int hooknum, } /* Fall thru... (Only ICMPs can be IP_CT_IS_REPLY) */ case IP_CT_NEW: - info = &nat->info; /* Seen it before? This can happen for loopback, retrans, or local packets.. */ @@ -138,14 +136,13 @@ nf_nat_fn(unsigned int hooknum, if (unlikely(nf_ct_is_confirmed(ct))) /* NAT module was loaded late */ - ret = alloc_null_binding_confirmed(ct, info, - hooknum); + ret = alloc_null_binding_confirmed(ct, hooknum); else if (hooknum == NF_IP_LOCAL_IN) /* LOCAL_IN hook doesn't have a chain! */ - ret = alloc_null_binding(ct, info, hooknum); + ret = alloc_null_binding(ct, hooknum); else ret = nf_nat_rule_find(pskb, hooknum, in, out, - ct, info); + ct); if (ret != NF_ACCEPT) { return ret; @@ -160,10 +157,8 @@ nf_nat_fn(unsigned int hooknum, /* ESTABLISHED */ NF_CT_ASSERT(ctinfo == IP_CT_ESTABLISHED || ctinfo == (IP_CT_ESTABLISHED+IP_CT_IS_REPLY)); - info = &nat->info; } - NF_CT_ASSERT(info); return nf_nat_packet(ct, ctinfo, hooknum, pskb); } -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 05:00:41 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 06:01:27 2007 Subject: [PATCH 2/5]: nf_conntrack: Removes duplicated declarations Message-ID: <200705070300.l4730fAv016222@toshiba.co.jp> These are also in include/net/netfilter/nf_conntrack_helper.h Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_conntrack.h | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index 1c6b8bd..4732432 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -183,13 +183,6 @@ extern void nf_conntrack_hash_insert(str extern void nf_conntrack_flush(void); -extern struct nf_conntrack_helper * -nf_ct_helper_find_get( const struct nf_conntrack_tuple *tuple); -extern void nf_ct_helper_put(struct nf_conntrack_helper *helper); - -extern struct nf_conntrack_helper * -__nf_conntrack_helper_find_byname(const char *name); - extern int nf_ct_invert_tuplepr(struct nf_conntrack_tuple *inverse, const struct nf_conntrack_tuple *orig); -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 05:01:03 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 06:01:42 2007 Subject: [PATCH 3/5]: nf_conntrack: Removes unused destroy operation of l3proto Message-ID: <200705070301.l47314D7010243@toshiba.co.jp> Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_conntrack_l3proto.h | 3 --- net/netfilter/nf_conntrack_core.c | 5 ----- 2 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/net/netfilter/nf_conntrack_l3proto.h b/include/net/netfilter/nf_conntrack_l3proto.h index f32f714..96a58d8 100644 --- a/include/net/netfilter/nf_conntrack_l3proto.h +++ b/include/net/netfilter/nf_conntrack_l3proto.h @@ -56,9 +56,6 @@ struct nf_conntrack_l3proto */ int (*new)(struct nf_conn *conntrack, const struct sk_buff *skb); - /* Called when a conntrack entry is destroyed */ - void (*destroy)(struct nf_conn *conntrack); - /* * Called before tracking. * *dataoff: offset of protocol header (TCP, UDP,...) in *pskb diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e132c8a..94000a4 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -299,7 +299,6 @@ destroy_conntrack(struct nf_conntrack *n { struct nf_conn *ct = (struct nf_conn *)nfct; struct nf_conn_help *help = nfct_help(ct); - struct nf_conntrack_l3proto *l3proto; struct nf_conntrack_l4proto *l4proto; typeof(nf_conntrack_destroyed) destroyed; @@ -317,10 +316,6 @@ destroy_conntrack(struct nf_conntrack *n * destroy_conntrack() MUST NOT be called with a write lock * to nf_conntrack_lock!!! -HW */ rcu_read_lock(); - l3proto = __nf_ct_l3proto_find(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.l3num); - if (l3proto && l3proto->destroy) - l3proto->destroy(ct); - l4proto = __nf_ct_l4proto_find(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.l3num, ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.protonum); if (l4proto && l4proto->destroy) -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 05:01:24 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 06:02:11 2007 Subject: [PATCH 4/5]: nfctnetlink: Clears helper area and handles unchanged helper Message-ID: <200705070301.l4731OEh017262@toshiba.co.jp> This patch - Clears private area for helper even if no helper is assigned to conntrack. It might be used by old helper. - Unchanges if the same helper as the used one is specified. - Does not find helper if no helper is specified. And it does not require private area for helper in that case. Signed-off-by: Yasuyuki Kozakai --- net/netfilter/nf_conntrack_netlink.c | 40 ++++++++++++++++++--------------- 1 files changed, 22 insertions(+), 18 deletions(-) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index aa1a97e..d6d39e2 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -830,11 +830,6 @@ ctnetlink_change_helper(struct nf_conn * char *helpname; int err; - if (!help) { - /* FIXME: we need to reallocate and rehash */ - return -EBUSY; - } - /* don't change helper of sibling connections */ if (ct->master) return -EINVAL; @@ -843,25 +838,34 @@ ctnetlink_change_helper(struct nf_conn * if (err < 0) return err; - helper = __nf_conntrack_helper_find_byname(helpname); - if (!helper) { - if (!strcmp(helpname, "")) - helper = NULL; - else - return -EINVAL; - } - - if (help->helper) { - if (!helper) { + if (!strcmp(helpname, "")) { + if (help && help->helper) { /* we had a helper before ... */ nf_ct_remove_expectations(ct); help->helper = NULL; - } else { - /* need to zero data of old helper */ - memset(&help->help, 0, sizeof(help->help)); } + + return 0; } + if (!help) { + /* FIXME: we need to reallocate and rehash */ + return -EBUSY; + } + + helper = __nf_conntrack_helper_find_byname(helpname); + if (helper == NULL) + return -EINVAL; + + if (help->helper == helper) + return 0; + + if (help->helper) + /* we had a helper before ... */ + nf_ct_remove_expectations(ct); + + /* need to zero data of old helper */ + memset(&help->help, 0, sizeof(help->help)); help->helper = helper; return 0; -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 05:01:35 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 06:02:15 2007 Subject: [PATCH 5/5]: nf_nat: Clears helper private area when NATing Message-ID: <200705070301.l4731ZdH017501@toshiba.co.jp> Some helpers (eg. ftp) assume that private area in conntrack is filled with zero. It should be cleared when helper is changed. Signed-off-by: Yasuyuki Kozakai --- net/netfilter/nf_conntrack_core.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 94000a4..e8b5c2d 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -888,8 +888,13 @@ void nf_conntrack_alter_reply(struct nf_ NF_CT_DUMP_TUPLE(newreply); ct->tuplehash[IP_CT_DIR_REPLY].tuple = *newreply; - if (!ct->master && help && help->expecting == 0) - help->helper = __nf_ct_helper_find(newreply); + if (!ct->master && help && help->expecting == 0) { + struct nf_conntrack_helper *helper; + helper = __nf_ct_helper_find(newreply); + if (helper) + memset(&help->help, 0, sizeof(help->help)); + help->helper = helper; + } write_unlock_bh(&nf_conntrack_lock); } EXPORT_SYMBOL_GPL(nf_conntrack_alter_reply); -- 1.4.4 From frozenspot at gmail.com Mon May 7 12:45:15 2007 From: frozenspot at gmail.com (fender) Date: Mon May 7 13:45:50 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <463DF61F.50509@netfilter.org> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> Message-ID: <7e36c7130705070345o776b5c61l285cc562d4840ebf@mail.gmail.com> On 5/6/07, Pablo Neira Ayuso wrote: > fender wrote: > > On 5/4/07, Patrick McHardy wrote: > >> Nothing, just set up the repository and send me the link. > > > > I'm sorry, I don't know what link of these will be the necessary: > > > > 1) http://portknocko.berlios.de/ ---> (project home page) > > > > 2) http://developer.berlios.de/project/showfiles.php?group_id=7093 ---> > > (.tar.gz files to download) > > > > 3) http://svn.berlios.de/svnroot/repos/portknocko/trunk > > No, Patrick means a link to your repository in pom-ng format. So > everybody can get external patchlets via ./runme --download. > > 1) Create a tarball with your project in pom-ng format [1]. > 2) Create a file called "index" that contains the name of your extension > in the same directory where you have put the tarball > 3) Send us the URL to add it to our sources.list file. > > [1] http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/ Ok, thanks Pablo for your explanation. I will generate the tarball in pom-ng format and I will send it to you as soon as possible. Regards, -- J. Federico Hernandez From kslee109 at gmail.com Mon May 7 13:32:55 2007 From: kslee109 at gmail.com (=?UTF-8?B?7J206re87IiY?=) Date: Mon May 7 14:33:33 2007 Subject: I encounterd kernel panic when I modified ip_queue. Message-ID: Well. I would modify ip_queue that the packet could bypass when ip_queue was full. If ip_queue was full, then I set kernel timer and the packet could bypass during one seconds. But, I encountered kernel pacnic when called add_timer(). Is there anyone who tell me the reason why I encountered kernel panic? The below is added and modified source code. static void ipq_packet_bypass(struct ipq_queue_entry *b_entry) { ipq_issue_verdict(b_entry, NF_ACCEPT); } static void ipq_bypass_timeout(unsigned long ptr) { bypass_flag = 0; del_timer_sync(&bypass_timer); /* delete bypass_timer */ } static void ipq_bypass_add_timer(){ init_timer(&bypass_timer); /* init the timer structure */ bypass_timer.expires = jiffies + HZ; /* one second */ bypass_timer.data = 1; bypass_timer.function = ipq_bypass_timeout; /* put timer call function */ add_timer(&bypass_timer); } static int ipq_enqueue_packet(struct sk_buff *skb, struct nf_info *info, void *data) { int status = -EINVAL; struct sk_buff *nskb; struct ipq_queue_entry *entry; if (copy_mode == IPQ_COPY_NONE) return -EAGAIN; entry = kmalloc(sizeof(*entry), GFP_ATOMIC); if (entry == NULL) { printk(KERN_ERR "Safezone queue: OOM in ipq_enqueue_packet()\n"); return -ENOMEM; } entry->info = info; entry->skb = skb; if (entry->info->hook == NF_IP_LOCAL_OUT) { struct iphdr *iph = skb->nh.iph; entry->rt_info.tos = iph->tos; entry->rt_info.daddr = iph->daddr; entry->rt_info.saddr = iph->saddr; } nskb = ipq_build_packet_message(entry, &status); if (nskb == NULL) goto err_out_free; write_lock_bh(&queue_lock); if(bypass_flag) { ipq_packet_bypass(entry); goto err_out_free_nskb; } if (!peer_pid) goto err_out_free_nskb; if (queue_total >= queue_maxlen) { queue_dropped++; status = -ENOSPC; if (net_ratelimit()) printk (KERN_WARNING "ip queue : full at %d entries, " "the packets are %s mode during 1 seconds. \n", queue_total, "BYPASS"); ip_queueu_full_alert(nskb); bypass_flag = 1; ipq_bypass_add_timer(); goto err_out_free_skb_bypass; } /* netlink_unicast will either free the nskb or attach it to a socket */ status = netlink_unicast(ipqnl, nskb, peer_pid, MSG_DONTWAIT); if (status < 0) { queue_user_dropped++; goto err_out_unlock; } __ipq_enqueue_entry(entry); write_unlock_bh(&queue_lock); return status; err_out_free_skb_bypass: ipq_packet_bypass(entry); write_unlock_bh(&queue_lock); return 0; err_out_free_nskb: kfree_skb(nskb); err_out_unlock: write_unlock_bh(&queue_lock); err_out_free: kfree(entry); return status; } ------------------------------------------------------------- Kun-soo Lee kslee109@gmail.com ------------------------------------------------------------- From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:00:29 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:01:14 2007 Subject: [RFC][PATCH 0/7]: ct_extend Message-ID: <200705071200.l47C0UoM006287@toshiba.co.jp> Hi all, I'm re-writing ct_extend patchset. This patchset is a snapshot. Like Rusty's original one, it allocates memory area by kmem_cache_alloc() to store basic informations about a connection, but it uses kmalloc() to allocate memory area for extension (currently helper and NAT). Some concepts are following. - 'struct ct_extend' keeps offsets to each area and the total size of them, instead of identifiers of extensions. This scheme can eliminate loops and make codes simple, but limits the total size of area to 256 bytes. Is it too small ? If so, we can be back to the original ct_extend. - To add a new area, it reallocates ct_extend. To fix the pointer to it from other objects, the 'move' operation defined by extension is used. - It does not have the operation to remove a memory area from ct_extend. Because it causes reallocating and restructuring ct_extend. It is complicated operation. And removing extension from all conntracks would require heavy processing. I prefer to leave unused area. - I added 'destroy' operation which is called in destroy_conntrack(). It can kill global operation 'nf_conntrack_destroyed' used by NAT. The issues I noticed are following. - This patchset does not consider locking. The places calling nfct_help() or nfct_nat() must be protected with new read-write lock. It will add some processing time and complexities. - ct_extend_add() reallocates memory area for all extensions. All helpers and NAT codes are necessary to take care that the pointer nfct_help(ct) and nfct_nat(ct) might be changed. It would make difficult to find bugs caused by this issue. And some improvements can be considered/are necessary. - Introducing new locking - 'move' operation might be better to have a argument 'struct nf_conn *ct'. - Moving other stuff in 'struct nf_conn' to ct_extend - Spliting nf_conn_nat into helper parts and others - Fixes of function names (nf_ct_ext_, nfct_ext_, nf_cte_, or ?) Comments are welcome. -- Yasuyuki Kozakai From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:00:50 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:01:40 2007 Subject: [PATCH 1/7]: nf_conntrack: Introduces a extension infrastructure Message-ID: <200705071200.l47C0p6J016120@toshiba.co.jp> Old space allocator of conntrack had problems about extensibility. - It required slab cache per combination of extensions. - It expected what extensions would be assigned, but it was impossible to expect that completely, then we allocated bigger memory object than really required. - It needed to search helper twice due to lock issue. Now basic informations of a connection are stored in 'struct nf_conn'. And a storage for extension (helper, NAT) is allocated by kmalloc. Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_conntrack.h | 4 + include/net/netfilter/nf_conntrack_extend.h | 72 +++++++++++++ net/netfilter/Makefile | 2 +- net/netfilter/nf_conntrack_core.c | 4 + net/netfilter/nf_conntrack_extend.c | 148 +++++++++++++++++++++++++++ 5 files changed, 229 insertions(+), 1 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index 4732432..fdab317 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -22,6 +22,7 @@ #include #include #include +#include #include #include @@ -131,6 +132,9 @@ struct nf_conn /* Storage reserved for other modules: */ union nf_conntrack_proto proto; + /* Extensions */ + struct ct_extend *ext; + /* features dynamically at the end: helper, nat (both optional) */ char data[0]; }; diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h new file mode 100644 index 0000000..1bfc87c --- /dev/null +++ b/include/net/netfilter/nf_conntrack_extend.h @@ -0,0 +1,72 @@ +#ifndef _NF_CONNTRACK_EXTEND_H +#define _NF_CONNTRACK_EXTEND_H + +enum ct_ext_type +{ + CTE_HELPER, + CTE_MAX, +} __attribute__((packed)); + +#define CTE_HELPER_TYPE struct nf_conn_help + +/* Extensions: optional stuff which isn't permanently in struct. */ +struct ct_extend { + u8 offset[CTE_MAX]; + u8 len; + char data[0]; +}; + +static inline int cte_exist(const struct ct_extend *ext, u8 type) +{ + return (ext->offset[type] != 0); +} + +static inline void *__ct_extend_find(const struct ct_extend *ext, u8 type) +{ + if (ext == NULL || !cte_exist(ext, type)) + return NULL; + + return (void *)ext + ext->offset[type]; +} +#define ct_extend_find(ext, type) ((type##_TYPE *)__ct_extend_find(ext, type)) + +/* Destroy all relationships */ +extern void __ct_extend_destroy(struct ct_extend *ext); +static inline void ct_extend_destroy(struct ct_extend *ext) +{ + if (ext) + __ct_extend_destroy(ext); +} + +/* Free operation. If you want to free a object referred from private area, + * please implement __ct_extend_free() and call it. + */ +static inline void ct_extend_free(struct ct_extend *ext) +{ + if (ext) + kfree(ext); +} + +/* Add this type, returns pointer to data or NULL. */ +void *__ct_extend_add(struct ct_extend **ext, enum ct_ext_type type, int gfp); +#define ct_extend_add(ext, type, gfp) \ + ((type##_TYPE *)__ct_extend_add(ext, type, gfp)) + +struct ct_extend_type +{ + /* Length and min alignment. */ + u8 len; + u8 align; + + /* Destroys relationships (can be NULL). */ + void (*destroy)(struct ct_extend *ext); + /* Called when realloacted (can be NULL). + Contents has already been moved. */ + void (*move)(struct ct_extend *new, struct ct_extend *old); + + enum ct_ext_type type; +}; + +int ct_extend_type_register(struct ct_extend_type *); +void ct_extend_type_unregister(struct ct_extend_type *); +#endif /* _NF_CONNTRACK_EXTEND_H */ diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile index b2b5c75..17b1d2c 100644 --- a/net/netfilter/Makefile +++ b/net/netfilter/Makefile @@ -1,6 +1,6 @@ netfilter-objs := core.o nf_log.o nf_queue.o nf_sockopt.o -nf_conntrack-y := nf_conntrack_core.o nf_conntrack_standalone.o nf_conntrack_expect.o nf_conntrack_helper.o nf_conntrack_proto.o nf_conntrack_l3proto_generic.o nf_conntrack_proto_generic.o nf_conntrack_proto_tcp.o nf_conntrack_proto_udp.o +nf_conntrack-y := nf_conntrack_core.o nf_conntrack_standalone.o nf_conntrack_expect.o nf_conntrack_helper.o nf_conntrack_proto.o nf_conntrack_l3proto_generic.o nf_conntrack_proto_generic.o nf_conntrack_proto_tcp.o nf_conntrack_proto_udp.o nf_conntrack_extend.o nf_conntrack-$(CONFIG_NF_CONNTRACK_EVENTS) += nf_conntrack_ecache.o obj-$(CONFIG_NETFILTER) = netfilter.o diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e8b5c2d..919ef2c 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -36,6 +36,7 @@ #include #include #include +#include #define NF_CONNTRACK_VERSION "0.5.0" @@ -321,6 +322,8 @@ destroy_conntrack(struct nf_conntrack *n if (l4proto && l4proto->destroy) l4proto->destroy(ct); + ct_extend_destroy(ct->ext); + destroyed = rcu_dereference(nf_conntrack_destroyed); if (destroyed) destroyed(ct); @@ -644,6 +647,7 @@ void nf_conntrack_free(struct nf_conn *c { u_int32_t features = conntrack->features; NF_CT_ASSERT(features >= NF_CT_F_BASIC && features < NF_CT_F_NUM); + ct_extend_free(conntrack->ext); DEBUGP("nf_conntrack_free: features = 0x%x, conntrack=%p\n", features, conntrack); kmem_cache_free(nf_ct_cache[features].cachep, conntrack); diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c new file mode 100644 index 0000000..209cd7a --- /dev/null +++ b/net/netfilter/nf_conntrack_extend.c @@ -0,0 +1,148 @@ +/* Structure dynamic extension infrastructure + * Copyright (C) 2004 Rusty Russell IBM Corporation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ +#include +#include +#include +#include +#include +#include + +static struct ct_extend_type *cte_types[CTE_MAX]; +static DEFINE_MUTEX(cte_type_mutex); + +/* Horrible trick to figure out smallest amount worth kmallocing. */ +#define CACHE(x) (x) + 0 * +enum { + CT_EXTEND_MIN_SIZE = +#include + 1 }; +#undef CACHE + +void __ct_extend_destroy(struct ct_extend *ext) +{ + unsigned int i; + struct ct_extend_type *t; + + for (i = 0; i < CTE_MAX; i++) { + if (!cte_exist(ext, i)) + continue; + + rcu_read_lock(); + t = rcu_dereference(cte_types[i]); + + /* Here the ct_extend_type might have been unregisterd. + * I.e., it has responsible to cleanup private + * area in all conntracks when it is unregisterd. + */ + if (t && t->destroy) + t->destroy(ext); + rcu_read_unlock(); + } +} +EXPORT_SYMBOL(__ct_extend_destroy); + +static void *cte_create(struct ct_extend **ext, enum ct_ext_type type, int gfp) +{ + unsigned int off, len; + struct ct_extend_type *t; + + rcu_read_lock(); + t = rcu_dereference(cte_types[type]); + BUG_ON(t == NULL); + off = ALIGN(sizeof(struct ct_extend), t->align); + len = off + t->len; + rcu_read_unlock(); + + *ext = kmalloc(max_t(unsigned int, CT_EXTEND_MIN_SIZE, len), gfp); + if (!*ext) + return NULL; + + memset(*ext, 0, len); + + (*ext)->offset[type] = off; + /* not real allocated size, but required size */ + (*ext)->len = len; + + return (void *)(*ext) + off; +} + +void *__ct_extend_add(struct ct_extend **ext, enum ct_ext_type type, int gfp) +{ + struct ct_extend *new; + int i, newlen, newoff; + struct ct_extend_type *t; + + if (!*ext) + return cte_create(ext, type, gfp); + + if (cte_exist((*ext), type)) + return NULL; + + rcu_read_lock(); + t = rcu_dereference(cte_types[type]); + BUG_ON(t == NULL); + + newoff = ALIGN((*ext)->len, t->align); + newlen = newoff + t->len; + rcu_read_unlock(); + + if (newlen >= CT_EXTEND_MIN_SIZE) { + new = kmalloc(newlen, gfp); + if (!new) + return NULL; + + memcpy(new, (*ext), (*ext)->len); + + for (i = 0; i < CTE_MAX; i++) { + if (!cte_exist((*ext), i)) + continue; + + rcu_read_lock(); + t = rcu_dereference(cte_types[i]); + if (t && t->move) + t->move(new, *ext); + rcu_read_unlock(); + } + kfree(*ext); + *ext = new; + } + + (*ext)->offset[type] = newoff; + (*ext)->len = newlen; + memset((void *)(*ext) + newoff, 0, newlen - newoff); + return (void *)(*ext) + newoff; +} +EXPORT_SYMBOL(__ct_extend_add); + +/* This MUST be called in process context. */ +int ct_extend_type_register(struct ct_extend_type *ext) +{ + int ret = 0; + + mutex_lock(&cte_type_mutex); + if (cte_types[ext->type]) { + ret = -EBUSY; + goto out; + } + + rcu_assign_pointer(cte_types[ext->type], ext); +out: + mutex_unlock(&cte_type_mutex); + return ret; +} +EXPORT_SYMBOL_GPL(ct_extend_type_register); + +/* This MUST be called in process context. */ +void ct_extend_type_unregister(struct ct_extend_type *ext) +{ + mutex_lock(&cte_type_mutex); + rcu_assign_pointer(cte_types[ext->type], NULL); + mutex_unlock(&cte_type_mutex); +} +EXPORT_SYMBOL_GPL(ct_extend_type_unregister); -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:01:00 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:02:02 2007 Subject: [PATCH 2/7]: nf_conntrack: Use extension infrastructure for helper Message-ID: <200705071201.l47C110u006659@toshiba.co.jp> Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_conntrack.h | 24 +-------- include/net/netfilter/nf_conntrack_core.h | 3 + net/ipv4/netfilter/nf_nat_standalone.c | 10 ---- net/netfilter/nf_conntrack_core.c | 80 +++++++++++++++++++---------- net/netfilter/nf_conntrack_helper.c | 27 ++++++---- net/netfilter/nf_conntrack_netlink.c | 44 ++++++++++------ 6 files changed, 101 insertions(+), 87 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index fdab317..5c43caf 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -294,32 +294,12 @@ static inline struct nf_conn_nat *nfct_n offset = ALIGN(offset, __alignof__(struct nf_conn_nat)); return (struct nf_conn_nat *) ((void *)ct + offset); } +#endif /* CONFIG_NF_NAT_NEEDED */ static inline struct nf_conn_help *nfct_help(const struct nf_conn *ct) { - unsigned int offset = sizeof(struct nf_conn); - - if (!(ct->features & NF_CT_F_HELP)) - return NULL; - if (ct->features & NF_CT_F_NAT) { - offset = ALIGN(offset, __alignof__(struct nf_conn_nat)); - offset += sizeof(struct nf_conn_nat); - } - - offset = ALIGN(offset, __alignof__(struct nf_conn_help)); - return (struct nf_conn_help *) ((void *)ct + offset); + return ct_extend_find(ct->ext, CTE_HELPER); } -#else /* No NAT */ -static inline struct nf_conn_help *nfct_help(const struct nf_conn *ct) -{ - unsigned int offset = sizeof(struct nf_conn); - - if (!(ct->features & NF_CT_F_HELP)) - return NULL; - offset = ALIGN(offset, __alignof__(struct nf_conn_help)); - return (struct nf_conn_help *) ((void *)ct + offset); -} -#endif /* CONFIG_NF_NAT_NEEDED */ #endif /* __KERNEL__ */ #endif /* _NF_CONNTRACK_H */ diff --git a/include/net/netfilter/nf_conntrack_core.h b/include/net/netfilter/nf_conntrack_core.h index 9fb9066..3bf7d05 100644 --- a/include/net/netfilter/nf_conntrack_core.h +++ b/include/net/netfilter/nf_conntrack_core.h @@ -30,6 +30,9 @@ extern void nf_conntrack_cleanup(void); extern int nf_conntrack_proto_init(void); extern void nf_conntrack_proto_fini(void); +extern int nf_conntrack_helper_init(void); +extern void nf_conntrack_helper_fini(void); + struct nf_conntrack_l3proto; extern struct nf_conntrack_l3proto *nf_ct_find_l3proto(u_int16_t pf); /* Like above, but you already have conntrack read lock. */ diff --git a/net/ipv4/netfilter/nf_nat_standalone.c b/net/ipv4/netfilter/nf_nat_standalone.c index 55dac36..0b2f0c3 100644 --- a/net/ipv4/netfilter/nf_nat_standalone.c +++ b/net/ipv4/netfilter/nf_nat_standalone.c @@ -338,14 +338,6 @@ static int __init nf_nat_standalone_init return ret; } - size = ALIGN(size, __alignof__(struct nf_conn_help)) + - sizeof(struct nf_conn_help); - ret = nf_conntrack_register_cache(NF_CT_F_NAT|NF_CT_F_HELP, - "nf_nat:help", size); - if (ret < 0) { - printk(KERN_ERR "nf_nat_init: Unable to create slab cache\n"); - goto cleanup_register_cache; - } #ifdef CONFIG_XFRM BUG_ON(ip_nat_decode_session != NULL); ip_nat_decode_session = nat_decode_session; @@ -370,8 +362,6 @@ static int __init nf_nat_standalone_init ip_nat_decode_session = NULL; synchronize_net(); #endif - nf_conntrack_unregister_cache(NF_CT_F_NAT|NF_CT_F_HELP); - cleanup_register_cache: nf_conntrack_unregister_cache(NF_CT_F_NAT); return ret; } diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 919ef2c..8b37797 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -560,7 +560,6 @@ __nf_conntrack_alloc(const struct nf_con u_int32_t features) { struct nf_conn *conntrack = NULL; - struct nf_conntrack_helper *helper; if (unlikely(!nf_conntrack_hash_rnd_initted)) { get_random_bytes(&nf_conntrack_hash_rnd, 4); @@ -587,14 +586,6 @@ __nf_conntrack_alloc(const struct nf_con /* find features needed by this conntrack. */ features |= l3proto->get_features(orig); - /* FIXME: protect helper list per RCU */ - read_lock_bh(&nf_conntrack_lock); - helper = __nf_ct_helper_find(repl); - /* NAT might want to assign a helper later */ - if (helper || features & NF_CT_F_NAT) - features |= NF_CT_F_HELP; - read_unlock_bh(&nf_conntrack_lock); - DEBUGP("nf_conntrack_alloc: features=0x%x\n", features); read_lock_bh(&nf_ct_cache_lock); @@ -674,12 +665,6 @@ init_conntrack(const struct nf_conntrack return NULL; } - read_lock_bh(&nf_conntrack_lock); - exp = __nf_conntrack_expect_find(tuple); - if (exp && exp->helper) - features = NF_CT_F_HELP; - read_unlock_bh(&nf_conntrack_lock); - conntrack = __nf_conntrack_alloc(tuple, &repl_tuple, l3proto, features); if (conntrack == NULL || IS_ERR(conntrack)) { DEBUGP("Can't allocate conntrack.\n"); @@ -694,15 +679,23 @@ init_conntrack(const struct nf_conntrack write_lock_bh(&nf_conntrack_lock); exp = find_expectation(tuple); - if (exp) { DEBUGP("conntrack: expectation arrives ct=%p exp=%p\n", conntrack, exp); /* Welcome, Mr. Bond. We've been expecting you... */ __set_bit(IPS_EXPECTED_BIT, &conntrack->status); conntrack->master = exp->master; - if (exp->helper) - nfct_help(conntrack)->helper = exp->helper; + if (exp->helper) { + struct nf_conn_help *help; + + help = ct_extend_add(&conntrack->ext, CTE_HELPER, + GFP_ATOMIC); + if (likely(help)) + help->helper = exp->helper; + else + DEBUGP("failed to add helper extension area"); + } + #ifdef CONFIG_NF_CONNTRACK_MARK conntrack->mark = exp->master->mark; #endif @@ -712,10 +705,18 @@ init_conntrack(const struct nf_conntrack nf_conntrack_get(&conntrack->master->ct_general); NF_CT_STAT_INC(expect_new); } else { - struct nf_conn_help *help = nfct_help(conntrack); - - if (help) - help->helper = __nf_ct_helper_find(&repl_tuple); + struct nf_conntrack_helper *helper; + struct nf_conn_help *help; + + helper = __nf_ct_helper_find(&repl_tuple); + if (helper) { + help = ct_extend_add(&conntrack->ext, CTE_HELPER, + GFP_ATOMIC); + if (likely(help)) + help->helper = helper; + else + DEBUGP("failed to add helper extension area"); + } NF_CT_STAT_INC(new); } @@ -883,6 +884,7 @@ void nf_conntrack_alter_reply(struct nf_ const struct nf_conntrack_tuple *newreply) { struct nf_conn_help *help = nfct_help(ct); + struct nf_conntrack_helper *helper; write_lock_bh(&nf_conntrack_lock); /* Should be unconfirmed, so not in hash table yet */ @@ -892,13 +894,28 @@ void nf_conntrack_alter_reply(struct nf_ NF_CT_DUMP_TUPLE(newreply); ct->tuplehash[IP_CT_DIR_REPLY].tuple = *newreply; - if (!ct->master && help && help->expecting == 0) { - struct nf_conntrack_helper *helper; - helper = __nf_ct_helper_find(newreply); - if (helper) - memset(&help->help, 0, sizeof(help->help)); - help->helper = helper; + if (ct->master || (help && help->expecting != 0)) + goto out; + + helper = __nf_ct_helper_find(newreply); + if (helper == NULL) { + if (help) + help->helper = NULL; + goto out; } + + if (help == NULL) { + help = ct_extend_add(&ct->ext, CTE_HELPER, GFP_ATOMIC); + if (unlikely(help == NULL)) { + DEBUGP("failed to add helper extension area"); + goto out; + } + } else { + memset(&help->help, 0, sizeof(help->help)); + } + + help->helper = helper; +out: write_unlock_bh(&nf_conntrack_lock); } EXPORT_SYMBOL_GPL(nf_conntrack_alter_reply); @@ -1140,6 +1157,7 @@ void nf_conntrack_cleanup(void) nf_conntrack_htable_size); nf_conntrack_proto_fini(); + nf_conntrack_helper_fini(); } static struct list_head *alloc_hashtable(int size, int *vmalloced) @@ -1262,6 +1280,10 @@ int __init nf_conntrack_init(void) if (ret < 0) goto out_free_expect_slab; + ret = nf_conntrack_helper_init(); + if (ret < 0) + goto out_fini_proto; + /* For use by REJECT target */ rcu_assign_pointer(ip_ct_attach, __nf_conntrack_attach); rcu_assign_pointer(nf_ct_destroy, destroy_conntrack); @@ -1274,6 +1296,8 @@ int __init nf_conntrack_init(void) return ret; +out_fini_proto: + nf_conntrack_proto_fini(); out_free_expect_slab: kmem_cache_destroy(nf_conntrack_expect_cachep); err_free_conntrack_slab: diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c index 0743be4..d8a9349 100644 --- a/net/netfilter/nf_conntrack_helper.c +++ b/net/netfilter/nf_conntrack_helper.c @@ -26,6 +26,7 @@ #include #include #include +#include static __read_mostly LIST_HEAD(helpers); @@ -100,18 +101,8 @@ static inline int unhelp(struct nf_connt int nf_conntrack_helper_register(struct nf_conntrack_helper *me) { - int size, ret; - BUG_ON(me->timeout == 0); - size = ALIGN(sizeof(struct nf_conn), __alignof__(struct nf_conn_help)) + - sizeof(struct nf_conn_help); - ret = nf_conntrack_register_cache(NF_CT_F_HELP, "nf_conntrack:help", - size); - if (ret < 0) { - printk(KERN_ERR "nf_conntrack_helper_register: Unable to create slab cache for conntracks\n"); - return ret; - } write_lock_bh(&nf_conntrack_lock); list_add(&me->list, &helpers); write_unlock_bh(&nf_conntrack_lock); @@ -153,3 +144,19 @@ void nf_conntrack_helper_unregister(stru synchronize_net(); } EXPORT_SYMBOL_GPL(nf_conntrack_helper_unregister); + +struct ct_extend_type helper_extend = { + .len = sizeof(struct nf_conn_help), + .align = __alignof__(struct nf_conn_help), + .type = CTE_HELPER, +}; + +int nf_conntrack_helper_init() +{ + return ct_extend_type_register(&helper_extend); +} + +void nf_conntrack_helper_fini() +{ + ct_extend_type_unregister(&helper_extend); +} diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index d6d39e2..ddb6a31 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -848,24 +848,26 @@ ctnetlink_change_helper(struct nf_conn * return 0; } - if (!help) { - /* FIXME: we need to reallocate and rehash */ - return -EBUSY; - } - helper = __nf_conntrack_helper_find_byname(helpname); if (helper == NULL) return -EINVAL; - if (help->helper == helper) - return 0; + if (help) { + if (help->helper == helper) + return 0; - if (help->helper) - /* we had a helper before ... */ - nf_ct_remove_expectations(ct); + if (help->helper) + /* we had a helper before ... */ + nf_ct_remove_expectations(ct); + + /* need to zero data of old helper */ + memset(&help->help, 0, sizeof(help->help)); + } else { + help = ct_extend_add(&ct->ext, CTE_HELPER, GFP_KERNEL); + if (help == NULL) + return -ENOMEM; + } - /* need to zero data of old helper */ - memset(&help->help, 0, sizeof(help->help)); help->helper = helper; return 0; @@ -950,6 +952,7 @@ ctnetlink_create_conntrack(struct nfattr struct nf_conn *ct; int err = -EINVAL; struct nf_conn_help *help; + struct nf_conntrack_helper *helper; ct = nf_conntrack_alloc(otuple, rtuple); if (ct == NULL || IS_ERR(ct)) @@ -979,15 +982,22 @@ ctnetlink_create_conntrack(struct nfattr ct->mark = ntohl(*(__be32 *)NFA_DATA(cda[CTA_MARK-1])); #endif - help = nfct_help(ct); - if (help) - help->helper = nf_ct_helper_find_get(rtuple); + helper = nf_ct_helper_find_get(rtuple); + if (helper) { + help = ct_extend_add(&ct->ext, CTE_HELPER, GFP_KERNEL); + if (help == NULL) { + nf_ct_helper_put(helper); + err = -ENOMEM; + goto err; + } + help->helper = helper; + } add_timer(&ct->timeout); nf_conntrack_hash_insert(ct); - if (help && help->helper) - nf_ct_helper_put(help->helper); + if (helper) + nf_ct_helper_put(helper); return 0; -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:01:25 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:02:11 2007 Subject: [PATCH 3/7]: nf_nat: Adds reference to conntrack from entry of bysource list Message-ID: <200705071201.l47C1QiH006878@toshiba.co.jp> I will split 'struct nf_nat_info' out from conntrack. So I cannot use 'offsetof' to get the pointer to conntrack from it. Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_nat.h | 5 +++-- net/ipv4/netfilter/nf_nat_core.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/include/net/netfilter/nf_nat.h b/include/net/netfilter/nf_nat.h index bc57dd7..fd8707d 100644 --- a/include/net/netfilter/nf_nat.h +++ b/include/net/netfilter/nf_nat.h @@ -52,15 +52,16 @@ struct nf_nat_multi_range_compat #ifdef __KERNEL__ #include +struct nf_conn; + /* The structure embedded in the conntrack structure. */ struct nf_nat_info { struct list_head bysource; struct nf_nat_seq seq[IP_CT_DIR_MAX]; + struct nf_conn *ct; }; -struct nf_conn; - /* Set up the info structure to map into this range. */ extern unsigned int nf_nat_setup_info(struct nf_conn *ct, const struct nf_nat_range *range, diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c index ea02f00..ac7e8ab 100644 --- a/net/ipv4/netfilter/nf_nat_core.c +++ b/net/ipv4/netfilter/nf_nat_core.c @@ -97,6 +97,7 @@ static void nf_nat_cleanup_conntrack(str nat = nfct_nat(conn); write_lock_bh(&nf_nat_lock); list_del(&nat->info.bysource); + nat->info.ct = NULL; write_unlock_bh(&nf_nat_lock); } @@ -169,7 +170,7 @@ find_appropriate_src(const struct nf_con read_lock_bh(&nf_nat_lock); list_for_each_entry(nat, &bysource[h], info.bysource) { - ct = (struct nf_conn *)((char *)nat - offsetof(struct nf_conn, data)); + ct = nat->info.ct; if (same_src(ct, tuple)) { /* Copy source part from reply tuple. */ nf_ct_invert_tuplepr(result, @@ -337,6 +338,7 @@ nf_nat_setup_info(struct nf_conn *ct, srchash = hash_by_src(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); write_lock_bh(&nf_nat_lock); + info->ct = ct; list_add(&info->bysource, &bysource[srchash]); write_unlock_bh(&nf_nat_lock); } -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:01:36 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:02:24 2007 Subject: [PATCH 4/7]: nf_nat: Use extension infrastructure Message-ID: <200705071201.l47C1bUI016561@toshiba.co.jp> Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_conntrack.h | 8 +--- include/net/netfilter/nf_conntrack_extend.h | 2 + net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 3 - net/ipv4/netfilter/nf_nat_core.c | 60 ++++++++++++++++++++++-- net/ipv4/netfilter/nf_nat_standalone.c | 20 +++----- 5 files changed, 67 insertions(+), 26 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index 5c43caf..bd1af5c 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -286,13 +286,7 @@ nf_conntrack_unregister_cache(u_int32_t #ifdef CONFIG_NF_NAT_NEEDED static inline struct nf_conn_nat *nfct_nat(const struct nf_conn *ct) { - unsigned int offset = sizeof(struct nf_conn); - - if (!(ct->features & NF_CT_F_NAT)) - return NULL; - - offset = ALIGN(offset, __alignof__(struct nf_conn_nat)); - return (struct nf_conn_nat *) ((void *)ct + offset); + return ct_extend_find(ct->ext, CTE_NAT); } #endif /* CONFIG_NF_NAT_NEEDED */ diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h index 1bfc87c..a66bb7b 100644 --- a/include/net/netfilter/nf_conntrack_extend.h +++ b/include/net/netfilter/nf_conntrack_extend.h @@ -4,10 +4,12 @@ enum ct_ext_type { CTE_HELPER, + CTE_NAT, CTE_MAX, } __attribute__((packed)); #define CTE_HELPER_TYPE struct nf_conn_help +#define CTE_NAT_TYPE struct nf_conn_nat /* Extensions: optional stuff which isn't permanently in struct. */ struct ct_extend { diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c index 0654eaa..b5eb948 100644 --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c @@ -108,9 +108,6 @@ EXPORT_SYMBOL_GPL(nf_nat_module_is_loade static u_int32_t ipv4_get_features(const struct nf_conntrack_tuple *tuple) { - if (nf_nat_module_is_loaded) - return NF_CT_F_NAT; - return NF_CT_F_BASIC; } diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c index ac7e8ab..278c6d3 100644 --- a/net/ipv4/netfilter/nf_nat_core.c +++ b/net/ipv4/netfilter/nf_nat_core.c @@ -297,11 +297,22 @@ nf_nat_setup_info(struct nf_conn *ct, unsigned int hooknum) { struct nf_conntrack_tuple curr_tuple, new_tuple; - struct nf_conn_nat *nat = nfct_nat(ct); - struct nf_nat_info *info = &nat->info; + struct nf_conn_nat *nat; + struct nf_nat_info *info; int have_to_hash = !(ct->status & IPS_NAT_DONE_MASK); enum nf_nat_manip_type maniptype = HOOK2MANIP(hooknum); + /* nat helper or nfctnetlink also setup binding */ + nat = nfct_nat(ct); + if (!nat) { + nat = ct_extend_add(&ct->ext, CTE_NAT, GFP_ATOMIC); + if (unlikely(nat == NULL)) { + DEBUGP("failed to add NAT extension\n"); + return NF_ACCEPT; + } + } + info = &nat->info; + NF_CT_ASSERT(hooknum == NF_IP_PRE_ROUTING || hooknum == NF_IP_POST_ROUTING || hooknum == NF_IP_LOCAL_IN || @@ -592,17 +603,52 @@ nf_nat_port_nfattr_to_range(struct nfatt EXPORT_SYMBOL_GPL(nf_nat_port_range_to_nfattr); #endif +static void nf_nat_move_storage(struct ct_extend *new, struct ct_extend *old) +{ + struct nf_conn_nat *new_nat = ct_extend_find(new, CTE_NAT); + struct nf_conn_nat *old_nat = ct_extend_find(old, CTE_NAT); + struct nf_conn *ct = old_nat->info.ct; + unsigned int srchash; + + if (!ct || !(ct->status & IPS_NAT_DONE_MASK)) + return; + + srchash = hash_by_src(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); + + write_lock_bh(&nf_nat_lock); + list_del(&old_nat->info.bysource); + new_nat->info.ct = ct; + list_add(&new_nat->info.bysource, &bysource[srchash]); + write_unlock_bh(&nf_nat_lock); +} + +struct ct_extend_type nat_extend = { + .len = sizeof(struct nf_conn_nat), + .align = __alignof__(struct nf_conn_nat), + .move = nf_nat_move_storage, + .type = CTE_NAT, +}; + static int __init nf_nat_init(void) { size_t i; + int ret; + + ret = ct_extend_type_register(&nat_extend); + if (ret < 0) { + printk(KERN_ERR "nf_nat_core: Unable to register extension\n"); + return ret; + } /* Leave them the same for the moment. */ nf_nat_htable_size = nf_conntrack_htable_size; /* One vmalloc for both hash tables */ bysource = vmalloc(sizeof(struct list_head) * nf_nat_htable_size); - if (!bysource) - return -ENOMEM; + if (!bysource) { + ret = -ENOMEM; + goto cleanup_extend; + } /* Sew in builtin protocols. */ write_lock_bh(&nf_nat_lock); @@ -625,7 +671,12 @@ static int __init nf_nat_init(void) nf_conntrack_untracked.status |= IPS_NAT_DONE_MASK; l3proto = nf_ct_l3proto_find_get((u_int16_t)AF_INET); + return 0; + + cleanup_extend: + ct_extend_type_unregister(&nat_extend); + return ret; } /* Clear NAT section of all conntracks, in case we're loaded again. */ @@ -647,6 +698,7 @@ static void __exit nf_nat_cleanup(void) synchronize_rcu(); vfree(bysource); nf_ct_l3proto_put(l3proto); + ct_extend_type_unregister(&nat_extend); } MODULE_LICENSE("GPL"); diff --git a/net/ipv4/netfilter/nf_nat_standalone.c b/net/ipv4/netfilter/nf_nat_standalone.c index 0b2f0c3..88af64e 100644 --- a/net/ipv4/netfilter/nf_nat_standalone.c +++ b/net/ipv4/netfilter/nf_nat_standalone.c @@ -113,8 +113,13 @@ nf_nat_fn(unsigned int hooknum, return NF_ACCEPT; nat = nfct_nat(ct); - if (!nat) - return NF_ACCEPT; + if (!nat) { + nat = ct_extend_add(&ct->ext, CTE_NAT, GFP_ATOMIC); + if (unlikely(nat == NULL)) { + DEBUGP("failed to add NAT extension\n"); + return NF_ACCEPT; + } + } switch (ctinfo) { case IP_CT_RELATED: @@ -326,18 +331,10 @@ static struct nf_hook_ops nf_nat_ops[] = static int __init nf_nat_standalone_init(void) { - int size, ret = 0; + int ret = 0; need_conntrack(); - size = ALIGN(sizeof(struct nf_conn), __alignof__(struct nf_conn_nat)) + - sizeof(struct nf_conn_nat); - ret = nf_conntrack_register_cache(NF_CT_F_NAT, "nf_nat:base", size); - if (ret < 0) { - printk(KERN_ERR "nf_nat_init: Unable to create slab cache\n"); - return ret; - } - #ifdef CONFIG_XFRM BUG_ON(ip_nat_decode_session != NULL); ip_nat_decode_session = nat_decode_session; @@ -362,7 +359,6 @@ static int __init nf_nat_standalone_init ip_nat_decode_session = NULL; synchronize_net(); #endif - nf_conntrack_unregister_cache(NF_CT_F_NAT); return ret; } -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:01:48 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:02:30 2007 Subject: [PATCH 5/7]: nf_conntrack: Removes old memory allocator of conntrack Message-ID: <200705071201.l47C1nrG007063@toshiba.co.jp> Now memory space for help and NAT are allocated by extension infrastructure. Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_conntrack.h | 23 --- include/net/netfilter/nf_conntrack_l3proto.h | 2 - net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 6 - net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 6 - net/netfilter/nf_conntrack_core.c | 222 ++---------------------- net/netfilter/nf_conntrack_l3proto_generic.c | 7 - 6 files changed, 15 insertions(+), 251 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index bd1af5c..15408c2 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -118,9 +118,6 @@ struct nf_conn /* Unique ID that identifies this conntrack*/ unsigned int id; - /* features - nat, helper, ... used by allocating system */ - u_int32_t features; - #if defined(CONFIG_NF_CONNTRACK_MARK) u_int32_t mark; #endif @@ -134,9 +131,6 @@ struct nf_conn /* Extensions */ struct ct_extend *ext; - - /* features dynamically at the end: helper, nat (both optional) */ - char data[0]; }; static inline struct nf_conn * @@ -266,23 +260,6 @@ do { \ local_bh_enable(); \ } while (0) -/* no helper, no nat */ -#define NF_CT_F_BASIC 0 -/* for helper */ -#define NF_CT_F_HELP 1 -/* for nat. */ -#define NF_CT_F_NAT 2 -#define NF_CT_F_NUM 4 - -extern int -nf_conntrack_register_cache(u_int32_t features, const char *name, size_t size); -extern void -nf_conntrack_unregister_cache(u_int32_t features); - -/* valid combinations: - * basic: nf_conn, nf_conn .. nf_conn_help - * nat: nf_conn .. nf_conn_nat, nf_conn .. nf_conn_nat .. nf_conn help - */ #ifdef CONFIG_NF_NAT_NEEDED static inline struct nf_conn_nat *nfct_nat(const struct nf_conn *ct) { diff --git a/include/net/netfilter/nf_conntrack_l3proto.h b/include/net/netfilter/nf_conntrack_l3proto.h index 96a58d8..890752d 100644 --- a/include/net/netfilter/nf_conntrack_l3proto.h +++ b/include/net/netfilter/nf_conntrack_l3proto.h @@ -64,8 +64,6 @@ struct nf_conntrack_l3proto int (*prepare)(struct sk_buff **pskb, unsigned int hooknum, unsigned int *dataoff, u_int8_t *protonum); - u_int32_t (*get_features)(const struct nf_conntrack_tuple *tuple); - int (*tuple_to_nfattr)(struct sk_buff *skb, const struct nf_conntrack_tuple *t); diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c index b5eb948..cb6c61d 100644 --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c @@ -106,11 +106,6 @@ ipv4_prepare(struct sk_buff **pskb, unsi int nf_nat_module_is_loaded = 0; EXPORT_SYMBOL_GPL(nf_nat_module_is_loaded); -static u_int32_t ipv4_get_features(const struct nf_conntrack_tuple *tuple) -{ - return NF_CT_F_BASIC; -} - static unsigned int ipv4_confirm(unsigned int hooknum, struct sk_buff **pskb, const struct net_device *in, @@ -421,7 +416,6 @@ struct nf_conntrack_l3proto nf_conntrack .print_tuple = ipv4_print_tuple, .print_conntrack = ipv4_print_conntrack, .prepare = ipv4_prepare, - .get_features = ipv4_get_features, #if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE) .tuple_to_nfattr = ipv4_tuple_to_nfattr, .nfattr_to_tuple = ipv4_nfattr_to_tuple, diff --git a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c index 6d2a082..86a9016 100644 --- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c +++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c @@ -147,11 +147,6 @@ ipv6_prepare(struct sk_buff **pskb, unsi return NF_ACCEPT; } -static u_int32_t ipv6_get_features(const struct nf_conntrack_tuple *tuple) -{ - return NF_CT_F_BASIC; -} - static unsigned int ipv6_confirm(unsigned int hooknum, struct sk_buff **pskb, const struct net_device *in, @@ -393,7 +388,6 @@ struct nf_conntrack_l3proto nf_conntrack .ctl_table_path = nf_net_netfilter_sysctl_path, .ctl_table = nf_ct_ipv6_sysctl_table, #endif - .get_features = ipv6_get_features, .me = THIS_MODULE, }; diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 8b37797..99fc52f 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -71,39 +71,12 @@ EXPORT_SYMBOL_GPL(nf_conntrack_untracked unsigned int nf_ct_log_invalid __read_mostly; LIST_HEAD(unconfirmed); static int nf_conntrack_vmalloc __read_mostly; - +static struct kmem_cache *nf_conntrack_cachep __read_mostly; static unsigned int nf_conntrack_next_id; DEFINE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat); EXPORT_PER_CPU_SYMBOL(nf_conntrack_stat); -/* - * This scheme offers various size of "struct nf_conn" dependent on - * features(helper, nat, ...) - */ - -#define NF_CT_FEATURES_NAMELEN 256 -static struct { - /* name of slab cache. printed in /proc/slabinfo */ - char *name; - - /* size of slab cache */ - size_t size; - - /* slab cache pointer */ - struct kmem_cache *cachep; - - /* allocated slab cache + modules which uses this slab cache */ - int use; - -} nf_ct_cache[NF_CT_F_NUM]; - -/* 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); - static int nf_conntrack_hash_rnd_initted; static unsigned int nf_conntrack_hash_rnd; @@ -126,122 +99,6 @@ static inline u_int32_t hash_conntrack(c nf_conntrack_hash_rnd); } -int nf_conntrack_register_cache(u_int32_t features, const char *name, - size_t size) -{ - int ret = 0; - char *cache_name; - struct kmem_cache *cachep; - - DEBUGP("nf_conntrack_register_cache: features=0x%x, name=%s, size=%d\n", - features, name, size); - - if (features < NF_CT_F_BASIC || features >= NF_CT_F_NUM) { - DEBUGP("nf_conntrack_register_cache: invalid features.: 0x%x\n", - features); - 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. - */ - 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; - } - - if (strlcpy(cache_name, name, NF_CT_FEATURES_NAMELEN) - >= NF_CT_FEATURES_NAMELEN) { - printk("nf_conntrack_register_cache: name too long\n"); - ret = -EINVAL; - goto out_free_name; - } - - 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); - ret = -ENOMEM; - goto out_free_name; - } - - write_lock_bh(&nf_ct_cache_lock); - 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; - -out_free_name: - kfree(cache_name); -out_up_mutex: - mutex_unlock(&nf_ct_cache_mutex); - return ret; -} -EXPORT_SYMBOL_GPL(nf_conntrack_register_cache); - -/* FIXME: In the current, only nf_conntrack_cleanup() can call this function. */ -void nf_conntrack_unregister_cache(u_int32_t features) -{ - struct kmem_cache *cachep; - char *name; - - /* - * This assures that kmem_cache_create() isn't called before destroying - * 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; - name = nf_ct_cache[features].name; - nf_ct_cache[features].cachep = NULL; - nf_ct_cache[features].name = NULL; - nf_ct_cache[features].size = 0; - write_unlock_bh(&nf_ct_cache_lock); - - synchronize_net(); - - kmem_cache_destroy(cachep); - kfree(name); - - mutex_unlock(&nf_ct_cache_mutex); -} -EXPORT_SYMBOL_GPL(nf_conntrack_unregister_cache); - int nf_ct_get_tuple(const struct sk_buff *skb, unsigned int nhoff, @@ -553,11 +410,8 @@ static int early_drop(struct list_head * return dropped; } -static struct nf_conn * -__nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, - const struct nf_conntrack_tuple *repl, - const struct nf_conntrack_l3proto *l3proto, - u_int32_t features) +struct nf_conn *nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, + const struct nf_conntrack_tuple *repl) { struct nf_conn *conntrack = NULL; @@ -583,65 +437,28 @@ __nf_conntrack_alloc(const struct nf_con } } - /* find features needed by this conntrack. */ - features |= l3proto->get_features(orig); - - DEBUGP("nf_conntrack_alloc: features=0x%x\n", features); - - read_lock_bh(&nf_ct_cache_lock); - - if (unlikely(!nf_ct_cache[features].use)) { - DEBUGP("nf_conntrack_alloc: not supported features = 0x%x\n", - features); - goto out; - } - - conntrack = kmem_cache_alloc(nf_ct_cache[features].cachep, GFP_ATOMIC); + conntrack = kmem_cache_zalloc(nf_conntrack_cachep, GFP_ATOMIC); if (conntrack == NULL) { - DEBUGP("nf_conntrack_alloc: Can't alloc conntrack from cache\n"); - goto out; + DEBUGP("nf_conntrack_alloc: Can't alloc conntrack.\n"); + atomic_dec(&nf_conntrack_count); + return ERR_PTR(-ENOMEM); } - memset(conntrack, 0, nf_ct_cache[features].size); - conntrack->features = features; atomic_set(&conntrack->ct_general.use, 1); conntrack->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *orig; conntrack->tuplehash[IP_CT_DIR_REPLY].tuple = *repl; /* Don't set timer yet: wait for confirmation */ setup_timer(&conntrack->timeout, death_by_timeout, (unsigned long)conntrack); - read_unlock_bh(&nf_ct_cache_lock); return conntrack; -out: - read_unlock_bh(&nf_ct_cache_lock); - atomic_dec(&nf_conntrack_count); - return conntrack; -} - -struct nf_conn *nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, - const struct nf_conntrack_tuple *repl) -{ - struct nf_conntrack_l3proto *l3proto; - struct nf_conn *ct; - - rcu_read_lock(); - l3proto = __nf_ct_l3proto_find(orig->src.l3num); - ct = __nf_conntrack_alloc(orig, repl, l3proto, 0); - rcu_read_unlock(); - - return ct; } EXPORT_SYMBOL_GPL(nf_conntrack_alloc); void nf_conntrack_free(struct nf_conn *conntrack) { - u_int32_t features = conntrack->features; - NF_CT_ASSERT(features >= NF_CT_F_BASIC && features < NF_CT_F_NUM); ct_extend_free(conntrack->ext); - DEBUGP("nf_conntrack_free: features = 0x%x, conntrack=%p\n", features, - conntrack); - kmem_cache_free(nf_ct_cache[features].cachep, conntrack); + kmem_cache_free(nf_conntrack_cachep, conntrack); atomic_dec(&nf_conntrack_count); } EXPORT_SYMBOL_GPL(nf_conntrack_free); @@ -658,14 +475,13 @@ init_conntrack(const struct nf_conntrack struct nf_conn *conntrack; struct nf_conntrack_tuple repl_tuple; struct nf_conntrack_expect *exp; - u_int32_t features = 0; if (!nf_ct_invert_tuple(&repl_tuple, tuple, l3proto, l4proto)) { DEBUGP("Can't invert tuple.\n"); return NULL; } - conntrack = __nf_conntrack_alloc(tuple, &repl_tuple, l3proto, features); + conntrack = nf_conntrack_alloc(tuple, &repl_tuple); if (conntrack == NULL || IS_ERR(conntrack)) { DEBUGP("Can't allocate conntrack.\n"); return (struct nf_conntrack_tuple_hash *)conntrack; @@ -1122,8 +938,6 @@ EXPORT_SYMBOL_GPL(nf_conntrack_flush); supposed to kill the mall. */ void nf_conntrack_cleanup(void) { - int i; - rcu_assign_pointer(ip_ct_attach, NULL); /* This makes sure all current packets have passed through @@ -1144,14 +958,7 @@ void nf_conntrack_cleanup(void) rcu_assign_pointer(nf_ct_destroy, NULL); - for (i = 0; i < NF_CT_F_NUM; i++) { - if (nf_ct_cache[i].use == 0) - continue; - - NF_CT_ASSERT(nf_ct_cache[i].use == 1); - nf_ct_cache[i].use = 1; - nf_conntrack_unregister_cache(i); - } + kmem_cache_destroy(nf_conntrack_cachep); kmem_cache_destroy(nf_conntrack_expect_cachep); free_conntrack_hash(nf_conntrack_hash, nf_conntrack_vmalloc, nf_conntrack_htable_size); @@ -1261,9 +1068,10 @@ int __init nf_conntrack_init(void) goto err_out; } - ret = nf_conntrack_register_cache(NF_CT_F_BASIC, "nf_conntrack:basic", - sizeof(struct nf_conn)); - if (ret < 0) { + nf_conntrack_cachep = kmem_cache_create("nf_conntrack", + sizeof(struct nf_conn), + 0, 0, NULL, NULL); + if (!nf_conntrack_cachep) { printk(KERN_ERR "Unable to create nf_conn slab cache\n"); goto err_free_hash; } @@ -1301,7 +1109,7 @@ out_fini_proto: out_free_expect_slab: kmem_cache_destroy(nf_conntrack_expect_cachep); err_free_conntrack_slab: - nf_conntrack_unregister_cache(NF_CT_F_BASIC); + kmem_cache_destroy(nf_conntrack_cachep); err_free_hash: free_conntrack_hash(nf_conntrack_hash, nf_conntrack_vmalloc, nf_conntrack_htable_size); diff --git a/net/netfilter/nf_conntrack_l3proto_generic.c b/net/netfilter/nf_conntrack_l3proto_generic.c index cbd96f3..2fd0f11 100644 --- a/net/netfilter/nf_conntrack_l3proto_generic.c +++ b/net/netfilter/nf_conntrack_l3proto_generic.c @@ -76,12 +76,6 @@ generic_prepare(struct sk_buff **pskb, u } -static u_int32_t generic_get_features(const struct nf_conntrack_tuple *tuple) - -{ - return NF_CT_F_BASIC; -} - struct nf_conntrack_l3proto nf_conntrack_l3proto_generic = { .l3proto = PF_UNSPEC, .name = "unknown", @@ -90,6 +84,5 @@ struct nf_conntrack_l3proto nf_conntrack .print_tuple = generic_print_tuple, .print_conntrack = generic_print_conntrack, .prepare = generic_prepare, - .get_features = generic_get_features, }; EXPORT_SYMBOL_GPL(nf_conntrack_l3proto_generic); -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:01:59 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:02:46 2007 Subject: [PATCH 6/7]: nf_nat: Kills global 'destroy' operation Message-ID: <200705071202.l47C20ai007167@toshiba.co.jp> This kills the global 'destroy' operation which was used by NAT. Instead it uses the extension infrastructure so that multiple extensions can register own operations. Signed-off-by: Yasuyuki Kozakai --- include/net/netfilter/nf_conntrack.h | 3 -- net/ipv4/netfilter/nf_nat_core.c | 44 ++++++++++++++++----------------- net/netfilter/nf_conntrack_core.c | 8 ------ 3 files changed, 21 insertions(+), 34 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index 15408c2..43d1923 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -214,9 +214,6 @@ extern void nf_conntrack_tcp_update(stru struct nf_conn *conntrack, int dir); -/* Call me when a conntrack is destroyed. */ -extern void (*nf_conntrack_destroyed)(struct nf_conn *conntrack); - /* Fake conntrack entry for untracked connections */ extern struct nf_conn nf_conntrack_untracked; diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c index 278c6d3..c95661a 100644 --- a/net/ipv4/netfilter/nf_nat_core.c +++ b/net/ipv4/netfilter/nf_nat_core.c @@ -87,20 +87,6 @@ hash_by_src(const struct nf_conntrack_tu tuple->dst.protonum, 0) % nf_nat_htable_size; } -/* Noone using conntrack by the time this called. */ -static void nf_nat_cleanup_conntrack(struct nf_conn *conn) -{ - struct nf_conn_nat *nat; - if (!(conn->status & IPS_NAT_DONE_MASK)) - return; - - nat = nfct_nat(conn); - write_lock_bh(&nf_nat_lock); - list_del(&nat->info.bysource); - nat->info.ct = NULL; - write_unlock_bh(&nf_nat_lock); -} - /* Is this tuple already taken? (not by us) */ int nf_nat_used_tuple(const struct nf_conntrack_tuple *tuple, @@ -603,6 +589,22 @@ nf_nat_port_nfattr_to_range(struct nfatt EXPORT_SYMBOL_GPL(nf_nat_port_range_to_nfattr); #endif +/* Noone using conntrack by the time this called. */ +static void nf_nat_cleanup_conntrack(struct ct_extend *ext) +{ + struct nf_conn_nat *nat = ct_extend_find(ext, CTE_NAT); + + if (nat == NULL || nat->info.ct == NULL) + return; + + NF_CT_ASSERT(nat->info.ct->status & IPS_NAT_DONE_MASK); + + write_lock_bh(&nf_nat_lock); + list_del(&nat->info.bysource); + nat->info.ct = NULL; + write_unlock_bh(&nf_nat_lock); +} + static void nf_nat_move_storage(struct ct_extend *new, struct ct_extend *old) { struct nf_conn_nat *new_nat = ct_extend_find(new, CTE_NAT); @@ -623,10 +625,11 @@ static void nf_nat_move_storage(struct c } struct ct_extend_type nat_extend = { - .len = sizeof(struct nf_conn_nat), - .align = __alignof__(struct nf_conn_nat), - .move = nf_nat_move_storage, - .type = CTE_NAT, + .len = sizeof(struct nf_conn_nat), + .align = __alignof__(struct nf_conn_nat), + .destroy = nf_nat_cleanup_conntrack, + .move = nf_nat_move_storage, + .type = CTE_NAT, }; static int __init nf_nat_init(void) @@ -663,10 +666,6 @@ static int __init nf_nat_init(void) INIT_LIST_HEAD(&bysource[i]); } - /* FIXME: Man, this is a hack. */ - NF_CT_ASSERT(rcu_dereference(nf_conntrack_destroyed) == NULL); - rcu_assign_pointer(nf_conntrack_destroyed, nf_nat_cleanup_conntrack); - /* Initialize fake conntrack so that NAT will skip it */ nf_conntrack_untracked.status |= IPS_NAT_DONE_MASK; @@ -694,7 +693,6 @@ static int clean_nat(struct nf_conn *i, static void __exit nf_nat_cleanup(void) { nf_ct_iterate_cleanup(&clean_nat, NULL); - rcu_assign_pointer(nf_conntrack_destroyed, NULL); synchronize_rcu(); vfree(bysource); nf_ct_l3proto_put(l3proto); diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 99fc52f..41d0921 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -53,9 +53,6 @@ EXPORT_SYMBOL_GPL(nf_conntrack_lock); atomic_t nf_conntrack_count = ATOMIC_INIT(0); EXPORT_SYMBOL_GPL(nf_conntrack_count); -void (*nf_conntrack_destroyed)(struct nf_conn *conntrack); -EXPORT_SYMBOL_GPL(nf_conntrack_destroyed); - unsigned int nf_conntrack_htable_size __read_mostly; EXPORT_SYMBOL_GPL(nf_conntrack_htable_size); @@ -158,7 +155,6 @@ destroy_conntrack(struct nf_conntrack *n struct nf_conn *ct = (struct nf_conn *)nfct; struct nf_conn_help *help = nfct_help(ct); struct nf_conntrack_l4proto *l4proto; - typeof(nf_conntrack_destroyed) destroyed; DEBUGP("destroy_conntrack(%p)\n", ct); NF_CT_ASSERT(atomic_read(&nfct->use) == 0); @@ -181,10 +177,6 @@ destroy_conntrack(struct nf_conntrack *n ct_extend_destroy(ct->ext); - destroyed = rcu_dereference(nf_conntrack_destroyed); - if (destroyed) - destroyed(ct); - rcu_read_unlock(); write_lock_bh(&nf_conntrack_lock); -- 1.4.4 From yasuyuki.kozakai at toshiba.co.jp Mon May 7 14:02:33 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon May 7 15:03:13 2007 Subject: [PATCH 7/7]: nf_nat: Fixes invalid access due to reallocating exntesion area Message-ID: <200705071202.l47C2YA8007383@toshiba.co.jp> ct_extend_add called in nf_conntrack_alter_reply can reallocate extension aera and the pointer to private arae for NAT can be changed. Signed-off-by: Yasuyuki Kozakai --- net/ipv4/netfilter/nf_nat_core.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c index c95661a..d68b3f2 100644 --- a/net/ipv4/netfilter/nf_nat_core.c +++ b/net/ipv4/netfilter/nf_nat_core.c @@ -297,7 +297,6 @@ nf_nat_setup_info(struct nf_conn *ct, return NF_ACCEPT; } } - info = &nat->info; NF_CT_ASSERT(hooknum == NF_IP_PRE_ROUTING || hooknum == NF_IP_POST_ROUTING || @@ -335,6 +334,8 @@ nf_nat_setup_info(struct nf_conn *ct, srchash = hash_by_src(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); write_lock_bh(&nf_nat_lock); + /* nf_conntrack_alter_reply might re-allocate exntension aera */ + info = &nfct_nat(ct)->info; info->ct = ct; list_add(&info->bysource, &bysource[srchash]); write_unlock_bh(&nf_nat_lock); -- 1.4.4 From kaber at trash.net Tue May 8 11:46:40 2007 From: kaber at trash.net (Patrick McHardy) Date: Tue May 8 12:49:48 2007 Subject: [RFC][PATCH 0/7]: ct_extend In-Reply-To: <200705071200.l47C0UoM006287@toshiba.co.jp> References: <200705071200.l47C0UoM006287@toshiba.co.jp> Message-ID: <46404700.40609@trash.net> Yasuyuki KOZAKAI wrote: > I'm re-writing ct_extend patchset. This patchset is a snapshot. > Like Rusty's original one, it allocates memory area by kmem_cache_alloc() > to store basic informations about a connection, but it uses kmalloc() to > allocate memory area for extension (currently helper and NAT). > > Some concepts are following. > - 'struct ct_extend' keeps offsets to each area and the total size of them, > instead of identifiers of extensions. This scheme can eliminate loops and > make codes simple, but limits the total size of area to 256 bytes. Is it > too small ? If so, we can be back to the original ct_extend. I think this will do, I believe we're somewhere in the 40-50 byte range now with both NAT and helpers. > - To add a new area, it reallocates ct_extend. To fix the pointer to it from > other objects, the 'move' operation defined by extension is used. > > - It does not have the operation to remove a memory area from > ct_extend. Because it causes reallocating and restructuring ct_extend. > It is complicated operation. And removing extension from all conntracks > would require heavy processing. I prefer to leave unused area. Agreed. > - I added 'destroy' operation which is called in destroy_conntrack(). It > can kill global operation 'nf_conntrack_destroyed' used by NAT. Nice work :) > The issues I noticed are following. > - This patchset does not consider locking. The places calling nfct_help() or > nfct_nat() must be protected with new read-write lock. It will add > some processing time and complexities. This will add quite some overhead since at least nfct_help is looked at for every packet (we might avoid this using a status flag though). I'm guessing the locks are needed to protect against concurrent reallocations. Maybe we can avoid this by adding the limitation that only unconfirmed entries may add new extensions? > - ct_extend_add() reallocates memory area for all extensions. All helpers > and NAT codes are necessary to take care that the pointer nfct_help(ct) > and nfct_nat(ct) might be changed. It would make difficult to find bugs > caused by this issue. Thats something we'll have to live with I guess. The same is true for the skb reallocation functions, maybe we can get a sparse check for this some day. > And some improvements can be considered/are necessary. > - Introducing new locking > - 'move' operation might be better to have a argument 'struct nf_conn *ct'. > - Moving other stuff in 'struct nf_conn' to ct_extend > - Spliting nf_conn_nat into helper parts and others > - Fixes of function names (nf_ct_ext_, nfct_ext_, nf_cte_, or ?) I prefer nf_ct_ext_ or nfct_ext_. > Comments are welcome. I'm thinking we could probably avoid some reallocations by doing a more accurate CT_EXTEND_MIN_SIZE calculation by taking nf_nat_module_is_loaded into account. Only makes sense if it currently is smaller than the space needed for NAT+MASQUERADE of course. From kaber at trash.net Tue May 8 10:32:51 2007 From: kaber at trash.net (Patrick McHardy) Date: Tue May 8 13:19:53 2007 Subject: [PATCH 0/5]: kill unused stuff and fixes re-assigning helper In-Reply-To: <200705070259.l472xcgO014664@toshiba.co.jp> References: <200705070259.l472xcgO014664@toshiba.co.jp> Message-ID: <464035B3.70406@trash.net> Yasuyuki KOZAKAI wrote: > They remove unused l3proto->destroy() and duplicated declarations, > clear private area in 'struct nf_conn' for helper before reusing the area, > and considers about unchanged helper when re-assigning helper. > > Patrick, please consider to apply them. All patches applied, thanks Yasuyuki. From hdemir at metu.edu.tr Tue May 8 13:09:05 2007 From: hdemir at metu.edu.tr (husnu demir) Date: Tue May 8 14:09:51 2007 Subject: Compile errors for debian-amd64 Message-ID: <20070508110905.GA3768482@metu.edu.tr> Hi, I am getting compile errors on debian-amd64. Can somebody point me correct place? hdemir. Thanks. # uname -a Linux auth 2.6.18.8 #2 SMP Tue May 1 06:43:45 EDT 2007 x86_64 GNU/Linux compile for linux-2.6.21.1 # make .. .. OBJCOPY arch/x86_64/boot/vmlinux.bin HOSTCC arch/x86_64/boot/tools/build BUILD arch/x86_64/boot/bzImage Root device is (104, 1) Boot sector 512 bytes. Setup is 7343 bytes. System is 1742 kB Kernel: arch/x86_64/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 754 modules WARNING: "ip6t_register_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! WARNING: "ip6t_unregister_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 All the added modules gave the same error for the PoM-ng. I select the "Layer 3 Independent Connection tracking". From docnielsen at gmail.com Tue May 8 14:52:10 2007 From: docnielsen at gmail.com (Doc Nielsen) Date: Tue May 8 15:52:55 2007 Subject: Compile errors for debian-amd64 In-Reply-To: <20070508110905.GA3768482@metu.edu.tr> References: <20070508110905.GA3768482@metu.edu.tr> Message-ID: <78e398b30705080552nc68462ckb13f7a295f6ed7e5@mail.gmail.com> On 5/8/07, husnu demir wrote: > I am getting compile errors on debian-amd64. Can somebody point me correct place? > MODPOST 754 modules > WARNING: "ip6t_register_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ip6t_unregister_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 thats funny, i got the same error while compiling a fresh 2.6.21.1 last night. Guess it wasn't just my system acting up. -Doc -- No trees were killed in the sending of this message However, a large number of electrons were terribly inconvenienced. Join the Revolution: 09f911029d74e35bd84156c5635688c0 From kaber at trash.net Tue May 8 14:53:28 2007 From: kaber at trash.net (Patrick McHardy) Date: Tue May 8 15:56:42 2007 Subject: Compile errors for debian-amd64 In-Reply-To: <78e398b30705080552nc68462ckb13f7a295f6ed7e5@mail.gmail.com> References: <20070508110905.GA3768482@metu.edu.tr> <78e398b30705080552nc68462ckb13f7a295f6ed7e5@mail.gmail.com> Message-ID: <464072C8.3060204@trash.net> Doc Nielsen wrote: > On 5/8/07, husnu demir wrote: > >> I am getting compile errors on debian-amd64. Can somebody point me >> correct place? > > >> MODPOST 754 modules >> WARNING: "ip6t_register_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] >> undefined! >> ... > > > thats funny, i got the same error while compiling a fresh 2.6.21.1 last > night. > Guess it wasn't just my system acting up. Patches for this have been sent multiple times, please search the archives. From hdemir at metu.edu.tr Tue May 8 16:53:48 2007 From: hdemir at metu.edu.tr (husnu demir) Date: Tue May 8 17:54:29 2007 Subject: [hdemir {at} metu.edu.tr: Re: Compile errors for debian-amd64] Message-ID: <20070508145348.GA249876@metu.edu.tr> I think this message lost. hdemir. ----- Forwarded message from husnu demir ----- Date: Tue, 8 May 2007 15:32:41 +0300 From: husnu demir To: netfilter-devel@lists.netfilter.org Subject: Re: Compile errors for debian-amd64 In-Reply-To: <20070508110905.GA3768482@metu.edu.tr> User-Agent: Mutt/1.5.11 Hi again, I will reply myself again. I am not a programmer so I solved my problem with changing the appropriate lines from the files. Somebody have forgotten the patchs I think. I changed the ipt_(un)register_match to xt_(un)register_match. Also, in some places I saw ipt_match should be changed to xt_match. Therefore I changed all with "(Layer 3 Dependent Connection tracking (OBSOLETE))". At the and ; # uname -a Linux auth 2.6.21.1 #3 SMP Tue May 8 11:12:18 EDT 2007 x86_64 GNU/Linux all compile without problem. I saw some patches at the CVS lists but these patches may be unapplied. I think, somebody should check with the CVS version. Or may I doing something wrong? Am I downloading from the wrong site (ftp.netfilter.org/.../snapshot...). Thanks in advance. hdemir. On Tue, May 08, 2007 at 02:09:05PM +0300, husnu demir wrote: > Hi, > > I am getting compile errors on debian-amd64. Can somebody point me correct place? > > > hdemir. > > Thanks. > > # uname -a > Linux auth 2.6.18.8 #2 SMP Tue May 1 06:43:45 EDT 2007 x86_64 GNU/Linux > > > > compile for linux-2.6.21.1 > > # make > .. > .. > > OBJCOPY arch/x86_64/boot/vmlinux.bin > HOSTCC arch/x86_64/boot/tools/build > BUILD arch/x86_64/boot/bzImage > Root device is (104, 1) > Boot sector 512 bytes. > Setup is 7343 bytes. > System is 1742 kB > Kernel: arch/x86_64/boot/bzImage is ready (#1) > Building modules, stage 2. > MODPOST 754 modules > WARNING: "ip6t_register_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ip6t_unregister_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > > All the added modules gave the same error for the PoM-ng. I select the "Layer 3 Independent Connection tracking". > > > > ----- End forwarded message ----- From hdemir at metu.edu.tr Tue May 8 14:32:41 2007 From: hdemir at metu.edu.tr (husnu demir) Date: Tue May 8 18:13:42 2007 Subject: Compile errors for debian-amd64 In-Reply-To: <20070508110905.GA3768482@metu.edu.tr> References: <20070508110905.GA3768482@metu.edu.tr> Message-ID: <20070508123241.GA1384606@metu.edu.tr> Hi again, I will reply myself again. I am not a programmer so I solved my problem with changing the appropriate lines from the files. Somebody have forgotten the patchs I think. I changed the ipt_(un)register_match to xt_(un)register_match. Also, in some places I saw ipt_match should be changed to xt_match. Therefore I changed all with "(Layer 3 Dependent Connection tracking (OBSOLETE))". At the and ; # uname -a Linux auth 2.6.21.1 #3 SMP Tue May 8 11:12:18 EDT 2007 x86_64 GNU/Linux all compile without problem. I saw some patches at the CVS lists but these patches may be unapplied. I think, somebody should check with the CVS version. Or may I doing something wrong? Am I downloading from the wrong site (ftp.netfilter.org/.../snapshot...). Thanks in advance. hdemir. On Tue, May 08, 2007 at 02:09:05PM +0300, husnu demir wrote: > Hi, > > I am getting compile errors on debian-amd64. Can somebody point me correct place? > > > hdemir. > > Thanks. > > # uname -a > Linux auth 2.6.18.8 #2 SMP Tue May 1 06:43:45 EDT 2007 x86_64 GNU/Linux > > > > compile for linux-2.6.21.1 > > # make > .. > .. > > OBJCOPY arch/x86_64/boot/vmlinux.bin > HOSTCC arch/x86_64/boot/tools/build > BUILD arch/x86_64/boot/bzImage > Root device is (104, 1) > Boot sector 512 bytes. > Setup is 7343 bytes. > System is 1742 kB > Kernel: arch/x86_64/boot/bzImage is ready (#1) > Building modules, stage 2. > MODPOST 754 modules > WARNING: "ip6t_register_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ip6t_unregister_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_connlimit.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > > All the added modules gave the same error for the PoM-ng. I select the "Layer 3 Independent Connection tracking". > > > > From frozenspot at gmail.com Tue May 8 21:07:31 2007 From: frozenspot at gmail.com (fender) Date: Tue May 8 22:08:17 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <463DF61F.50509@netfilter.org> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> Message-ID: <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> On 5/6/07, Pablo Neira Ayuso wrote: > fender wrote: > > On 5/4/07, Patrick McHardy wrote: > >> Nothing, just set up the repository and send me the link. > > > > I'm sorry, I don't know what link of these will be the necessary: > > > > 1) http://portknocko.berlios.de/ ---> (project home page) > > > > 2) http://developer.berlios.de/project/showfiles.php?group_id=7093 ---> > > (.tar.gz files to download) > > > > 3) http://svn.berlios.de/svnroot/repos/portknocko/trunk > > No, Patrick means a link to your repository in pom-ng format. So > everybody can get external patchlets via ./runme --download. > > 1) Create a tarball with your project in pom-ng format [1]. > 2) Create a file called "index" that contains the name of your extension > in the same directory where you have put the tarball > 3) Send us the URL to add it to our sources.list file. > > [1] http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/ > This is the link: http://portknocko.berlios.de/pom-ng/ Regards, -- J. Federico Hernandez From max at rfc2324.org Wed May 9 00:07:14 2007 From: max at rfc2324.org (Maximilian Wilhelm) Date: Wed May 9 01:07:56 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> Message-ID: <20070508220714.GA23200@outback.rfc2324.org> On Tuesday, May 8th fender wrote: ~~~~~~ Is this your real name? > This is the link: > http://portknocko.berlios.de/pom-ng/ | Forbidden | You don't have permission to access /pom-ng/pknock-0.3.tar.gz on this server. Ciao Max -- Follow the white penguin. From vvs at sw.ru Wed May 9 08:59:03 2007 From: vvs at sw.ru (Vasily Averin) Date: Wed May 9 10:50:13 2007 Subject: [NETFILTER] early_drop() imrovement (v3) In-Reply-To: <46187770.1070106@sw.ru> References: <4615FE1D.80206@sw.ru> <20070406102433.d3a670a5.dada1@cosmosbay.com> <4616203A.80203@sw.ru> <4616626C.9020100@trash.net> <4617845F.7080203@sw.ru> <461789CF.8000106@cosmosbay.com> <46187770.1070106@sw.ru> Message-ID: <46417137.5080501@sw.ru> When the number of conntracks is reached nf_conntrack_max limit, early_drop() tries to free one of already used conntracks. If it does not find any conntracks that may be freed, it leads to transmission errors. In current implementation the conntracks are searched in one hash bucket only. It have some drawbacks: if used hash bucket is empty we have not any chances to find something. On the other hand the hash bucket can contain a huge number of conntracks and its check can last a long time. The proposed patch limits the number of checked conntracks by default number of conntracks in one hash bucket (NF_CT_PER_BUCKET) and allows to search conntracks in other hash buckets. As result in any case the search will have the same chances to free one of the conntracks and the check will not lead to long delays. Signed-off-by: Vasily Averin diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e132c8a..d984bce 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -76,6 +76,8 @@ static unsigned int nf_conntrack_next_id; DEFINE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat); EXPORT_PER_CPU_SYMBOL(nf_conntrack_stat); +#define NF_CT_PER_BUCKET 8U + /* * This scheme offers various size of "struct nf_conn" dependent on * features(helper, nat, ...) @@ -525,7 +527,7 @@ EXPORT_SYMBOL_GPL(nf_conntrack_tuple_taken); /* There's a small race here where we may free a just-assured connection. Too bad: we're in trouble anyway. */ -static int early_drop(struct list_head *chain) +static int __early_drop(struct list_head *chain, unsigned int *cnt) { /* Traverse backwards: gives us oldest, which is roughly LRU */ struct nf_conntrack_tuple_hash *h; @@ -540,6 +542,8 @@ static int early_drop(struct list_head *chain) atomic_inc(&ct->ct_general.use); break; } + if (!--(*cnt)) + break; } read_unlock_bh(&nf_conntrack_lock); @@ -555,6 +559,21 @@ static int early_drop(struct list_head *chain) return dropped; } +static int early_drop(const struct nf_conntrack_tuple *orig) +{ + unsigned int i, hash, cnt; + int ret = 0; + + hash = hash_conntrack(orig); + cnt = NF_CT_PER_BUCKET; + + for (i = 0; + !ret && cnt && i < nf_conntrack_htable_size; + ++i, hash = ++hash % nf_conntrack_htable_size) + ret = __early_drop(&nf_conntrack_hash[hash], &cnt); + return ret; +} + static struct nf_conn * __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, const struct nf_conntrack_tuple *repl, @@ -574,9 +593,7 @@ __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, if (nf_conntrack_max && atomic_read(&nf_conntrack_count) > nf_conntrack_max) { - unsigned int hash = hash_conntrack(orig); - /* Try dropping from this hash chain. */ - if (!early_drop(&nf_conntrack_hash[hash])) { + if (!early_drop(orig)) { atomic_dec(&nf_conntrack_count); if (net_ratelimit()) printk(KERN_WARNING @@ -1226,7 +1243,7 @@ int __init nf_conntrack_init(void) if (nf_conntrack_htable_size < 16) nf_conntrack_htable_size = 16; } - nf_conntrack_max = 8 * nf_conntrack_htable_size; + nf_conntrack_max = NF_CT_PER_BUCKET * nf_conntrack_htable_size; printk("nf_conntrack version %s (%u buckets, %d max)\n", NF_CONNTRACK_VERSION, nf_conntrack_htable_size, From yasuyuki.kozakai at toshiba.co.jp Wed May 9 13:05:12 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Wed May 9 14:06:27 2007 Subject: [RFC][PATCH 0/7]: ct_extend In-Reply-To: <46404700.40609@trash.net> References: <200705071200.l47C0UoM006287@toshiba.co.jp> <46404700.40609@trash.net> Message-ID: <200705091105.l49B5DQt026096@toshiba.co.jp> Hi, Patrick, From: Patrick McHardy Date: Tue, 08 May 2007 11:46:40 +0200 > > The issues I noticed are following. > > - This patchset does not consider locking. The places calling nfct_help() or > > nfct_nat() must be protected with new read-write lock. It will add > > some processing time and complexities. > > > This will add quite some overhead since at least nfct_help is looked at > for every packet (we might avoid this using a status flag though). > I'm guessing the locks are needed to protect against concurrent > reallocations. Maybe we can avoid this by adding the limitation that > only unconfirmed entries may add new extensions? It sounds good to avoid competition of 2 packet processing. I think that the remain is nfctnetlink. It can assign helper to a confirmed conntrack. Do you think that it's enough to assume that it disables bh ? > > - ct_extend_add() reallocates memory area for all extensions. All helpers > > and NAT codes are necessary to take care that the pointer nfct_help(ct) > > and nfct_nat(ct) might be changed. It would make difficult to find bugs > > caused by this issue. > > > Thats something we'll have to live with I guess. The same is true for > the skb reallocation functions, maybe we can get a sparse check for > this some day. I agree. > > And some improvements can be considered/are necessary. > > - Introducing new locking > > - 'move' operation might be better to have a argument 'struct nf_conn *ct'. > > - Moving other stuff in 'struct nf_conn' to ct_extend > > - Spliting nf_conn_nat into helper parts and others > > - Fixes of function names (nf_ct_ext_, nfct_ext_, nf_cte_, or ?) > > > I prefer nf_ct_ext_ or nfct_ext_. Ok, I'll replace them with nf_ct_ext_*. > I'm thinking we could probably avoid some reallocations by doing > a more accurate CT_EXTEND_MIN_SIZE calculation by taking > nf_nat_module_is_loaded into account. Only makes sense if it > currently is smaller than the space needed for NAT+MASQUERADE > of course. Good idea. On my laptop, CT_EXTEND_MIN_SIZE is 32 bytes, the size of helper area is 32 bytes, and 36 bytes for NAT. The helper area is allocated before the NAT, so pre-allocating NAT area can reduce the number of allocation. I'll add a flag to 'ct_extend_type' to intend pre-allocating. Thanks for comments, -- Yasuyuki Kozakai From frozenspot at gmail.com Wed May 9 13:48:59 2007 From: frozenspot at gmail.com (fender) Date: Wed May 9 14:49:48 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <20070508220714.GA23200@outback.rfc2324.org> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> <20070508220714.GA23200@outback.rfc2324.org> Message-ID: <7e36c7130705090448r2e29e4b0nce3b62ed08df1913@mail.gmail.com> On 5/8/07, Maximilian Wilhelm wrote: > > > This is the link: > > > http://portknocko.berlios.de/pom-ng/ > > | Forbidden > | You don't have permission to access /pom-ng/pknock-0.3.tar.gz on this server. > Thanks Max. I'm sorry, the berlios repository doesn't let me to put external files (the tarball). I will try with another server and I will send you the link to the tarball. Regards, -- J. Federico Hernandez From michael.ransburg at gmail.com Wed May 9 17:32:06 2007 From: michael.ransburg at gmail.com (Michael Ransburg) Date: Wed May 9 18:32:56 2007 Subject: Userspace packet queuing with libipq: ip_conntrack does not defragment? Message-ID: <22b256140705090832v556bee45ne5119d529a7e310e@mail.gmail.com> Hi all, I'm using libipq to pass certain packets to my userspace application on Fedora 6 / Kernel 2.6.21.1 and ipTables 1.3.5. I do: modprobe iptable_filter modprobe ip_queue modprobe ip_conntrack iptables -A INPUT -p tcp -j QUEUE Works fine. However, since ip_conntrack is loaded I would expect that the packets are defragmented before they are passed to my userspace appliation (as indicated here for example: http://lists.netfilter.org/pipermail/netfilter/2002-May/034006.html). This does not seem the case, i.e., the maximum size of the packets which I get (through ->data_len) is 1500 bits. The len parameter of the ipq_read method is well over 1500, as is the buffer size. Any suggestions what I'm doing wrong? Many thanks, Michael -- icq: 71772353 | skype: daneel1409 | msn: mike@unfolded.com From michael.ransburg at gmail.com Wed May 9 17:52:25 2007 From: michael.ransburg at gmail.com (Michael Ransburg) Date: Wed May 9 18:53:16 2007 Subject: Userspace packet queuing with libipq: ip_conntrack does not defragment? In-Reply-To: <22b256140705090832v556bee45ne5119d529a7e310e@mail.gmail.com> References: <22b256140705090832v556bee45ne5119d529a7e310e@mail.gmail.com> Message-ID: <22b256140705090852p5a9c512ck67993032641c8589@mail.gmail.com> > Any suggestions what I'm doing wrong? A small update: I found out (through this presentation: http://ants.iis.sinica.edu.tw/linux_summer_school/Connection%20Tracking.ppt#262,5,Slide 5) that defragmentation is only available in the prerouting and output chains. I therefore changed my iptables rule to OUTPUT, but I'm getting the same result, i.e., maximum packet sizes of 1500. Any hints are appreciated. Thanks, Michael -- icq: 71772353 | skype: daneel1409 | msn: mike@unfolded.com From m at rtij.nl Wed May 9 18:34:22 2007 From: m at rtij.nl (Martijn Lievaart) Date: Wed May 9 19:36:03 2007 Subject: Userspace packet queuing with libipq: ip_conntrack does not defragment? In-Reply-To: <22b256140705090832v556bee45ne5119d529a7e310e@mail.gmail.com> References: <22b256140705090832v556bee45ne5119d529a7e310e@mail.gmail.com> Message-ID: <4641F80E.8050103@rtij.nl> Michael Ransburg wrote: > However, since ip_conntrack is loaded I would expect that > the packets are defragmented before they are passed to my userspace > appliation (as indicated here for example: > http://lists.netfilter.org/pipermail/netfilter/2002-May/034006.html). > This does not seem the case, i.e., the maximum size of the packets > which I get (through ->data_len) is 1500 bits. > > The len parameter of the ipq_read method is well over 1500, as is the > buffer size. Do you actually have packets greater than 1500 bytes? That would mean you send over loopback, tokenring, etc, but NOT ethernet. Maybe you are confusing datagram and packet fragmentation. Conntrack only defragments packets, not datagrams. HTH, M4 From michael.ransburg at gmail.com Wed May 9 20:12:05 2007 From: michael.ransburg at gmail.com (Michael Ransburg) Date: Wed May 9 21:12:54 2007 Subject: Userspace packet queuing with libipq: ip_conntrack does not defragment? In-Reply-To: <22b256140705091043m3ff01e3djc45390edbf84293c@mail.gmail.com> References: <22b256140705090832v556bee45ne5119d529a7e310e@mail.gmail.com> <4641F80E.8050103@rtij.nl> <22b256140705091014i1d3d7578nf8ed6b20cc1aa1fa@mail.gmail.com> <46420398.7060101@rtij.nl> <22b256140705091043m3ff01e3djc45390edbf84293c@mail.gmail.com> Message-ID: <22b256140705091112i75f9677ep8aabd4ae33e7844f@mail.gmail.com> > > This was indeed my misconception. I thought that conntrack would > > reassemble IP datagrams into the original (single) TCP/IP datagram. I > > would like to access and inspect the reassembled TCP/IP datagram on my > > firewall/router. Can netfilter provide me with this, i.e., can it take > > care of reassembling and fragmentation of (e.g.) TCP/IP datagrams? > > > > Mu! Tcp uses streams. There is nothing to reassemble. Udp uses > datagrams, but netfilter cannot (and should not) reassemble those. > > What are you trying to achieve in the first place? Sorry for using the wrong terminology. Let's say I'm downloading a video from a website (over HTTP/TCP/IP). What I see is that each picture of the video is send as a single TCP/IP packet (?) - usually with a size of around 10 KB. This TCP/IP packet is fragmented according to the MTU and therefore I see the following fragments on the wire: Fragment 1: application data Fragment 2: application data Fragment 3: application data ? On my router/firewall I would like to inspect the video picture as a whole. In my current (windows) application I have to reassemble the fragments manually into the original TCP/IP packet. I hoped that netfilter would make my life easier by performing the reassembling for me (and potentially also the recalculation of the checksum(s) if the video picture is changed). Is there support in netfilter for this kind of stuff? I've googled quite a bit and there seem to be discussions indicating that NAT is doing that (http://lists.netfilter.org/pipermail/netfilter/2001-January/006915.html)...? Many thanks again for your help, Michael -- icq: 71772353 | skype: daneel1409 | msn: mike@unfolded.com From vvs at sw.ru Wed May 9 08:59:03 2007 From: vvs at sw.ru (Vasily Averin) Date: Wed May 9 23:14:02 2007 Subject: [NETFILTER] early_drop() imrovement (v3) In-Reply-To: <46187770.1070106@sw.ru> References: <4615FE1D.80206@sw.ru> <20070406102433.d3a670a5.dada1@cosmosbay.com> <4616203A.80203@sw.ru> <4616626C.9020100@trash.net> <4617845F.7080203@sw.ru> <461789CF.8000106@cosmosbay.com> <46187770.1070106@sw.ru> Message-ID: <46417137.5080501@sw.ru> When the number of conntracks is reached nf_conntrack_max limit, early_drop() tries to free one of already used conntracks. If it does not find any conntracks that may be freed, it leads to transmission errors. In current implementation the conntracks are searched in one hash bucket only. It have some drawbacks: if used hash bucket is empty we have not any chances to find something. On the other hand the hash bucket can contain a huge number of conntracks and its check can last a long time. The proposed patch limits the number of checked conntracks by default number of conntracks in one hash bucket (NF_CT_PER_BUCKET) and allows to search conntracks in other hash buckets. As result in any case the search will have the same chances to free one of the conntracks and the check will not lead to long delays. Signed-off-by: Vasily Averin diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e132c8a..d984bce 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -76,6 +76,8 @@ static unsigned int nf_conntrack_next_id; DEFINE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat); EXPORT_PER_CPU_SYMBOL(nf_conntrack_stat); +#define NF_CT_PER_BUCKET 8U + /* * This scheme offers various size of "struct nf_conn" dependent on * features(helper, nat, ...) @@ -525,7 +527,7 @@ EXPORT_SYMBOL_GPL(nf_conntrack_tuple_taken); /* There's a small race here where we may free a just-assured connection. Too bad: we're in trouble anyway. */ -static int early_drop(struct list_head *chain) +static int __early_drop(struct list_head *chain, unsigned int *cnt) { /* Traverse backwards: gives us oldest, which is roughly LRU */ struct nf_conntrack_tuple_hash *h; @@ -540,6 +542,8 @@ static int early_drop(struct list_head *chain) atomic_inc(&ct->ct_general.use); break; } + if (!--(*cnt)) + break; } read_unlock_bh(&nf_conntrack_lock); @@ -555,6 +559,21 @@ static int early_drop(struct list_head *chain) return dropped; } +static int early_drop(const struct nf_conntrack_tuple *orig) +{ + unsigned int i, hash, cnt; + int ret = 0; + + hash = hash_conntrack(orig); + cnt = NF_CT_PER_BUCKET; + + for (i = 0; + !ret && cnt && i < nf_conntrack_htable_size; + ++i, hash = ++hash % nf_conntrack_htable_size) + ret = __early_drop(&nf_conntrack_hash[hash], &cnt); + return ret; +} + static struct nf_conn * __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, const struct nf_conntrack_tuple *repl, @@ -574,9 +593,7 @@ __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, if (nf_conntrack_max && atomic_read(&nf_conntrack_count) > nf_conntrack_max) { - unsigned int hash = hash_conntrack(orig); - /* Try dropping from this hash chain. */ - if (!early_drop(&nf_conntrack_hash[hash])) { + if (!early_drop(orig)) { atomic_dec(&nf_conntrack_count); if (net_ratelimit()) printk(KERN_WARNING @@ -1226,7 +1243,7 @@ int __init nf_conntrack_init(void) if (nf_conntrack_htable_size < 16) nf_conntrack_htable_size = 16; } - nf_conntrack_max = 8 * nf_conntrack_htable_size; + nf_conntrack_max = NF_CT_PER_BUCKET * nf_conntrack_htable_size; printk("nf_conntrack version %s (%u buckets, %d max)\n", NF_CONNTRACK_VERSION, nf_conntrack_htable_size, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From vvs at sw.ru Wed May 9 08:59:03 2007 From: vvs at sw.ru (Vasily Averin) Date: Thu May 10 00:41:44 2007 Subject: [NETFILTER] early_drop() imrovement (v3) In-Reply-To: <46187770.1070106@sw.ru> References: <4615FE1D.80206@sw.ru> <20070406102433.d3a670a5.dada1@cosmosbay.com> <4616203A.80203@sw.ru> <4616626C.9020100@trash.net> <4617845F.7080203@sw.ru> <461789CF.8000106@cosmosbay.com> <46187770.1070106@sw.ru> Message-ID: <46417137.5080501@sw.ru> When the number of conntracks is reached nf_conntrack_max limit, early_drop() tries to free one of already used conntracks. If it does not find any conntracks that may be freed, it leads to transmission errors. In current implementation the conntracks are searched in one hash bucket only. It have some drawbacks: if used hash bucket is empty we have not any chances to find something. On the other hand the hash bucket can contain a huge number of conntracks and its check can last a long time. The proposed patch limits the number of checked conntracks by default number of conntracks in one hash bucket (NF_CT_PER_BUCKET) and allows to search conntracks in other hash buckets. As result in any case the search will have the same chances to free one of the conntracks and the check will not lead to long delays. Signed-off-by: Vasily Averin diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e132c8a..d984bce 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -76,6 +76,8 @@ static unsigned int nf_conntrack_next_id; DEFINE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat); EXPORT_PER_CPU_SYMBOL(nf_conntrack_stat); +#define NF_CT_PER_BUCKET 8U + /* * This scheme offers various size of "struct nf_conn" dependent on * features(helper, nat, ...) @@ -525,7 +527,7 @@ EXPORT_SYMBOL_GPL(nf_conntrack_tuple_taken); /* There's a small race here where we may free a just-assured connection. Too bad: we're in trouble anyway. */ -static int early_drop(struct list_head *chain) +static int __early_drop(struct list_head *chain, unsigned int *cnt) { /* Traverse backwards: gives us oldest, which is roughly LRU */ struct nf_conntrack_tuple_hash *h; @@ -540,6 +542,8 @@ static int early_drop(struct list_head *chain) atomic_inc(&ct->ct_general.use); break; } + if (!--(*cnt)) + break; } read_unlock_bh(&nf_conntrack_lock); @@ -555,6 +559,21 @@ static int early_drop(struct list_head *chain) return dropped; } +static int early_drop(const struct nf_conntrack_tuple *orig) +{ + unsigned int i, hash, cnt; + int ret = 0; + + hash = hash_conntrack(orig); + cnt = NF_CT_PER_BUCKET; + + for (i = 0; + !ret && cnt && i < nf_conntrack_htable_size; + ++i, hash = ++hash % nf_conntrack_htable_size) + ret = __early_drop(&nf_conntrack_hash[hash], &cnt); + return ret; +} + static struct nf_conn * __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, const struct nf_conntrack_tuple *repl, @@ -574,9 +593,7 @@ __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, if (nf_conntrack_max && atomic_read(&nf_conntrack_count) > nf_conntrack_max) { - unsigned int hash = hash_conntrack(orig); - /* Try dropping from this hash chain. */ - if (!early_drop(&nf_conntrack_hash[hash])) { + if (!early_drop(orig)) { atomic_dec(&nf_conntrack_count); if (net_ratelimit()) printk(KERN_WARNING @@ -1226,7 +1243,7 @@ int __init nf_conntrack_init(void) if (nf_conntrack_htable_size < 16) nf_conntrack_htable_size = 16; } - nf_conntrack_max = 8 * nf_conntrack_htable_size; + nf_conntrack_max = NF_CT_PER_BUCKET * nf_conntrack_htable_size; printk("nf_conntrack version %s (%u buckets, %d max)\n", NF_CONNTRACK_VERSION, nf_conntrack_htable_size, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From vvs at sw.ru Wed May 9 08:59:03 2007 From: vvs at sw.ru (Vasily Averin) Date: Thu May 10 00:52:13 2007 Subject: [NETFILTER] early_drop() imrovement (v3) In-Reply-To: <46187770.1070106@sw.ru> References: <4615FE1D.80206@sw.ru> <20070406102433.d3a670a5.dada1@cosmosbay.com> <4616203A.80203@sw.ru> <4616626C.9020100@trash.net> <4617845F.7080203@sw.ru> <461789CF.8000106@cosmosbay.com> <46187770.1070106@sw.ru> Message-ID: <46417137.5080501@sw.ru> When the number of conntracks is reached nf_conntrack_max limit, early_drop() tries to free one of already used conntracks. If it does not find any conntracks that may be freed, it leads to transmission errors. In current implementation the conntracks are searched in one hash bucket only. It have some drawbacks: if used hash bucket is empty we have not any chances to find something. On the other hand the hash bucket can contain a huge number of conntracks and its check can last a long time. The proposed patch limits the number of checked conntracks by default number of conntracks in one hash bucket (NF_CT_PER_BUCKET) and allows to search conntracks in other hash buckets. As result in any case the search will have the same chances to free one of the conntracks and the check will not lead to long delays. Signed-off-by: Vasily Averin diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e132c8a..d984bce 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -76,6 +76,8 @@ static unsigned int nf_conntrack_next_id; DEFINE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat); EXPORT_PER_CPU_SYMBOL(nf_conntrack_stat); +#define NF_CT_PER_BUCKET 8U + /* * This scheme offers various size of "struct nf_conn" dependent on * features(helper, nat, ...) @@ -525,7 +527,7 @@ EXPORT_SYMBOL_GPL(nf_conntrack_tuple_taken); /* There's a small race here where we may free a just-assured connection. Too bad: we're in trouble anyway. */ -static int early_drop(struct list_head *chain) +static int __early_drop(struct list_head *chain, unsigned int *cnt) { /* Traverse backwards: gives us oldest, which is roughly LRU */ struct nf_conntrack_tuple_hash *h; @@ -540,6 +542,8 @@ static int early_drop(struct list_head *chain) atomic_inc(&ct->ct_general.use); break; } + if (!--(*cnt)) + break; } read_unlock_bh(&nf_conntrack_lock); @@ -555,6 +559,21 @@ static int early_drop(struct list_head *chain) return dropped; } +static int early_drop(const struct nf_conntrack_tuple *orig) +{ + unsigned int i, hash, cnt; + int ret = 0; + + hash = hash_conntrack(orig); + cnt = NF_CT_PER_BUCKET; + + for (i = 0; + !ret && cnt && i < nf_conntrack_htable_size; + ++i, hash = ++hash % nf_conntrack_htable_size) + ret = __early_drop(&nf_conntrack_hash[hash], &cnt); + return ret; +} + static struct nf_conn * __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, const struct nf_conntrack_tuple *repl, @@ -574,9 +593,7 @@ __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, if (nf_conntrack_max && atomic_read(&nf_conntrack_count) > nf_conntrack_max) { - unsigned int hash = hash_conntrack(orig); - /* Try dropping from this hash chain. */ - if (!early_drop(&nf_conntrack_hash[hash])) { + if (!early_drop(orig)) { atomic_dec(&nf_conntrack_count); if (net_ratelimit()) printk(KERN_WARNING @@ -1226,7 +1243,7 @@ int __init nf_conntrack_init(void) if (nf_conntrack_htable_size < 16) nf_conntrack_htable_size = 16; } - nf_conntrack_max = 8 * nf_conntrack_htable_size; + nf_conntrack_max = NF_CT_PER_BUCKET * nf_conntrack_htable_size; printk("nf_conntrack version %s (%u buckets, %d max)\n", NF_CONNTRACK_VERSION, nf_conntrack_htable_size, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From vvs at sw.ru Wed May 9 08:59:03 2007 From: vvs at sw.ru (Vasily Averin) Date: Thu May 10 00:53:11 2007 Subject: [NETFILTER] early_drop() imrovement (v3) In-Reply-To: <46187770.1070106@sw.ru> References: <4615FE1D.80206@sw.ru> <20070406102433.d3a670a5.dada1@cosmosbay.com> <4616203A.80203@sw.ru> <4616626C.9020100@trash.net> <4617845F.7080203@sw.ru> <461789CF.8000106@cosmosbay.com> <46187770.1070106@sw.ru> Message-ID: <46417137.5080501@sw.ru> When the number of conntracks is reached nf_conntrack_max limit, early_drop() tries to free one of already used conntracks. If it does not find any conntracks that may be freed, it leads to transmission errors. In current implementation the conntracks are searched in one hash bucket only. It have some drawbacks: if used hash bucket is empty we have not any chances to find something. On the other hand the hash bucket can contain a huge number of conntracks and its check can last a long time. The proposed patch limits the number of checked conntracks by default number of conntracks in one hash bucket (NF_CT_PER_BUCKET) and allows to search conntracks in other hash buckets. As result in any case the search will have the same chances to free one of the conntracks and the check will not lead to long delays. Signed-off-by: Vasily Averin diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e132c8a..d984bce 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -76,6 +76,8 @@ static unsigned int nf_conntrack_next_id; DEFINE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat); EXPORT_PER_CPU_SYMBOL(nf_conntrack_stat); +#define NF_CT_PER_BUCKET 8U + /* * This scheme offers various size of "struct nf_conn" dependent on * features(helper, nat, ...) @@ -525,7 +527,7 @@ EXPORT_SYMBOL_GPL(nf_conntrack_tuple_taken); /* There's a small race here where we may free a just-assured connection. Too bad: we're in trouble anyway. */ -static int early_drop(struct list_head *chain) +static int __early_drop(struct list_head *chain, unsigned int *cnt) { /* Traverse backwards: gives us oldest, which is roughly LRU */ struct nf_conntrack_tuple_hash *h; @@ -540,6 +542,8 @@ static int early_drop(struct list_head *chain) atomic_inc(&ct->ct_general.use); break; } + if (!--(*cnt)) + break; } read_unlock_bh(&nf_conntrack_lock); @@ -555,6 +559,21 @@ static int early_drop(struct list_head *chain) return dropped; } +static int early_drop(const struct nf_conntrack_tuple *orig) +{ + unsigned int i, hash, cnt; + int ret = 0; + + hash = hash_conntrack(orig); + cnt = NF_CT_PER_BUCKET; + + for (i = 0; + !ret && cnt && i < nf_conntrack_htable_size; + ++i, hash = ++hash % nf_conntrack_htable_size) + ret = __early_drop(&nf_conntrack_hash[hash], &cnt); + return ret; +} + static struct nf_conn * __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, const struct nf_conntrack_tuple *repl, @@ -574,9 +593,7 @@ __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig, if (nf_conntrack_max && atomic_read(&nf_conntrack_count) > nf_conntrack_max) { - unsigned int hash = hash_conntrack(orig); - /* Try dropping from this hash chain. */ - if (!early_drop(&nf_conntrack_hash[hash])) { + if (!early_drop(orig)) { atomic_dec(&nf_conntrack_count); if (net_ratelimit()) printk(KERN_WARNING @@ -1226,7 +1243,7 @@ int __init nf_conntrack_init(void) if (nf_conntrack_htable_size < 16) nf_conntrack_htable_size = 16; } - nf_conntrack_max = 8 * nf_conntrack_htable_size; + nf_conntrack_max = NF_CT_PER_BUCKET * nf_conntrack_htable_size; printk("nf_conntrack version %s (%u buckets, %d max)\n", NF_CONNTRACK_VERSION, nf_conntrack_htable_size, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From jengelh at linux01.gwdg.de Thu May 10 08:27:42 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Thu May 10 09:28:52 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue Message-ID: Hi, the following command gives an error: iptables -t mangle -I FORWARD -m conntrack --ctstate NEW output is: iptables: Unknown error 4294967295 As mentioned in the topic, I suspect it is due to 32-bit iptables not coping correctly with the 64-bit kernel (sometimes, patches to fix these are posted, so I thought it could be related). OS is Aurora Linux 2.98, with their latest(?) kernel 2.6.20-1.2986.al3.3smp. Jan -- From jengelh at linux01.gwdg.de Thu May 10 08:34:07 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Thu May 10 09:35:22 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue In-Reply-To: References: Message-ID: On May 10 2007 08:27, Jan Engelhardt wrote: >Hi, > > >the following command gives an error: > > iptables -t mangle -I FORWARD -m conntrack --ctstate NEW > >output is: > > iptables: Unknown error 4294967295 > >As mentioned in the topic, I suspect it is due to 32-bit iptables not >coping correctly with the 64-bit kernel (sometimes, patches to fix these >are posted, so I thought it could be related). OS is Aurora Linux 2.98, >with their latest(?) kernel 2.6.20-1.2986.al3.3smp. And the following cmd oopsed it: # iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j sshcheck; Output: Unable to handle kernel NULL pointer dereference tsk->{mm,active_mm}->context = 000000000000078d tsk->{mm,active_mm}->pgd = fffff80055a48000 \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ iptables(9865): Oops [#1] TSTATE: 0000009911009606 TPC: 000000000052853c TNPC: 0000000000528540 Y: 00000000 Not tainted TPC: g0: fffff8001fdf4000 g1: 000000001029a340 g2: 00000000000000c8 g3: 0000000000000000 g4: fffff8007fbe6f00 g5: fffff80000e80000 g6: fffff8001fdf4000 g7: 0000000000000005 o0: 0000000000000001 o1: 0000000000000010 o2: 0000000010284810 o3: 0000000000000050 o4: 0000000000000048 o5: 0000000000000640 sp: fffff8001fdf70a1 ret_pc: 000000001029a350 RPC: l0: 000000001028f000 l1: 0000000000000000 l2: 0000000000000040 l3: 0000000000000000 l4: 0000000000030bbc l5: 000000000002f690 l6: 0000000000031600 l7: 000000000002ca50 i0: 0000000000000000 i1: 000000001029d400 i2: 0000000010284800 i3: fffff8001a0fb4a0 i4: 0000000000000002 i5: 0000000000000006 i6: fffff8001fdf7161 i7: 000000001022a2a8 I7: Caller[000000001022a2a8]: compat_do_ipt_set_ctl+0x7d4/0xa04 [ip_tables] Caller[00000000006155b4]: compat_nf_sockopt+0x130/0x16c Caller[0000000000615628]: compat_nf_setsockopt+0x24/0x30 Caller[0000000000623e74]: compat_ip_setsockopt+0xac/0xc0 Caller[00000000005f10e4]: compat_sock_common_setsockopt+0x48/0x54 Caller[0000000000609ba0]: compat_sys_setsockopt+0x4b4/0x4ec Caller[0000000000406c14]: linux_sparc_syscall32+0x3c/0x40 Caller[0000000000019340]: 0x19348 Instruction DUMP: 81c3e008 01000000 8143e003 8e204008 cfe25001 80a04007 1247fffc 8e21c008 Jan -- From davem at davemloft.net Thu May 10 09:16:43 2007 From: davem at davemloft.net (David Miller) Date: Thu May 10 10:17:36 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue In-Reply-To: References: Message-ID: <20070510.001643.75191263.davem@davemloft.net> From: Jan Engelhardt Date: Thu, 10 May 2007 08:34:07 +0200 (MEST) > Unable to handle kernel NULL pointer dereference > tsk->{mm,active_mm}->context = 000000000000078d > tsk->{mm,active_mm}->pgd = fffff80055a48000 > \|/ ____ \|/ > "@'/ .. \`@" > /_| \__/ |_\ > \__U_/ > iptables(9865): Oops [#1] > TSTATE: 0000009911009606 TPC: 000000000052853c TNPC: 0000000000528540 Y: > 00000000 Not tainted > TPC: > g0: fffff8001fdf4000 g1: 000000001029a340 > g2: 00000000000000c8 g3: 0000000000000000 > g4: fffff8007fbe6f00 g5: fffff80000e80000 > g6: fffff8001fdf4000 g7: 0000000000000005 > o0: 0000000000000001 o1: 0000000000000010 > o2: 0000000010284810 o3: 0000000000000050 > o4: 0000000000000048 o5: 0000000000000640 > sp: fffff8001fdf70a1 ret_pc: 000000001029a350 > RPC: in hashlimit_destroy(), r->hinfo is NULL, and this NULL pointer is being passed to atomic_sub_ret() via htable_put()'s if (atomic_dec_and_test(&hinfo->use)) call. It would be interesting if the current 2.6.21 vanilla kernel gives you the same problem, please built that and retest because I believe some compat issues were fixed between 2.6.20 and 2.6.21 Thanks. From frozenspot at gmail.com Wed May 9 00:52:23 2007 From: frozenspot at gmail.com (fender) Date: Thu May 10 14:20:59 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <20070508220714.GA23200@outback.rfc2324.org> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> <20070508220714.GA23200@outback.rfc2324.org> Message-ID: <7e36c7130705081552k6b82df38p52e085ab41c9edaa@mail.gmail.com> On 5/8/07, Maximilian Wilhelm wrote: > On Tuesday, May 8th fender wrote: > > > This is the link: > > > http://portknocko.berlios.de/pom-ng/ > > | Forbidden > | You don't have permission to access /pom-ng/pknock-0.3.tar.gz on this server. > Thanks Max. I'm sorry, the berlios repository doesn't allow me to put external links. I will try with another server and I will send you the link to the tarball. Regards, -- J. Federico Hernandez From kaber at trash.net Thu May 10 14:34:00 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 15:36:16 2007 Subject: [RFC][PATCH 0/7]: ct_extend In-Reply-To: <200705091105.l49B5DTu023689@toshiba.co.jp> References: <200705071200.l47C0UoM006287@toshiba.co.jp> <46404700.40609@trash.net> <200705091105.l49B5DTu023689@toshiba.co.jp> Message-ID: <46431138.2080805@trash.net> Yasuyuki KOZAKAI wrote: > From: Patrick McHardy > Date: Tue, 08 May 2007 11:46:40 +0200 > >>This will add quite some overhead since at least nfct_help is looked at >>for every packet (we might avoid this using a status flag though). >>I'm guessing the locks are needed to protect against concurrent >>reallocations. Maybe we can avoid this by adding the limitation that >>only unconfirmed entries may add new extensions? > > > It sounds good to avoid competition of 2 packet processing. I think > that the remain is nfctnetlink. It can assign helper to a confirmed > conntrack. Do you think that it's enough to assume that it disables bh ? No, that would only help for the CPU its running on. But so far we only allow to change helpers, not assign completely new ones, so no reallocation is needed. I'm wondering if this behaviour is correct though .. From kaber at trash.net Thu May 10 14:58:24 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:00:32 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue In-Reply-To: References: Message-ID: <464316F0.60709@trash.net> Jan Engelhardt wrote: > Hi, > > > the following command gives an error: > > iptables -t mangle -I FORWARD -m conntrack --ctstate NEW > > output is: > > iptables: Unknown error 4294967295 > > As mentioned in the topic, I suspect it is due to 32-bit iptables not > coping correctly with the 64-bit kernel (sometimes, patches to fix these > are posted, so I thought it could be related). OS is Aurora Linux 2.98, > with their latest(?) kernel 2.6.20-1.2986.al3.3smp. The conntrack match is missing compat support, I've queued this patch to fix it. -------------- next part -------------- [NETFILTER]: xt_conntrack: add compat support Signed-off-by: Patrick McHardy --- commit ba8991494e1522be10d764b174fc4e3744c99655 tree 85d5cf3861566aa38ecb2e091be987ecfeb17655 parent 1797736897a68f556aef76a6a0963c3e8b1b4950 author Patrick McHardy Thu, 10 May 2007 14:57:40 +0200 committer Patrick McHardy Thu, 10 May 2007 14:57:40 +0200 net/netfilter/xt_conntrack.c | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 54 insertions(+), 0 deletions(-) diff --git a/net/netfilter/xt_conntrack.c b/net/netfilter/xt_conntrack.c index f4ea8fe..189ded5 100644 --- a/net/netfilter/xt_conntrack.c +++ b/net/netfilter/xt_conntrack.c @@ -134,12 +134,66 @@ static void destroy(const struct xt_match *match, void *matchinfo) nf_ct_l3proto_module_put(match->family); } +#ifdef CONFIG_COMPAT +struct compat_xt_conntrack_info +{ + compat_uint_t statemask; + compat_uint_t statusmask; + struct ip_conntrack_old_tuple tuple[IP_CT_DIR_MAX]; + struct in_addr sipmsk[IP_CT_DIR_MAX]; + struct in_addr dipmsk[IP_CT_DIR_MAX]; + compat_ulong_t expires_min; + compat_ulong_t expires_max; + u_int8_t flags; + u_int8_t invflags; +}; + +static void compat_from_user(void *dst, void *src) +{ + struct compat_xt_conntrack_info *cm = src; + struct xt_conntrack_info m = { + .statemask = cm->statemask, + .statusmask = cm->statusmask, + .expires_min = cm->expires_min, + .expires_max = cm->expires_max, + .flags = cm->flags, + .invflags = cm->invflags, + }; + memcpy(m.tuple, cm->tuple, sizeof(m.tuple)); + memcpy(m.sipmsk, cm->sipmsk, sizeof(m.sipmsk)); + memcpy(m.dipmsk, cm->dipmsk, sizeof(m.dipmsk)); + memcpy(dst, &m, sizeof(m)); +} + +static int compat_to_user(void __user *dst, void *src) +{ + struct xt_conntrack_info *m = src; + struct compat_xt_conntrack_info cm = { + .statemask = m->statemask, + .statusmask = m->statusmask, + .expires_min = m->expires_min, + .expires_max = m->expires_max, + .flags = m->flags, + .invflags = m->invflags, + }; + memcpy(cm.tuple, m->tuple, sizeof(cm.tuple)); + memcpy(cm.sipmsk, m->sipmsk, sizeof(cm.sipmsk)); + memcpy(cm.dipmsk, m->dipmsk, sizeof(cm.dipmsk)); + return copy_to_user(dst, &cm, sizeof(cm)) ? -EFAULT : 0; +} +#endif + static struct xt_match conntrack_match = { .name = "conntrack", .match = match, .checkentry = checkentry, .destroy = destroy, .matchsize = sizeof(struct xt_conntrack_info), +#ifdef CONFIG_COMPAT + .compatsize = sizeof(struct compat_xt_conntrack_info), + .compat_from_user = compat_from_user, + .compat_to_user = compat_to_user, +#endif .family = AF_INET, .me = THIS_MODULE, }; From kaber at trash.net Thu May 10 15:20:13 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:22:18 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue In-Reply-To: References: Message-ID: <46431C0D.5080507@trash.net> Jan Engelhardt wrote: > On May 10 2007 08:27, Jan Engelhardt wrote: > >>As mentioned in the topic, I suspect it is due to 32-bit iptables not >>coping correctly with the 64-bit kernel (sometimes, patches to fix these >>are posted, so I thought it could be related). OS is Aurora Linux 2.98, >>with their latest(?) kernel 2.6.20-1.2986.al3.3smp. > > > And the following cmd oopsed it: > > # iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW > -j sshcheck; I believe this is a bug in the compat code, which *seems* to call (its a bit messy, I just had a quick look) the destroy function without having called checkentry previously when something goes wrong. Which commands did you run before this? From jengelh at linux01.gwdg.de Thu May 10 15:24:45 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Thu May 10 16:26:24 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue In-Reply-To: <46431C0D.5080507@trash.net> References: <46431C0D.5080507@trash.net> Message-ID: On May 10 2007 15:20, Patrick McHardy wrote: >> >> And the following cmd oopsed it: >> >> # iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW >> -j sshcheck; > > >I believe this is a bug in the compat code, which *seems* to call (its >a bit messy, I just had a quick look) the destroy function without >having called checkentry previously when something goes wrong. Which >commands did you run before this? A lot ... as far as the filter table and sshcheck is concerned, iptables -N sshcheck; iptables -A sshcheck -m recent --name sshcheck --seconds 60 --update -j DROP; iptables -A sshcheck -m hashlimit --hashlimit-name sshcheck \ --hashlimit-mode srcip --hashlimit 4/min --hashlimit-burst 4 \ -j RETURN; iptables -A sshcheck -m recent --name sshcheck --set -j DROP; Jan -- From kaber at trash.net Thu May 10 15:41:09 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:42:33 2007 Subject: [NETFILTER 00/09]: Netfilter patches Message-ID: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Hi Dave, following are a few netfilter patches, containing some cleanup of nf_conntrack, nf_nat and ip_tables, additionally there are two fixes to clear the private helper area when reassigning helpers and compat support for xt_conntrack. Please apply, thanks. include/linux/netfilter/x_tables.h | 8 + include/linux/netfilter_arp/arp_tables.h | 41 +++++++ include/linux/netfilter_ipv4/ip_tables.h | 22 ++++ include/linux/netfilter_ipv6/ip6_tables.h | 22 ++++ include/net/netfilter/nf_conntrack.h | 7 - include/net/netfilter/nf_conntrack_l3proto.h | 3 include/net/netfilter/nf_nat_rule.h | 11 -- net/ipv4/netfilter/arptable_filter.c | 140 ++++----------------------- net/ipv4/netfilter/iptable_filter.c | 73 ++++---------- net/ipv4/netfilter/iptable_mangle.c | 99 +++++-------------- net/ipv4/netfilter/iptable_raw.c | 78 +++++---------- net/ipv4/netfilter/nf_nat_rule.c | 86 ++-------------- net/ipv4/netfilter/nf_nat_standalone.c | 11 -- net/ipv6/netfilter/ip6table_filter.c | 70 ++++--------- net/ipv6/netfilter/ip6table_mangle.c | 96 +++++------------- net/ipv6/netfilter/ip6table_raw.c | 52 ---------- net/netfilter/nf_conntrack_core.c | 14 +- net/netfilter/nf_conntrack_netlink.c | 40 ++++--- net/netfilter/xt_conntrack.c | 54 ++++++++++ 19 files changed, 354 insertions(+), 573 deletions(-) Patrick McHardy (4): [NETFILTER]: Clean up table initialization [NETFILTER]: iptable_{filter,mangle}: more descriptive "happy cracking" message [NETFILTER]: iptable_raw: ignore short packets sent by SOCK_RAW sockets [NETFILTER]: xt_conntrack: add compat support Yasuyuki Kozakai (5): [NETFILTER]: nf_nat: remove unused argument of function allocating binding [NETFILTER]: nf_conntrack: Removes duplicated declarations [NETFILTER]: nf_conntrack: Removes unused destroy operation of l3proto [NETFILTER]: ctnetlink: clear helper area and handle unchanged helper [NETFILTER]: nf_nat: Clears helper private area when NATing From kaber at trash.net Thu May 10 15:41:12 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:42:40 2007 Subject: [NETFILTER 02/09]: nf_nat: remove unused argument of function allocating binding In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134030.8559.58054.sendpatchset@localhost.localdomain> [NETFILTER]: nf_nat: remove unused argument of function allocating binding nf_nat_rule_find, alloc_null_binding and alloc_null_binding_confirmed do not use the argument 'info', which is actually ct->nat.info. If they are necessary to access it again, we can use the argument 'ct' instead. Signed-off-by: Yasuyuki Kozakai Signed-off-by: Patrick McHardy --- commit f1103257fddbe3a55b4ae964741cefb5026c20ec tree 32d30851ebdb14a2dfc5b7b10267b9700cf010d5 parent acf2e14c5f3ff9b9ad1500c135a8d9be98d66436 author Yasuyuki Kozakai Tue, 08 May 2007 11:06:17 +0200 committer Patrick McHardy Tue, 08 May 2007 11:06:17 +0200 include/net/netfilter/nf_nat_rule.h | 11 +++-------- net/ipv4/netfilter/nf_nat_rule.c | 13 ++++--------- net/ipv4/netfilter/nf_nat_standalone.c | 11 +++-------- 3 files changed, 10 insertions(+), 25 deletions(-) diff --git a/include/net/netfilter/nf_nat_rule.h b/include/net/netfilter/nf_nat_rule.h index e765654..f974318 100644 --- a/include/net/netfilter/nf_nat_rule.h +++ b/include/net/netfilter/nf_nat_rule.h @@ -10,16 +10,11 @@ extern int nf_nat_rule_find(struct sk_buff **pskb, unsigned int hooknum, const struct net_device *in, const struct net_device *out, - struct nf_conn *ct, - struct nf_nat_info *info); + struct nf_conn *ct); extern unsigned int -alloc_null_binding(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum); +alloc_null_binding(struct nf_conn *ct, unsigned int hooknum); extern unsigned int -alloc_null_binding_confirmed(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum); +alloc_null_binding_confirmed(struct nf_conn *ct, unsigned int hooknum); #endif /* _NF_NAT_RULE_H */ diff --git a/net/ipv4/netfilter/nf_nat_rule.c b/net/ipv4/netfilter/nf_nat_rule.c index 07e99e3..6740736 100644 --- a/net/ipv4/netfilter/nf_nat_rule.c +++ b/net/ipv4/netfilter/nf_nat_rule.c @@ -173,9 +173,7 @@ static int ipt_dnat_checkentry(const char *tablename, } inline unsigned int -alloc_null_binding(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum) +alloc_null_binding(struct nf_conn *ct, unsigned int hooknum) { /* Force range to this IP; let proto decide mapping for per-proto parts (hence not IP_NAT_RANGE_PROTO_SPECIFIED). @@ -194,9 +192,7 @@ alloc_null_binding(struct nf_conn *ct, } unsigned int -alloc_null_binding_confirmed(struct nf_conn *ct, - struct nf_nat_info *info, - unsigned int hooknum) +alloc_null_binding_confirmed(struct nf_conn *ct, unsigned int hooknum) { __be32 ip = (HOOK2MANIP(hooknum) == IP_NAT_MANIP_SRC @@ -218,8 +214,7 @@ int nf_nat_rule_find(struct sk_buff **pskb, unsigned int hooknum, const struct net_device *in, const struct net_device *out, - struct nf_conn *ct, - struct nf_nat_info *info) + struct nf_conn *ct) { int ret; @@ -228,7 +223,7 @@ int nf_nat_rule_find(struct sk_buff **pskb, if (ret == NF_ACCEPT) { if (!nf_nat_initialized(ct, HOOK2MANIP(hooknum))) /* NUL mapping */ - ret = alloc_null_binding(ct, info, hooknum); + ret = alloc_null_binding(ct, hooknum); } return ret; } diff --git a/net/ipv4/netfilter/nf_nat_standalone.c b/net/ipv4/netfilter/nf_nat_standalone.c index 64bbed2..55dac36 100644 --- a/net/ipv4/netfilter/nf_nat_standalone.c +++ b/net/ipv4/netfilter/nf_nat_standalone.c @@ -80,7 +80,6 @@ nf_nat_fn(unsigned int hooknum, struct nf_conn *ct; enum ip_conntrack_info ctinfo; struct nf_conn_nat *nat; - struct nf_nat_info *info; /* maniptype == SRC for postrouting. */ enum nf_nat_manip_type maniptype = HOOK2MANIP(hooknum); @@ -129,7 +128,6 @@ nf_nat_fn(unsigned int hooknum, } /* Fall thru... (Only ICMPs can be IP_CT_IS_REPLY) */ case IP_CT_NEW: - info = &nat->info; /* Seen it before? This can happen for loopback, retrans, or local packets.. */ @@ -138,14 +136,13 @@ nf_nat_fn(unsigned int hooknum, if (unlikely(nf_ct_is_confirmed(ct))) /* NAT module was loaded late */ - ret = alloc_null_binding_confirmed(ct, info, - hooknum); + ret = alloc_null_binding_confirmed(ct, hooknum); else if (hooknum == NF_IP_LOCAL_IN) /* LOCAL_IN hook doesn't have a chain! */ - ret = alloc_null_binding(ct, info, hooknum); + ret = alloc_null_binding(ct, hooknum); else ret = nf_nat_rule_find(pskb, hooknum, in, out, - ct, info); + ct); if (ret != NF_ACCEPT) { return ret; @@ -160,10 +157,8 @@ nf_nat_fn(unsigned int hooknum, /* ESTABLISHED */ NF_CT_ASSERT(ctinfo == IP_CT_ESTABLISHED || ctinfo == (IP_CT_ESTABLISHED+IP_CT_IS_REPLY)); - info = &nat->info; } - NF_CT_ASSERT(info); return nf_nat_packet(ct, ctinfo, hooknum, pskb); } From kaber at trash.net Thu May 10 15:41:11 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:42:41 2007 Subject: [NETFILTER 01/09]: Clean up table initialization In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134028.8559.53451.sendpatchset@localhost.localdomain> [NETFILTER]: Clean up table initialization - move arp_tables initial table structure definitions to arp_tables.h similar to ip_tables and ip6_tables - use C99 initializers - use initializer macros where possible Signed-off-by: Patrick McHardy --- commit acf2e14c5f3ff9b9ad1500c135a8d9be98d66436 tree c3d814e7e64652f2ec2541e174b9a210ac1f2459 parent a989705c4cf6e6c1a339c95f9daf658b4ba88ca8 author Patrick McHardy Tue, 08 May 2007 11:06:17 +0200 committer Patrick McHardy Tue, 08 May 2007 11:06:17 +0200 include/linux/netfilter/x_tables.h | 8 ++ include/linux/netfilter_arp/arp_tables.h | 41 ++++++++ include/linux/netfilter_ipv4/ip_tables.h | 22 +++++ include/linux/netfilter_ipv6/ip6_tables.h | 22 +++++ net/ipv4/netfilter/arptable_filter.c | 140 +++++------------------------ net/ipv4/netfilter/iptable_filter.c | 70 +++++---------- net/ipv4/netfilter/iptable_mangle.c | 96 ++++++-------------- net/ipv4/netfilter/iptable_raw.c | 58 +----------- net/ipv4/netfilter/nf_nat_rule.c | 73 ++------------- net/ipv6/netfilter/ip6table_filter.c | 70 +++++---------- net/ipv6/netfilter/ip6table_mangle.c | 96 ++++++-------------- net/ipv6/netfilter/ip6table_raw.c | 52 +---------- 12 files changed, 238 insertions(+), 510 deletions(-) diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h index 022edfa..7e733a6 100644 --- a/include/linux/netfilter/x_tables.h +++ b/include/linux/netfilter/x_tables.h @@ -54,6 +54,14 @@ struct xt_entry_target unsigned char data[0]; }; +#define XT_TARGET_INIT(__name, __size) \ +{ \ + .target.u.user = { \ + .target_size = XT_ALIGN(__size), \ + .name = __name, \ + }, \ +} + struct xt_standard_target { struct xt_entry_target target; diff --git a/include/linux/netfilter_arp/arp_tables.h b/include/linux/netfilter_arp/arp_tables.h index 24c8786..584cd1b 100644 --- a/include/linux/netfilter_arp/arp_tables.h +++ b/include/linux/netfilter_arp/arp_tables.h @@ -238,6 +238,47 @@ static __inline__ struct arpt_entry_target *arpt_get_target(struct arpt_entry *e */ #ifdef __KERNEL__ +/* Standard entry. */ +struct arpt_standard +{ + struct arpt_entry entry; + struct arpt_standard_target target; +}; + +struct arpt_error_target +{ + struct arpt_entry_target target; + char errorname[ARPT_FUNCTION_MAXNAMELEN]; +}; + +struct arpt_error +{ + struct arpt_entry entry; + struct arpt_error_target target; +}; + +#define ARPT_ENTRY_INIT(__size) \ +{ \ + .target_offset = sizeof(struct arpt_entry), \ + .next_offset = (__size), \ +} + +#define ARPT_STANDARD_INIT(__verdict) \ +{ \ + .entry = ARPT_ENTRY_INIT(sizeof(struct arpt_standard)), \ + .target = XT_TARGET_INIT(ARPT_STANDARD_TARGET, \ + sizeof(struct arpt_standard_target)), \ + .target.verdict = -(__verdict) - 1, \ +} + +#define ARPT_ERROR_INIT \ +{ \ + .entry = ARPT_ENTRY_INIT(sizeof(struct arpt_error)), \ + .target = XT_TARGET_INIT(ARPT_ERROR_TARGET, \ + sizeof(struct arpt_error_target)), \ + .target.errorname = "ERROR", \ +} + #define arpt_register_target(tgt) \ ({ (tgt)->family = NF_ARP; \ xt_register_target(tgt); }) diff --git a/include/linux/netfilter_ipv4/ip_tables.h b/include/linux/netfilter_ipv4/ip_tables.h index 9527296..2f46dd7 100644 --- a/include/linux/netfilter_ipv4/ip_tables.h +++ b/include/linux/netfilter_ipv4/ip_tables.h @@ -295,6 +295,28 @@ struct ipt_error struct ipt_error_target target; }; +#define IPT_ENTRY_INIT(__size) \ +{ \ + .target_offset = sizeof(struct ipt_entry), \ + .next_offset = (__size), \ +} + +#define IPT_STANDARD_INIT(__verdict) \ +{ \ + .entry = IPT_ENTRY_INIT(sizeof(struct ipt_standard)), \ + .target = XT_TARGET_INIT(IPT_STANDARD_TARGET, \ + sizeof(struct xt_standard_target)), \ + .target.verdict = -(__verdict) - 1, \ +} + +#define IPT_ERROR_INIT \ +{ \ + .entry = IPT_ENTRY_INIT(sizeof(struct ipt_error)), \ + .target = XT_TARGET_INIT(IPT_ERROR_TARGET, \ + sizeof(struct ipt_error_target)), \ + .target.errorname = "ERROR", \ +} + extern unsigned int ipt_do_table(struct sk_buff **pskb, unsigned int hook, const struct net_device *in, diff --git a/include/linux/netfilter_ipv6/ip6_tables.h b/include/linux/netfilter_ipv6/ip6_tables.h index 61aa104..4686f83 100644 --- a/include/linux/netfilter_ipv6/ip6_tables.h +++ b/include/linux/netfilter_ipv6/ip6_tables.h @@ -123,6 +123,28 @@ struct ip6t_error struct ip6t_error_target target; }; +#define IP6T_ENTRY_INIT(__size) \ +{ \ + .target_offset = sizeof(struct ip6t_entry), \ + .next_offset = (__size), \ +} + +#define IP6T_STANDARD_INIT(__verdict) \ +{ \ + .entry = IP6T_ENTRY_INIT(sizeof(struct ip6t_standard)), \ + .target = XT_TARGET_INIT(IP6T_STANDARD_TARGET, \ + sizeof(struct ip6t_standard_target)), \ + .target.verdict = -(__verdict) - 1, \ +} + +#define IP6T_ERROR_INIT \ +{ \ + .entry = IP6T_ENTRY_INIT(sizeof(struct ip6t_error)), \ + .target = XT_TARGET_INIT(IP6T_ERROR_TARGET, \ + sizeof(struct ip6t_error_target)), \ + .target.errorname = "ERROR", \ +} + /* * New IP firewall options for [gs]etsockopt at the RAW IP level. * Unlike BSD Linux inherits IP options so you don't have to use diff --git a/net/ipv4/netfilter/arptable_filter.c b/net/ipv4/netfilter/arptable_filter.c index 7edea2a..75c0230 100644 --- a/net/ipv4/netfilter/arptable_filter.c +++ b/net/ipv4/netfilter/arptable_filter.c @@ -15,128 +15,34 @@ MODULE_DESCRIPTION("arptables filter table"); #define FILTER_VALID_HOOKS ((1 << NF_ARP_IN) | (1 << NF_ARP_OUT) | \ (1 << NF_ARP_FORWARD)) -/* Standard entry. */ -struct arpt_standard -{ - struct arpt_entry entry; - struct arpt_standard_target target; -}; - -struct arpt_error_target -{ - struct arpt_entry_target target; - char errorname[ARPT_FUNCTION_MAXNAMELEN]; -}; - -struct arpt_error -{ - struct arpt_entry entry; - struct arpt_error_target target; -}; - static struct { struct arpt_replace repl; struct arpt_standard entries[3]; struct arpt_error term; -} initial_table __initdata -= { { "filter", FILTER_VALID_HOOKS, 4, - sizeof(struct arpt_standard) * 3 + sizeof(struct arpt_error), - { [NF_ARP_IN] = 0, - [NF_ARP_OUT] = sizeof(struct arpt_standard), - [NF_ARP_FORWARD] = 2 * sizeof(struct arpt_standard), }, - { [NF_ARP_IN] = 0, - [NF_ARP_OUT] = sizeof(struct arpt_standard), - [NF_ARP_FORWARD] = 2 * sizeof(struct arpt_standard), }, - 0, NULL, { } }, - { - /* ARP_IN */ - { - { - { - { 0 }, { 0 }, { 0 }, { 0 }, - 0, 0, - { { 0, }, { 0, } }, - { { 0, }, { 0, } }, - 0, 0, - 0, 0, - 0, 0, - "", "", { 0 }, { 0 }, - 0, 0 - }, - sizeof(struct arpt_entry), - sizeof(struct arpt_standard), - 0, - { 0, 0 }, { } }, - { { { { ARPT_ALIGN(sizeof(struct arpt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } - }, - /* ARP_OUT */ - { - { - { - { 0 }, { 0 }, { 0 }, { 0 }, - 0, 0, - { { 0, }, { 0, } }, - { { 0, }, { 0, } }, - 0, 0, - 0, 0, - 0, 0, - "", "", { 0 }, { 0 }, - 0, 0 - }, - sizeof(struct arpt_entry), - sizeof(struct arpt_standard), - 0, - { 0, 0 }, { } }, - { { { { ARPT_ALIGN(sizeof(struct arpt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } - }, - /* ARP_FORWARD */ - { - { - { - { 0 }, { 0 }, { 0 }, { 0 }, - 0, 0, - { { 0, }, { 0, } }, - { { 0, }, { 0, } }, - 0, 0, - 0, 0, - 0, 0, - "", "", { 0 }, { 0 }, - 0, 0 - }, - sizeof(struct arpt_entry), - sizeof(struct arpt_standard), - 0, - { 0, 0 }, { } }, - { { { { ARPT_ALIGN(sizeof(struct arpt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } - } - }, - /* ERROR */ - { - { - { - { 0 }, { 0 }, { 0 }, { 0 }, - 0, 0, - { { 0, }, { 0, } }, - { { 0, }, { 0, } }, - 0, 0, - 0, 0, - 0, 0, - "", "", { 0 }, { 0 }, - 0, 0 - }, - sizeof(struct arpt_entry), - sizeof(struct arpt_error), - 0, - { 0, 0 }, { } }, - { { { { ARPT_ALIGN(sizeof(struct arpt_error_target)), ARPT_ERROR_TARGET } }, - { } }, - "ERROR" - } - } +} initial_table __initdata = { + .repl = { + .name = "filter", + .valid_hooks = FILTER_VALID_HOOKS, + .num_entries = 4, + .size = sizeof(struct arpt_standard) * 3 + sizeof(struct arpt_error), + .hook_entry = { + [NF_ARP_IN] = 0, + [NF_ARP_OUT] = sizeof(struct arpt_standard), + [NF_ARP_FORWARD] = 2 * sizeof(struct arpt_standard), + }, + .underflow = { + [NF_ARP_IN] = 0, + [NF_ARP_OUT] = sizeof(struct arpt_standard), + [NF_ARP_FORWARD] = 2 * sizeof(struct arpt_standard), + }, + }, + .entries = { + ARPT_STANDARD_INIT(NF_ACCEPT), /* ARP_IN */ + ARPT_STANDARD_INIT(NF_ACCEPT), /* ARP_OUT */ + ARPT_STANDARD_INIT(NF_ACCEPT), /* ARP_FORWARD */ + }, + .term = ARPT_ERROR_INIT, }; static struct arpt_table packet_filter = { diff --git a/net/ipv4/netfilter/iptable_filter.c b/net/ipv4/netfilter/iptable_filter.c index 4272890..ea14979 100644 --- a/net/ipv4/netfilter/iptable_filter.c +++ b/net/ipv4/netfilter/iptable_filter.c @@ -26,53 +26,29 @@ static struct struct ipt_replace repl; struct ipt_standard entries[3]; struct ipt_error term; -} initial_table __initdata -= { { "filter", FILTER_VALID_HOOKS, 4, - sizeof(struct ipt_standard) * 3 + sizeof(struct ipt_error), - { [NF_IP_LOCAL_IN] = 0, - [NF_IP_FORWARD] = sizeof(struct ipt_standard), - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2 }, - { [NF_IP_LOCAL_IN] = 0, - [NF_IP_FORWARD] = sizeof(struct ipt_standard), - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2 }, - 0, NULL, { } }, - { - /* LOCAL_IN */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* FORWARD */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* LOCAL_OUT */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } } - }, - /* ERROR */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_error), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_error_target)), IPT_ERROR_TARGET } }, - { } }, - "ERROR" - } - } +} initial_table __initdata = { + .repl = { + .name = "filter", + .valid_hooks = FILTER_VALID_HOOKS, + .num_entries = 4, + .size = sizeof(struct ipt_standard) * 3 + sizeof(struct ipt_error), + .hook_entry = { + [NF_IP_LOCAL_IN] = 0, + [NF_IP_FORWARD] = sizeof(struct ipt_standard), + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2, + }, + .underflow = { + [NF_IP_LOCAL_IN] = 0, + [NF_IP_FORWARD] = sizeof(struct ipt_standard), + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2, + }, + }, + .entries = { + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_IN */ + IPT_STANDARD_INIT(NF_ACCEPT), /* FORWARD */ + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ + }, + .term = IPT_ERROR_INIT, /* ERROR */ }; static struct xt_table packet_filter = { diff --git a/net/ipv4/netfilter/iptable_mangle.c b/net/ipv4/netfilter/iptable_mangle.c index 9278802..c3827ba 100644 --- a/net/ipv4/netfilter/iptable_mangle.c +++ b/net/ipv4/netfilter/iptable_mangle.c @@ -33,73 +33,35 @@ static struct struct ipt_replace repl; struct ipt_standard entries[5]; struct ipt_error term; -} initial_table __initdata -= { { "mangle", MANGLE_VALID_HOOKS, 6, - sizeof(struct ipt_standard) * 5 + sizeof(struct ipt_error), - { [NF_IP_PRE_ROUTING] = 0, - [NF_IP_LOCAL_IN] = sizeof(struct ipt_standard), - [NF_IP_FORWARD] = sizeof(struct ipt_standard) * 2, - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 3, - [NF_IP_POST_ROUTING] = sizeof(struct ipt_standard) * 4 }, - { [NF_IP_PRE_ROUTING] = 0, - [NF_IP_LOCAL_IN] = sizeof(struct ipt_standard), - [NF_IP_FORWARD] = sizeof(struct ipt_standard) * 2, - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 3, - [NF_IP_POST_ROUTING] = sizeof(struct ipt_standard) * 4 }, - 0, NULL, { } }, - { - /* PRE_ROUTING */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* LOCAL_IN */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* FORWARD */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* LOCAL_OUT */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* POST_ROUTING */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_standard), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - }, - /* ERROR */ - { { { { 0 }, { 0 }, { 0 }, { 0 }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ipt_entry), - sizeof(struct ipt_error), - 0, { 0, 0 }, { } }, - { { { { IPT_ALIGN(sizeof(struct ipt_error_target)), IPT_ERROR_TARGET } }, - { } }, - "ERROR" - } - } +} initial_table __initdata = { + .repl = { + .name = "mangle", + .valid_hooks = MANGLE_VALID_HOOKS, + .num_entries = 6, + .size = sizeof(struct ipt_standard) * 5 + sizeof(struct ipt_error), + .hook_entry = { + [NF_IP_PRE_ROUTING] = 0, + [NF_IP_LOCAL_IN] = sizeof(struct ipt_standard), + [NF_IP_FORWARD] = sizeof(struct ipt_standard) * 2, + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 3, + [NF_IP_POST_ROUTING] = sizeof(struct ipt_standard) * 4, + }, + .underflow = { + [NF_IP_PRE_ROUTING] = 0, + [NF_IP_LOCAL_IN] = sizeof(struct ipt_standard), + [NF_IP_FORWARD] = sizeof(struct ipt_standard) * 2, + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 3, + [NF_IP_POST_ROUTING] = sizeof(struct ipt_standard) * 4, + }, + }, + .entries = { + IPT_STANDARD_INIT(NF_ACCEPT), /* PRE_ROUTING */ + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_IN */ + IPT_STANDARD_INIT(NF_ACCEPT), /* FORWARD */ + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ + IPT_STANDARD_INIT(NF_ACCEPT), /* POST_ROUTING */ + }, + .term = IPT_ERROR_INIT, /* ERROR */ }; static struct xt_table packet_mangler = { diff --git a/net/ipv4/netfilter/iptable_raw.c b/net/ipv4/netfilter/iptable_raw.c index 18c3d4c..f7d28fd 100644 --- a/net/ipv4/netfilter/iptable_raw.c +++ b/net/ipv4/netfilter/iptable_raw.c @@ -21,62 +21,18 @@ static struct .size = sizeof(struct ipt_standard) * 2 + sizeof(struct ipt_error), .hook_entry = { [NF_IP_PRE_ROUTING] = 0, - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) }, + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) + }, .underflow = { [NF_IP_PRE_ROUTING] = 0, - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) }, + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) + }, }, .entries = { - /* PRE_ROUTING */ - { - .entry = { - .target_offset = sizeof(struct ipt_entry), - .next_offset = sizeof(struct ipt_standard), - }, - .target = { - .target = { - .u = { - .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), - }, - }, - .verdict = -NF_ACCEPT - 1, - }, - }, - - /* LOCAL_OUT */ - { - .entry = { - .target_offset = sizeof(struct ipt_entry), - .next_offset = sizeof(struct ipt_standard), - }, - .target = { - .target = { - .u = { - .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), - }, - }, - .verdict = -NF_ACCEPT - 1, - }, - }, + IPT_STANDARD_INIT(NF_ACCEPT), /* PRE_ROUTING */ + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ }, - /* ERROR */ - .term = { - .entry = { - .target_offset = sizeof(struct ipt_entry), - .next_offset = sizeof(struct ipt_error), - }, - .target = { - .target = { - .u = { - .user = { - .target_size = IPT_ALIGN(sizeof(struct ipt_error_target)), - .name = IPT_ERROR_TARGET, - }, - }, - }, - .errorname = "ERROR", - }, - } + .term = IPT_ERROR_INIT, /* ERROR */ }; static struct xt_table packet_raw = { diff --git a/net/ipv4/netfilter/nf_nat_rule.c b/net/ipv4/netfilter/nf_nat_rule.c index 2534f71..07e99e3 100644 --- a/net/ipv4/netfilter/nf_nat_rule.c +++ b/net/ipv4/netfilter/nf_nat_rule.c @@ -46,77 +46,20 @@ static struct .hook_entry = { [NF_IP_PRE_ROUTING] = 0, [NF_IP_POST_ROUTING] = sizeof(struct ipt_standard), - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2 }, + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2 + }, .underflow = { [NF_IP_PRE_ROUTING] = 0, [NF_IP_POST_ROUTING] = sizeof(struct ipt_standard), - [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2 }, + [NF_IP_LOCAL_OUT] = sizeof(struct ipt_standard) * 2 + }, }, .entries = { - /* PRE_ROUTING */ - { - .entry = { - .target_offset = sizeof(struct ipt_entry), - .next_offset = sizeof(struct ipt_standard), - }, - .target = { - .target = { - .u = { - .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), - }, - }, - .verdict = -NF_ACCEPT - 1, - }, - }, - /* POST_ROUTING */ - { - .entry = { - .target_offset = sizeof(struct ipt_entry), - .next_offset = sizeof(struct ipt_standard), - }, - .target = { - .target = { - .u = { - .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), - }, - }, - .verdict = -NF_ACCEPT - 1, - }, - }, - /* LOCAL_OUT */ - { - .entry = { - .target_offset = sizeof(struct ipt_entry), - .next_offset = sizeof(struct ipt_standard), - }, - .target = { - .target = { - .u = { - .target_size = IPT_ALIGN(sizeof(struct ipt_standard_target)), - }, - }, - .verdict = -NF_ACCEPT - 1, - }, - }, + IPT_STANDARD_INIT(NF_ACCEPT), /* PRE_ROUTING */ + IPT_STANDARD_INIT(NF_ACCEPT), /* POST_ROUTING */ + IPT_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ }, - /* ERROR */ - .term = { - .entry = { - .target_offset = sizeof(struct ipt_entry), - .next_offset = sizeof(struct ipt_error), - }, - .target = { - .target = { - .u = { - .user = { - .target_size = IPT_ALIGN(sizeof(struct ipt_error_target)), - .name = IPT_ERROR_TARGET, - }, - }, - }, - .errorname = "ERROR", - }, - } + .term = IPT_ERROR_INIT, /* ERROR */ }; static struct xt_table nat_table = { diff --git a/net/ipv6/netfilter/ip6table_filter.c b/net/ipv6/netfilter/ip6table_filter.c index 76f0cf6..7e32e2a 100644 --- a/net/ipv6/netfilter/ip6table_filter.c +++ b/net/ipv6/netfilter/ip6table_filter.c @@ -24,53 +24,29 @@ static struct struct ip6t_replace repl; struct ip6t_standard entries[3]; struct ip6t_error term; -} initial_table __initdata -= { { "filter", FILTER_VALID_HOOKS, 4, - sizeof(struct ip6t_standard) * 3 + sizeof(struct ip6t_error), - { [NF_IP6_LOCAL_IN] = 0, - [NF_IP6_FORWARD] = sizeof(struct ip6t_standard), - [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 2 }, - { [NF_IP6_LOCAL_IN] = 0, - [NF_IP6_FORWARD] = sizeof(struct ip6t_standard), - [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 2 }, - 0, NULL, { } }, - { - /* LOCAL_IN */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* FORWARD */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* LOCAL_OUT */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } } - }, - /* ERROR */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_error), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_error_target)), IP6T_ERROR_TARGET } }, - { } }, - "ERROR" - } - } +} initial_table __initdata = { + .repl = { + .name = "filter", + .valid_hooks = FILTER_VALID_HOOKS, + .num_entries = 4, + .size = sizeof(struct ip6t_standard) * 3 + sizeof(struct ip6t_error), + .hook_entry = { + [NF_IP6_LOCAL_IN] = 0, + [NF_IP6_FORWARD] = sizeof(struct ip6t_standard), + [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 2 + }, + .underflow = { + [NF_IP6_LOCAL_IN] = 0, + [NF_IP6_FORWARD] = sizeof(struct ip6t_standard), + [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 2 + }, + }, + .entries = { + IP6T_STANDARD_INIT(NF_ACCEPT), /* LOCAL_IN */ + IP6T_STANDARD_INIT(NF_ACCEPT), /* FORWARD */ + IP6T_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ + }, + .term = IP6T_ERROR_INIT, /* ERROR */ }; static struct xt_table packet_filter = { diff --git a/net/ipv6/netfilter/ip6table_mangle.c b/net/ipv6/netfilter/ip6table_mangle.c index a9f10e3..f2d2649 100644 --- a/net/ipv6/netfilter/ip6table_mangle.c +++ b/net/ipv6/netfilter/ip6table_mangle.c @@ -32,73 +32,35 @@ static struct struct ip6t_replace repl; struct ip6t_standard entries[5]; struct ip6t_error term; -} initial_table __initdata -= { { "mangle", MANGLE_VALID_HOOKS, 6, - sizeof(struct ip6t_standard) * 5 + sizeof(struct ip6t_error), - { [NF_IP6_PRE_ROUTING] = 0, - [NF_IP6_LOCAL_IN] = sizeof(struct ip6t_standard), - [NF_IP6_FORWARD] = sizeof(struct ip6t_standard) * 2, - [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 3, - [NF_IP6_POST_ROUTING] = sizeof(struct ip6t_standard) * 4}, - { [NF_IP6_PRE_ROUTING] = 0, - [NF_IP6_LOCAL_IN] = sizeof(struct ip6t_standard), - [NF_IP6_FORWARD] = sizeof(struct ip6t_standard) * 2, - [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 3, - [NF_IP6_POST_ROUTING] = sizeof(struct ip6t_standard) * 4}, - 0, NULL, { } }, - { - /* PRE_ROUTING */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* LOCAL_IN */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* FORWARD */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* LOCAL_OUT */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } }, - /* POST_ROUTING */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_standard), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_standard_target)), "" } }, { } }, - -NF_ACCEPT - 1 } } - }, - /* ERROR */ - { { { { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, { { { 0 } } }, "", "", { 0 }, { 0 }, 0, 0, 0 }, - 0, - sizeof(struct ip6t_entry), - sizeof(struct ip6t_error), - 0, { 0, 0 }, { } }, - { { { { IP6T_ALIGN(sizeof(struct ip6t_error_target)), IP6T_ERROR_TARGET } }, - { } }, - "ERROR" - } - } +} initial_table __initdata = { + .repl = { + .name = "mangle", + .valid_hooks = MANGLE_VALID_HOOKS, + .num_entries = 6, + .size = sizeof(struct ip6t_standard) * 5 + sizeof(struct ip6t_error), + .hook_entry = { + [NF_IP6_PRE_ROUTING] = 0, + [NF_IP6_LOCAL_IN] = sizeof(struct ip6t_standard), + [NF_IP6_FORWARD] = sizeof(struct ip6t_standard) * 2, + [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 3, + [NF_IP6_POST_ROUTING] = sizeof(struct ip6t_standard) * 4, + }, + .underflow = { + [NF_IP6_PRE_ROUTING] = 0, + [NF_IP6_LOCAL_IN] = sizeof(struct ip6t_standard), + [NF_IP6_FORWARD] = sizeof(struct ip6t_standard) * 2, + [NF_IP6_LOCAL_OUT] = sizeof(struct ip6t_standard) * 3, + [NF_IP6_POST_ROUTING] = sizeof(struct ip6t_standard) * 4, + }, + }, + .entries = { + IP6T_STANDARD_INIT(NF_ACCEPT), /* PRE_ROUTING */ + IP6T_STANDARD_INIT(NF_ACCEPT), /* LOCAL_IN */ + IP6T_STANDARD_INIT(NF_ACCEPT), /* FORWARD */ + IP6T_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ + IP6T_STANDARD_INIT(NF_ACCEPT), /* POST_ROUTING */ + }, + .term = IP6T_ERROR_INIT, /* ERROR */ }; static struct xt_table packet_mangler = { diff --git a/net/ipv6/netfilter/ip6table_raw.c b/net/ipv6/netfilter/ip6table_raw.c index a3eb5b8..0acda45 100644 --- a/net/ipv6/netfilter/ip6table_raw.c +++ b/net/ipv6/netfilter/ip6table_raw.c @@ -35,56 +35,10 @@ static struct }, }, .entries = { - /* PRE_ROUTING */ - { - .entry = { - .target_offset = sizeof(struct ip6t_entry), - .next_offset = sizeof(struct ip6t_standard), - }, - .target = { - .target = { - .u = { - .target_size = IP6T_ALIGN(sizeof(struct ip6t_standard_target)), - }, - }, - .verdict = -NF_ACCEPT - 1, - }, - }, - - /* LOCAL_OUT */ - { - .entry = { - .target_offset = sizeof(struct ip6t_entry), - .next_offset = sizeof(struct ip6t_standard), - }, - .target = { - .target = { - .u = { - .target_size = IP6T_ALIGN(sizeof(struct ip6t_standard_target)), - }, - }, - .verdict = -NF_ACCEPT - 1, - }, - }, + IP6T_STANDARD_INIT(NF_ACCEPT), /* PRE_ROUTING */ + IP6T_STANDARD_INIT(NF_ACCEPT), /* LOCAL_OUT */ }, - /* ERROR */ - .term = { - .entry = { - .target_offset = sizeof(struct ip6t_entry), - .next_offset = sizeof(struct ip6t_error), - }, - .target = { - .target = { - .u = { - .user = { - .target_size = IP6T_ALIGN(sizeof(struct ip6t_error_target)), - .name = IP6T_ERROR_TARGET, - }, - }, - }, - .errorname = "ERROR", - }, - } + .term = IP6T_ERROR_INIT, /* ERROR */ }; static struct xt_table packet_raw = { From kaber at trash.net Thu May 10 15:41:14 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:42:42 2007 Subject: [NETFILTER 03/09]: nf_conntrack: Removes duplicated declarations In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134031.8559.74950.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack: Removes duplicated declarations These are also in include/net/netfilter/nf_conntrack_helper.h Signed-off-by: Yasuyuki Kozakai Signed-off-by: Patrick McHardy --- commit aeca1c226efa93ec47d21303d907d7ab18c30f0e tree f35fccc4722bc6fe48e574e2c2596723bb01b673 parent f1103257fddbe3a55b4ae964741cefb5026c20ec author Yasuyuki Kozakai Tue, 08 May 2007 11:06:18 +0200 committer Patrick McHardy Tue, 08 May 2007 11:06:18 +0200 include/net/netfilter/nf_conntrack.h | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index 1c6b8bd..4732432 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -183,13 +183,6 @@ extern void nf_conntrack_hash_insert(struct nf_conn *ct); extern void nf_conntrack_flush(void); -extern struct nf_conntrack_helper * -nf_ct_helper_find_get( const struct nf_conntrack_tuple *tuple); -extern void nf_ct_helper_put(struct nf_conntrack_helper *helper); - -extern struct nf_conntrack_helper * -__nf_conntrack_helper_find_byname(const char *name); - extern int nf_ct_invert_tuplepr(struct nf_conntrack_tuple *inverse, const struct nf_conntrack_tuple *orig); From kaber at trash.net Thu May 10 15:41:15 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:42:46 2007 Subject: [NETFILTER 04/09]: nf_conntrack: Removes unused destroy operation of l3proto In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134032.8559.22163.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack: Removes unused destroy operation of l3proto Signed-off-by: Yasuyuki Kozakai Signed-off-by: Patrick McHardy --- commit f1ab39bebc088ba296db8e047b21700b4a77d51c tree d3276fe947a35054a48f9ba00ec7a31e2d375432 parent aeca1c226efa93ec47d21303d907d7ab18c30f0e author Yasuyuki Kozakai Tue, 08 May 2007 11:06:18 +0200 committer Patrick McHardy Tue, 08 May 2007 11:06:18 +0200 include/net/netfilter/nf_conntrack_l3proto.h | 3 --- net/netfilter/nf_conntrack_core.c | 5 ----- 2 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/net/netfilter/nf_conntrack_l3proto.h b/include/net/netfilter/nf_conntrack_l3proto.h index f32f714..96a58d8 100644 --- a/include/net/netfilter/nf_conntrack_l3proto.h +++ b/include/net/netfilter/nf_conntrack_l3proto.h @@ -56,9 +56,6 @@ struct nf_conntrack_l3proto */ int (*new)(struct nf_conn *conntrack, const struct sk_buff *skb); - /* Called when a conntrack entry is destroyed */ - void (*destroy)(struct nf_conn *conntrack); - /* * Called before tracking. * *dataoff: offset of protocol header (TCP, UDP,...) in *pskb diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index e132c8a..94000a4 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -299,7 +299,6 @@ destroy_conntrack(struct nf_conntrack *nfct) { struct nf_conn *ct = (struct nf_conn *)nfct; struct nf_conn_help *help = nfct_help(ct); - struct nf_conntrack_l3proto *l3proto; struct nf_conntrack_l4proto *l4proto; typeof(nf_conntrack_destroyed) destroyed; @@ -317,10 +316,6 @@ destroy_conntrack(struct nf_conntrack *nfct) * destroy_conntrack() MUST NOT be called with a write lock * to nf_conntrack_lock!!! -HW */ rcu_read_lock(); - l3proto = __nf_ct_l3proto_find(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.l3num); - if (l3proto && l3proto->destroy) - l3proto->destroy(ct); - l4proto = __nf_ct_l4proto_find(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.l3num, ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.protonum); if (l4proto && l4proto->destroy) From kaber at trash.net Thu May 10 15:41:18 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:43:27 2007 Subject: [NETFILTER 06/09]: nf_nat: Clears helper private area when NATing In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134035.8559.15799.sendpatchset@localhost.localdomain> [NETFILTER]: nf_nat: Clears helper private area when NATing Some helpers (eg. ftp) assume that private area in conntrack is filled with zero. It should be cleared when helper is changed. Signed-off-by: Yasuyuki Kozakai Signed-off-by: Patrick McHardy --- commit 204674154410105c5b614101779698b439c2d864 tree c1d5f9835776353a1c53b7313f880ae4a6d8b2f1 parent 9655305aa47e326950ad24fc072ff19aaf5691f9 author Yasuyuki Kozakai Tue, 08 May 2007 11:06:19 +0200 committer Patrick McHardy Tue, 08 May 2007 11:06:19 +0200 net/netfilter/nf_conntrack_core.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 94000a4..e8b5c2d 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -888,8 +888,13 @@ void nf_conntrack_alter_reply(struct nf_conn *ct, NF_CT_DUMP_TUPLE(newreply); ct->tuplehash[IP_CT_DIR_REPLY].tuple = *newreply; - if (!ct->master && help && help->expecting == 0) - help->helper = __nf_ct_helper_find(newreply); + if (!ct->master && help && help->expecting == 0) { + struct nf_conntrack_helper *helper; + helper = __nf_ct_helper_find(newreply); + if (helper) + memset(&help->help, 0, sizeof(help->help)); + help->helper = helper; + } write_unlock_bh(&nf_conntrack_lock); } EXPORT_SYMBOL_GPL(nf_conntrack_alter_reply); From kaber at trash.net Thu May 10 15:41:19 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:43:28 2007 Subject: [NETFILTER 07/09]: iptable_{filter, mangle}: more descriptive "happy cracking" message In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134036.8559.70460.sendpatchset@localhost.localdomain> [NETFILTER]: iptable_{filter,mangle}: more descriptive "happy cracking" message Signed-off-by: Patrick McHardy --- commit 2a5f3d9533016d5f7914b75ea5f7a5fe98872f24 tree e20bd2440ccf6814b349fb00cee0941d63b31d61 parent 204674154410105c5b614101779698b439c2d864 author Patrick McHardy Thu, 10 May 2007 15:30:22 +0200 committer Patrick McHardy Thu, 10 May 2007 15:30:22 +0200 net/ipv4/netfilter/iptable_filter.c | 3 ++- net/ipv4/netfilter/iptable_mangle.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv4/netfilter/iptable_filter.c b/net/ipv4/netfilter/iptable_filter.c index ea14979..4f51c1d 100644 --- a/net/ipv4/netfilter/iptable_filter.c +++ b/net/ipv4/netfilter/iptable_filter.c @@ -81,7 +81,8 @@ ipt_local_out_hook(unsigned int hook, if ((*pskb)->len < sizeof(struct iphdr) || ip_hdrlen(*pskb) < sizeof(struct iphdr)) { if (net_ratelimit()) - printk("ipt_hook: happy cracking.\n"); + printk("iptable_filter: ignoring short SOCK_RAW " + "packet.\n"); return NF_ACCEPT; } diff --git a/net/ipv4/netfilter/iptable_mangle.c b/net/ipv4/netfilter/iptable_mangle.c index c3827ba..902446f 100644 --- a/net/ipv4/netfilter/iptable_mangle.c +++ b/net/ipv4/netfilter/iptable_mangle.c @@ -100,7 +100,8 @@ ipt_local_hook(unsigned int hook, if ((*pskb)->len < sizeof(struct iphdr) || ip_hdrlen(*pskb) < sizeof(struct iphdr)) { if (net_ratelimit()) - printk("ipt_hook: happy cracking.\n"); + printk("iptable_mangle: ignoring short SOCK_RAW " + "packet.\n"); return NF_ACCEPT; } From kaber at trash.net Thu May 10 15:41:20 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:43:38 2007 Subject: [NETFILTER 08/09]: iptable_raw: ignore short packets sent by SOCK_RAW sockets In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134038.8559.13052.sendpatchset@localhost.localdomain> [NETFILTER]: iptable_raw: ignore short packets sent by SOCK_RAW sockets iptables matches and targets expect packets to have at least a full IP header and a valid header length. Ignore packets sent through raw sockets for which this isn't true as in the other tables. Signed-off-by: Patrick McHardy --- commit e319b2005352790a24e1a91dc1af4b2f8643a876 tree 20b707b1bb83996c701f78745f18c75d3e06a3d0 parent 2a5f3d9533016d5f7914b75ea5f7a5fe98872f24 author Patrick McHardy Thu, 10 May 2007 15:38:16 +0200 committer Patrick McHardy Thu, 10 May 2007 15:38:16 +0200 net/ipv4/netfilter/iptable_raw.c | 21 ++++++++++++++++++++- 1 files changed, 20 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/iptable_raw.c b/net/ipv4/netfilter/iptable_raw.c index f7d28fd..d6e5033 100644 --- a/net/ipv4/netfilter/iptable_raw.c +++ b/net/ipv4/netfilter/iptable_raw.c @@ -5,6 +5,7 @@ */ #include #include +#include #define RAW_VALID_HOOKS ((1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_LOCAL_OUT)) @@ -54,6 +55,24 @@ ipt_hook(unsigned int hook, return ipt_do_table(pskb, hook, in, out, &packet_raw); } +static unsigned int +ipt_local_hook(unsigned int hook, + struct sk_buff **pskb, + const struct net_device *in, + const struct net_device *out, + int (*okfn)(struct sk_buff *)) +{ + /* root is playing with raw sockets. */ + if ((*pskb)->len < sizeof(struct iphdr) || + ip_hdrlen(*pskb) < sizeof(struct iphdr)) { + if (net_ratelimit()) + printk("iptable_raw: ignoring short SOCK_RAW" + "packet.\n"); + return NF_ACCEPT; + } + return ipt_do_table(pskb, hook, in, out, &packet_raw); +} + /* 'raw' is the very first table. */ static struct nf_hook_ops ipt_ops[] = { { @@ -64,7 +83,7 @@ static struct nf_hook_ops ipt_ops[] = { .owner = THIS_MODULE, }, { - .hook = ipt_hook, + .hook = ipt_local_hook, .pf = PF_INET, .hooknum = NF_IP_LOCAL_OUT, .priority = NF_IP_PRI_RAW, From kaber at trash.net Thu May 10 15:41:16 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:43:41 2007 Subject: [NETFILTER 05/09]: ctnetlink: clear helper area and handle unchanged helper In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134034.8559.94686.sendpatchset@localhost.localdomain> [NETFILTER]: ctnetlink: clear helper area and handle unchanged helper This patch - Clears private area for helper even if no helper is assigned to conntrack. It might be used by old helper. - Unchanges if the same helper as the used one is specified. - Does not find helper if no helper is specified. And it does not require private area for helper in that case. Signed-off-by: Yasuyuki Kozakai Signed-off-by: Patrick McHardy --- commit 9655305aa47e326950ad24fc072ff19aaf5691f9 tree f8c4bc7c4772b99427327af7bf93007f82e8c69f parent f1ab39bebc088ba296db8e047b21700b4a77d51c author Yasuyuki Kozakai Tue, 08 May 2007 11:06:18 +0200 committer Patrick McHardy Tue, 08 May 2007 11:06:18 +0200 net/netfilter/nf_conntrack_netlink.c | 40 +++++++++++++++++++--------------- 1 files changed, 22 insertions(+), 18 deletions(-) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index aa1a97e..d6d39e2 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -830,11 +830,6 @@ ctnetlink_change_helper(struct nf_conn *ct, struct nfattr *cda[]) char *helpname; int err; - if (!help) { - /* FIXME: we need to reallocate and rehash */ - return -EBUSY; - } - /* don't change helper of sibling connections */ if (ct->master) return -EINVAL; @@ -843,25 +838,34 @@ ctnetlink_change_helper(struct nf_conn *ct, struct nfattr *cda[]) if (err < 0) return err; - helper = __nf_conntrack_helper_find_byname(helpname); - if (!helper) { - if (!strcmp(helpname, "")) - helper = NULL; - else - return -EINVAL; - } - - if (help->helper) { - if (!helper) { + if (!strcmp(helpname, "")) { + if (help && help->helper) { /* we had a helper before ... */ nf_ct_remove_expectations(ct); help->helper = NULL; - } else { - /* need to zero data of old helper */ - memset(&help->help, 0, sizeof(help->help)); } + + return 0; } + if (!help) { + /* FIXME: we need to reallocate and rehash */ + return -EBUSY; + } + + helper = __nf_conntrack_helper_find_byname(helpname); + if (helper == NULL) + return -EINVAL; + + if (help->helper == helper) + return 0; + + if (help->helper) + /* we had a helper before ... */ + nf_ct_remove_expectations(ct); + + /* need to zero data of old helper */ + memset(&help->help, 0, sizeof(help->help)); help->helper = helper; return 0; From kaber at trash.net Thu May 10 15:41:22 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 16:43:44 2007 Subject: [NETFILTER 09/09]: xt_conntrack: add compat support In-Reply-To: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> Message-ID: <20070510134039.8559.90741.sendpatchset@localhost.localdomain> [NETFILTER]: xt_conntrack: add compat support Signed-off-by: Patrick McHardy --- commit 18a31ce74f45310a1133fadd17f36b879fd0221b tree 2b0e1102cbb2625a350309348ac0b15a7b54db5d parent e319b2005352790a24e1a91dc1af4b2f8643a876 author Patrick McHardy Thu, 10 May 2007 15:39:08 +0200 committer Patrick McHardy Thu, 10 May 2007 15:39:08 +0200 net/netfilter/xt_conntrack.c | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 54 insertions(+), 0 deletions(-) diff --git a/net/netfilter/xt_conntrack.c b/net/netfilter/xt_conntrack.c index f4ea8fe..189ded5 100644 --- a/net/netfilter/xt_conntrack.c +++ b/net/netfilter/xt_conntrack.c @@ -134,12 +134,66 @@ static void destroy(const struct xt_match *match, void *matchinfo) nf_ct_l3proto_module_put(match->family); } +#ifdef CONFIG_COMPAT +struct compat_xt_conntrack_info +{ + compat_uint_t statemask; + compat_uint_t statusmask; + struct ip_conntrack_old_tuple tuple[IP_CT_DIR_MAX]; + struct in_addr sipmsk[IP_CT_DIR_MAX]; + struct in_addr dipmsk[IP_CT_DIR_MAX]; + compat_ulong_t expires_min; + compat_ulong_t expires_max; + u_int8_t flags; + u_int8_t invflags; +}; + +static void compat_from_user(void *dst, void *src) +{ + struct compat_xt_conntrack_info *cm = src; + struct xt_conntrack_info m = { + .statemask = cm->statemask, + .statusmask = cm->statusmask, + .expires_min = cm->expires_min, + .expires_max = cm->expires_max, + .flags = cm->flags, + .invflags = cm->invflags, + }; + memcpy(m.tuple, cm->tuple, sizeof(m.tuple)); + memcpy(m.sipmsk, cm->sipmsk, sizeof(m.sipmsk)); + memcpy(m.dipmsk, cm->dipmsk, sizeof(m.dipmsk)); + memcpy(dst, &m, sizeof(m)); +} + +static int compat_to_user(void __user *dst, void *src) +{ + struct xt_conntrack_info *m = src; + struct compat_xt_conntrack_info cm = { + .statemask = m->statemask, + .statusmask = m->statusmask, + .expires_min = m->expires_min, + .expires_max = m->expires_max, + .flags = m->flags, + .invflags = m->invflags, + }; + memcpy(cm.tuple, m->tuple, sizeof(cm.tuple)); + memcpy(cm.sipmsk, m->sipmsk, sizeof(cm.sipmsk)); + memcpy(cm.dipmsk, m->dipmsk, sizeof(cm.dipmsk)); + return copy_to_user(dst, &cm, sizeof(cm)) ? -EFAULT : 0; +} +#endif + static struct xt_match conntrack_match = { .name = "conntrack", .match = match, .checkentry = checkentry, .destroy = destroy, .matchsize = sizeof(struct xt_conntrack_info), +#ifdef CONFIG_COMPAT + .compatsize = sizeof(struct compat_xt_conntrack_info), + .compat_from_user = compat_from_user, + .compat_to_user = compat_to_user, +#endif .family = AF_INET, .me = THIS_MODULE, }; From kaber at trash.net Thu May 10 16:02:18 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 17:04:25 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue In-Reply-To: References: <46431C0D.5080507@trash.net> Message-ID: <464325EA.8040303@trash.net> Jan Engelhardt wrote: > On May 10 2007 15:20, Patrick McHardy wrote: > >>>And the following cmd oopsed it: >>> >>> # iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW >>> -j sshcheck; >> >> >>I believe this is a bug in the compat code, which *seems* to call (its >>a bit messy, I just had a quick look) the destroy function without >>having called checkentry previously when something goes wrong. Which >>commands did you run before this? > > > A lot ... as far as the filter table and sshcheck is concerned, > > iptables -N sshcheck; > iptables -A sshcheck -m recent --name sshcheck --seconds 60 --update -j DROP; > iptables -A sshcheck -m hashlimit --hashlimit-name sshcheck \ > --hashlimit-mode srcip --hashlimit 4/min --hashlimit-burst 4 \ > -j RETURN; > iptables -A sshcheck -m recent --name sshcheck --set -j DROP; Did you get an "invalid size" message in the ringbuffer before the oops? From jengelh at linux01.gwdg.de Thu May 10 16:05:14 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Thu May 10 17:06:59 2007 Subject: iptables throws unknown error - suspecting 32/64 compat issue In-Reply-To: <464325EA.8040303@trash.net> References: <46431C0D.5080507@trash.net> <464325EA.8040303@trash.net> Message-ID: On May 10 2007 16:02, Patrick McHardy wrote: >> >> A lot ... as far as the filter table and sshcheck is concerned, >> >> iptables -N sshcheck; >> iptables -A sshcheck -m recent --name sshcheck --seconds 60 --update -j DROP; >> iptables -A sshcheck -m hashlimit --hashlimit-name sshcheck \ >> --hashlimit-mode srcip --hashlimit 4/min --hashlimit-burst 4 \ >> -j RETURN; >> iptables -A sshcheck -m recent --name sshcheck --set -j DROP; > >Did you get an "invalid size" message in the ringbuffer before the oops? Now that you mention it, yes: ip_tables: conntrack match: invalid size 80 != 72 Jan -- From kaber at trash.net Thu May 10 16:11:44 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 17:13:50 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> Message-ID: <46432820.8040602@trash.net> fender wrote: > This is the link: > > http://portknocko.berlios.de/pom-ng/ Added to sources.list, thanks. From hlin at nextone.com Thu May 10 17:41:04 2007 From: hlin at nextone.com (Hung Lin) Date: Thu May 10 19:43:02 2007 Subject: Kernel oops when putting the console option in /boot/grub/menu.lst Message-ID: Hi, I'm using ipset-2.2.9 with kernel 2.6.11.4-21.13 (SuSE 9.3 kernel) and iptables-1.3.1-3 (SuSE 9.3 iptables) and everything is fine. But after I added a console option to /boot/grub/menu.lst, the kenrel will hang sometimes and show kernel oops message on the monitor. After research, I found it is `iptables -m hashlimit` command to cause this problem. Therefore, I did some tests: I used a loop to insert and delete hashlimit rules to iptables, here's the result: 1. with ipset patch and without console option in grub menu, no problem 2. withotu ipset patch and with console option in grub menu, no problem 3. with ipset patch and with console option in grub menu, kernel crashs after hundreds of iterations. It looks like console option in the grub menu has something conflict with ipset kernel patch. But I don't understand. Please give me your advices. Thanks in advance. P.S. Here's the grub menu: ORIGINAL ONE (without console option): color white/blue black/light-gray default 0 timeout 8 title NexTone Linux kernel (hd0,1)/boot/vmlinuz root=/dev/sda2 vga=normal splash=silent desktop showopts vmalloc=256M initrd (hd0,1)/boot/initrd title Rescue Floppy root (fd0) chainloader +1 title Failsafe kernel (hd0,1)/boot/vmlinuz root=/dev/sda2 vga=normal splash=silent desktop showopts single initrd (hd0,1)/boot/initrd NEW ONE (with console option): color white/blue black/light-gray default 0 timeout 8 title NexTone Linux kernel (hd0,1)/boot/vmlinuz root=/dev/sda2 vga=normal splash=silent desktop showopts console=tty0 console=ttyS0,9600n8 vmalloc=256M initrd (hd0,1)/boot/initrd title Rescue Floppy root (fd0) chainloader +1 title Failsafe kernel (hd0,1)/boot/vmlinuz root=/dev/sda2 vga=normal splash=silent desktop showopts console=ttyS0,9600n8 console=tty0 single initrd (hd0,1)/boot/initrd Hung Lin Software Engineer NexTone Communications, Inc. -- Network Without Limits -- From kaber at trash.net Thu May 10 18:44:18 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 10 19:46:33 2007 Subject: Kernel oops when putting the console option in /boot/grub/menu.lst In-Reply-To: References: Message-ID: <46434BE2.5090605@trash.net> Hung Lin wrote: > Hi, > > I'm using ipset-2.2.9 with kernel 2.6.11.4-21.13 (SuSE 9.3 kernel) and > iptables-1.3.1-3 (SuSE 9.3 iptables) and everything is fine. But after > I added a console option to /boot/grub/menu.lst, the kenrel will hang > sometimes and show kernel oops message on the monitor. After research, > I found it is `iptables -m hashlimit` command to cause this problem. > Therefore, I did some tests: > > I used a loop to insert and delete hashlimit rules to iptables, here's > the result: > > 1. with ipset patch and without console option in grub menu, no problem > > 2. withotu ipset patch and with console option in grub menu, no problem > > 3. with ipset patch and with console option in grub menu, kernel crashs > after hundreds of iterations. > > > It looks like console option in the grub menu has something conflict > with ipset kernel patch. But I don't understand. > > Please give me your advices. Thanks in advance. Please send the oops. From hlin at nextone.com Thu May 10 19:06:29 2007 From: hlin at nextone.com (Hung Lin) Date: Thu May 10 20:07:24 2007 Subject: Kernel oops when putting the console option in /boot/grub/menu.lst In-Reply-To: <46434BE2.5090605@trash.net> References: <46434BE2.5090605@trash.net> Message-ID: >Hung Lin wrote: >> Hi, >> >> I'm using ipset-2.2.9 with kernel 2.6.11.4-21.13 (SuSE 9.3 kernel) and >> iptables-1.3.1-3 (SuSE 9.3 iptables) and everything is fine. But >> after I added a console option to /boot/grub/menu.lst, the kenrel will >> hang sometimes and show kernel oops message on the monitor. After >> research, I found it is `iptables -m hashlimit` command to cause this problem. >> Therefore, I did some tests: >> >> I used a loop to insert and delete hashlimit rules to iptables, here's >> the result: >> >> 1. with ipset patch and without console option in grub menu, no >> problem >> >> 2. withotu ipset patch and with console option in grub menu, no >> problem >> >> 3. with ipset patch and with console option in grub menu, kernel >> crashs after hundreds of iterations. >> >> >> It looks like console option in the grub menu has something conflict >> with ipset kernel patch. But I don't understand. >> >> Please give me your advices. Thanks in advance. >Please send the oops. The oops message are not always the same. Most time the process is iptables and the first call trace is htable_destroy, sometime the first call trace is htable_create. And some times the process is swapper. Here are the most often oops messages: Oops: 0002 [#1] SMP Modules linked in: af_packet ip_set_ipporthash ip_set_ipportiphash ip_set_iphash ipt_limit ip_set_portmap ipt_sethl ip_set_ipnethash ipt_ULOG ipt_hashlimit ipt_set ip_set_ipiphash 8021q edd joydev nvram thermal processor fan button battery ac bv rp ipt_state ipt_pkttype ipv6 hhnet_drawb hhnet hhnet_eth e1000 ehci_hcd uhci_hcd usbcore i2c_i801 i2c_core evdev iptable_filter ip6table_filter ip6_tables ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables dm_mod sr_mod st mptspi mptscsih mptbase ide_cd cdrom reiserfs aic79xx sd_mod scsi_mod CPU: 0 EIP: 0060:[] Tainted: PF U VLI EFLAGS: 00010046 (2.6.11.4-430.8-bigsmp) EIP is at del_timer+0x3b/0x70 eax: f112e034 ebx: c381bae0 ecx: 00000282 edx: f12f2034 esi: f1304034 edi: f561efe0 ebp: e4e54000 esp: e4e55c18 ds: 007b es: 007b ss: 0068 Process iptables (pid: 25097, threadinfo=e4e54000 task=df2dd020) Stack: f1304000 00000070 f0eb4427 f561f050 f0976b57 e4e55c58 00000074 e4e55c88 e4e55c9c 08053078 e4e55c84 e4e54000 0000bf60 f0d89000 f5613000 f5da5000 00000000 746c6966 00007265 00000000 00000000 00000000 00000000 00000000 Call Trace: [] htable_destroy+0x37/0x60 [ipt_hashlimit] [] do_replace+0x437/0x650 [ip_tables] [] do_ipt_set_ctl+0x4b/0x60 [ip_tables] [] nf_sockopt+0xc3/0x120 [] nf_setsockopt+0x1e/0x30 [] ip_setsockopt+0x10c/0xb10 [] nf_sockopt+0x90/0x120 [] ip_getsockopt+0xb0/0x6c0 [] do_page_fault+0x1d3/0x613 [] zap_pte_range+0x1fd/0x370 [] buffered_rmqueue+0x14c/0x210 [] __alloc_pages+0x125/0x450 [] do_anonymous_page+0x7c/0x1e0 [] do_no_page+0x7a/0x350 [] handle_mm_fault+0x1c2/0x1e0 [] vsnprintf+0x394/0x510 [] do_page_fault+0x1d3/0x613 [] fd_install+0x2f/0x60 [] fget+0x49/0x60 [] sock_common_setsockopt+0x26/0x40 [] sys_setsockopt+0x69/0xd0 [] sys_socketcall+0xca/0x250 [] do_page_fault+0x0/0x613 [] sysenter_past_esp+0x52/0x75 Code: ff ff eb 17 89 d8 e8 45 fc 20 00 3b 5e 1c 89 c1 74 14 89 c2 89 d8 e8 75 fd 20 00 8b 5e 1c 31 c0 85 db 75 e0 eb 2c 8b 56 04 8b 06 <89> 50 04 89 02 c7 46 04 00 02 20 00 c7 06 00 01 10 00 c7 46 1c From davem at davemloft.net Thu May 10 23:14:24 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:15:17 2007 Subject: [NETFILTER 01/09]: Clean up table initialization In-Reply-To: <20070510134028.8559.53451.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134028.8559.53451.sendpatchset@localhost.localdomain> Message-ID: <20070510.141424.31751194.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:11 +0200 (MEST) > [NETFILTER]: Clean up table initialization > > - move arp_tables initial table structure definitions to arp_tables.h > similar to ip_tables and ip6_tables > > - use C99 initializers > > - use initializer macros where possible > > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 10 23:14:53 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:15:46 2007 Subject: [NETFILTER 02/09]: nf_nat: remove unused argument of function allocating binding In-Reply-To: <20070510134030.8559.58054.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134030.8559.58054.sendpatchset@localhost.localdomain> Message-ID: <20070510.141453.94072260.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:12 +0200 (MEST) > [NETFILTER]: nf_nat: remove unused argument of function allocating binding > > nf_nat_rule_find, alloc_null_binding and alloc_null_binding_confirmed > do not use the argument 'info', which is actually ct->nat.info. > If they are necessary to access it again, we can use the argument 'ct' > instead. > > Signed-off-by: Yasuyuki Kozakai > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 10 23:15:16 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:16:11 2007 Subject: [NETFILTER 03/09]: nf_conntrack: Removes duplicated declarations In-Reply-To: <20070510134031.8559.74950.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134031.8559.74950.sendpatchset@localhost.localdomain> Message-ID: <20070510.141516.82054449.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:14 +0200 (MEST) > [NETFILTER]: nf_conntrack: Removes duplicated declarations > > These are also in include/net/netfilter/nf_conntrack_helper.h > > Signed-off-by: Yasuyuki Kozakai > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 10 23:15:37 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:16:31 2007 Subject: [NETFILTER 04/09]: nf_conntrack: Removes unused destroy operation of l3proto In-Reply-To: <20070510134032.8559.22163.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134032.8559.22163.sendpatchset@localhost.localdomain> Message-ID: <20070510.141537.120444235.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:15 +0200 (MEST) > [NETFILTER]: nf_conntrack: Removes unused destroy operation of l3proto > > Signed-off-by: Yasuyuki Kozakai > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 10 23:16:05 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:17:02 2007 Subject: [NETFILTER 05/09]: ctnetlink: clear helper area and handle unchanged helper In-Reply-To: <20070510134034.8559.94686.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134034.8559.94686.sendpatchset@localhost.localdomain> Message-ID: <20070510.141605.75759461.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:16 +0200 (MEST) > [NETFILTER]: ctnetlink: clear helper area and handle unchanged helper > > This patch > - Clears private area for helper even if no helper is assigned to > conntrack. It might be used by old helper. > - Unchanges if the same helper as the used one is specified. > - Does not find helper if no helper is specified. And it does not > require private area for helper in that case. > > Signed-off-by: Yasuyuki Kozakai > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 10 23:16:31 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:17:28 2007 Subject: [NETFILTER 06/09]: nf_nat: Clears helper private area when NATing In-Reply-To: <20070510134035.8559.15799.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134035.8559.15799.sendpatchset@localhost.localdomain> Message-ID: <20070510.141631.42906695.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:18 +0200 (MEST) > [NETFILTER]: nf_nat: Clears helper private area when NATing > > Some helpers (eg. ftp) assume that private area in conntrack is > filled with zero. It should be cleared when helper is changed. > > Signed-off-by: Yasuyuki Kozakai > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 10 23:17:18 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:18:18 2007 Subject: [NETFILTER 07/09]: iptable_{filter,mangle}: more descriptive "happy cracking" message In-Reply-To: <20070510134036.8559.70460.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134036.8559.70460.sendpatchset@localhost.localdomain> Message-ID: <20070510.141718.45876207.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:19 +0200 (MEST) > [NETFILTER]: iptable_{filter,mangle}: more descriptive "happy cracking" message > > Signed-off-by: Patrick McHardy In a way I'm very sad to see this message go away, but such is "progress", so applied ;-) From davem at davemloft.net Thu May 10 23:17:44 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:18:39 2007 Subject: [NETFILTER 08/09]: iptable_raw: ignore short packets sent by SOCK_RAW sockets In-Reply-To: <20070510134038.8559.13052.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134038.8559.13052.sendpatchset@localhost.localdomain> Message-ID: <20070510.141744.76776387.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:20 +0200 (MEST) > [NETFILTER]: iptable_raw: ignore short packets sent by SOCK_RAW sockets > > iptables matches and targets expect packets to have at least a full > IP header and a valid header length. Ignore packets sent through > raw sockets for which this isn't true as in the other tables. > > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Thu May 10 23:18:11 2007 From: davem at davemloft.net (David Miller) Date: Fri May 11 00:19:05 2007 Subject: [NETFILTER 09/09]: xt_conntrack: add compat support In-Reply-To: <20070510134039.8559.90741.sendpatchset@localhost.localdomain> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134039.8559.90741.sendpatchset@localhost.localdomain> Message-ID: <20070510.141811.109882029.davem@davemloft.net> From: Patrick McHardy Date: Thu, 10 May 2007 15:41:22 +0200 (MEST) > [NETFILTER]: xt_conntrack: add compat support > > Signed-off-by: Patrick McHardy Also applied, thanks a lot Patrick. From kaber at trash.net Fri May 11 02:44:39 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 11 03:47:02 2007 Subject: [NETFILTER 07/09]: iptable_{filter,mangle}: more descriptive "happy cracking" message In-Reply-To: <20070510.141718.45876207.davem@davemloft.net> References: <20070510134027.8559.40540.sendpatchset@localhost.localdomain> <20070510134036.8559.70460.sendpatchset@localhost.localdomain> <20070510.141718.45876207.davem@davemloft.net> Message-ID: <4643BC77.1070906@trash.net> David Miller wrote: > From: Patrick McHardy > Date: Thu, 10 May 2007 15:41:19 +0200 (MEST) > > >>[NETFILTER]: iptable_{filter,mangle}: more descriptive "happy cracking" message >> >>Signed-off-by: Patrick McHardy > > > In a way I'm very sad to see this message go away, but such is > "progress", so applied ;-) Me too, but I'd rather change it than explain it again. We still have a few of Rusty's funny messages and commentaries left :) From yasuyuki.kozakai at toshiba.co.jp Fri May 11 03:51:06 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri May 11 04:52:33 2007 Subject: [RFC][PATCH 0/7]: ct_extend In-Reply-To: <46431138.2080805@trash.net> References: <46404700.40609@trash.net> <200705091105.l49B5DTu023689@toshiba.co.jp> <46431138.2080805@trash.net> Message-ID: <200705110151.l4B1p7bd012706@toshiba.co.jp> Hi, Patrick, Pablo and all, From: Patrick McHardy Date: Thu, 10 May 2007 14:34:00 +0200 > >>This will add quite some overhead since at least nfct_help is looked at > >>for every packet (we might avoid this using a status flag though). > >>I'm guessing the locks are needed to protect against concurrent > >>reallocations. Maybe we can avoid this by adding the limitation that > >>only unconfirmed entries may add new extensions? > > > > > > It sounds good to avoid competition of 2 packet processing. I think > > that the remain is nfctnetlink. It can assign helper to a confirmed > > conntrack. Do you think that it's enough to assume that it disables bh ? > > > No, that would only help for the CPU its running on. But so far > we only allow to change helpers, not assign completely new ones, > so no reallocation is needed. I'm wondering if this behaviour > is correct though .. IIRC, Harald had a idea of userland helper using nfctnetlink and nfqueue (2 years ago ?). ??? Please wait...... oh.. but to do that, nfctnetlink is enough to assign a helper to an unconfirmed conntrack (currently it does not). And I'm not sure about the case of conntrackd. Pablo, is there any case that conntrackd assign helper to a confirmed conntrack ? -- Yasuyuki Kozakai From hdemir at metu.edu.tr Fri May 11 10:21:46 2007 From: hdemir at metu.edu.tr (husnu demir) Date: Fri May 11 11:22:46 2007 Subject: Compile errors for debian-amd64 Message-ID: <20070511082145.GA2289804@metu.edu.tr> Hi, I am trying to compile kernel 2.6.21.1 with ipset from pom-ng snapshot of 10.05.2007. However, there is problem as; Kernel: arch/x86_64/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 725 modules WARNING: "ip6t_register_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! WARNING: "ip6t_unregister_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 When I change the ipt_unregister_match(&set_match); to xt_reg... etc., it compiles but does not work. I think it needs something elses. # iptables -A OUTPUT -m set --set izinli src -j ACCEPT iptables: No chain/target/match by that name # ipset -nL izinli Name: izinli Type: iphash References: 0 Default binding: Header: hashsize: 1024 probes: 8 resize: 50 Members: 10.10.144.156 Bindings: Do I only need help on this subject? I could not find any patches available on the dev-list and also for the ROUTE as said before?? Thanks. hdemir. From frozenspot at gmail.com Fri May 11 15:00:59 2007 From: frozenspot at gmail.com (fender) Date: Fri May 11 16:02:06 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <46432820.8040602@trash.net> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> <46432820.8040602@trash.net> Message-ID: <7e36c7130705110600l35d6af11m3247eabd22621439@mail.gmail.com> Hi Patrick, On 5/10/07, Patrick McHardy wrote: > fender wrote: > > This is the link: > > > > http://portknocko.berlios.de/pom-ng/ > > > Added to sources.list, thanks. I thought that you have read the last mail. This link doesn't work, because the berlios repository doesn't let me to put external files (the tarball). I will try with another server and I will send you the new link to the tarball. Regards, -- J. Federico Hernandez From kaber at trash.net Fri May 11 18:37:43 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 11 19:40:26 2007 Subject: Kernel oops when putting the console option in /boot/grub/menu.lst In-Reply-To: References: <46434BE2.5090605@trash.net> Message-ID: <46449BD7.1010405@trash.net> Hung Lin wrote: > EFLAGS: 00010046 (2.6.11.4-430.8-bigsmp) This is an ancient and heavily patched SuSE kernel. Please try to reproduce with current mainline. From c-d.hailfinger.devel.2006 at gmx.net Fri May 11 19:15:38 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri May 11 20:16:27 2007 Subject: Kernel oops when putting the console option in /boot/grub/menu.lst In-Reply-To: References: <46434BE2.5090605@trash.net> Message-ID: <4644A4BA.8040606@gmx.net> On 10.05.2007 19:06, Hung Lin wrote: > EIP: 0060:[] Tainted: PF U VLI > EFLAGS: 00010046 (2.6.11.4-430.8-bigsmp) Please try to reproduce with current vanilla kernel without loading proprietary modules and without forcing module load. Regards, Carl-Daniel From jengelh at linux01.gwdg.de Sat May 12 12:31:13 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Sat May 12 13:33:18 2007 Subject: Userspace packet queuing with libipq: ip_conntrack does not defragment? In-Reply-To: <4641F80E.8050103@rtij.nl> References: <22b256140705090832v556bee45ne5119d529a7e310e@mail.gmail.com> <4641F80E.8050103@rtij.nl> Message-ID: On May 9 2007 18:34, Martijn Lievaart wrote: > Michael Ransburg wrote: >> However, since ip_conntrack is loaded I would expect that >> the packets are defragmented before they are passed to my userspace >> appliation (as indicated here for example: >> http://lists.netfilter.org/pipermail/netfilter/2002-May/034006.html). >> This does not seem the case, i.e., the maximum size of the packets >> which I get (through ->data_len) is 1500 bits. >> >> The len parameter of the ipq_read method is well over 1500, as is the >> buffer size. > > Do you actually have packets greater than 1500 bytes? That would mean you send > over loopback, tokenring, etc, but NOT ethernet. Gigabit ethernet allows for 9000-byte jumbo frames. > Maybe you are confusing datagram and packet fragmentation. Conntrack only > defragments packets, not datagrams. Jan -- From halm90 at gmail.com Sat May 12 03:34:36 2007 From: halm90 at gmail.com (Hal Moroff) Date: Sat May 12 17:26:24 2007 Subject: Is libiptc still the preferred library for manipulating tables? Message-ID: I've been trying for awhile to find this out as well. I'm working on an appliance and I need to dynamically insert/remove rules based on what's happening in the box. I prefer not to resort to system("itpables yada yada yada") and so have been trying to use libiptc. I've succeeded in inserting / removing simple rules (based only on source IP and destination IP). I'm struggling now to understand how to construct more complex matching rules (destination port). There's this document: http://www.opalsoft.net/qos/libiptc/qlibiptc.html which is incomplete, but mostly correct as far as it goes. I offered to correct some errors in the doc, but the author's email address is apparently invalid. If anyone has any feedback / tips / samples I'd be grateful. From jengelh at linux01.gwdg.de Mon May 14 21:53:09 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Mon May 14 22:55:32 2007 Subject: netfilter load sharing In-Reply-To: <46483D46.6040308@fragstein.de> References: <46483D46.6040308@fragstein.de> Message-ID: On May 14 2007 12:43, Thomas Fragstein wrote: > > Hi List, > > i have two questions. > > first: how i can see how many cpu load ist generate by netfilter (iptables) > > second: on my linux box i have seen 20-30% of one cpu is using by system. it is > possible that netfilter can share the load over any cores (multicore cpu) I believe that on incoming packets, the CPU handling the network card interurpt will also serve the iptables and routing logic, and on output, the processor the program runs on that sent a packet. Not sure, though. CC/FWD to nf-dev, maybe they know. Jan -- From henrik at henriknordstrom.net Tue May 15 09:07:41 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Tue May 15 10:09:15 2007 Subject: Is libiptc still the preferred library for manipulating tables? In-Reply-To: References: Message-ID: <1179212861.24969.7.camel@henriknordstrom.net> fre 2007-05-11 klockan 18:34 -0700 skrev Hal Moroff: > I've been trying for awhile to find this out as well. Well.. lipiptc is not and has never been an official interface. Has always been considered an internal API not for reuse by other applications with the iptables and iptables-save/restore commands being the official APIs. > I'm working on an appliance and I need to dynamically insert/remove > rules based on > what's happening in the box. I prefer not to resort to > system("itpables yada yada yada") An alternative official interface is to popen iptables-restore in the noflush mode. Gives you a quite smart interface for manipulating iptables. Syntax is the same as iptables, execpt for how you select which table to manipulate. *tablename iptables command line, without iptables or table selection [repeat until done with current modification] COMMIT Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070515/3e546d21/attachment-0001.pgp From azez at ufomechanic.net Tue May 15 12:58:19 2007 From: azez at ufomechanic.net (Amin Azez) Date: Tue May 15 14:00:09 2007 Subject: Kernel oops when putting the console option in /boot/grub/menu.lst In-Reply-To: References: Message-ID: <4649924B.7020301@ufomechanic.net> * Hung Lin wrote, On 10/05/07 16:41: > Hi, > > I'm using ipset-2.2.9 with kernel 2.6.11.4-21.13 (SuSE 9.3 kernel) and > iptables-1.3.1-3 (SuSE 9.3 iptables) and everything is fine. But after > I added a console option to /boot/grub/menu.lst, the kenrel will hang > sometimes and show kernel oops message on the monitor. After research, > I found it is `iptables -m hashlimit` command to cause this problem. > Therefore, I did some tests: Try running: dmesg -n 1 in rc.local or something and then see if you get the oops? I would guess that a module is doing some printk that are going to the serial console, which can be slow, very slow. This could well enforce an otherwise unreachable race condition. dmesg-n 1 will stop most or all printk from going to the console. It would be good to track the prink behind it and stop it as it will still be slowing down the system anyway when it logs a lot to the kernel ring buffer. Sam From kaber at trash.net Wed May 16 18:54:41 2007 From: kaber at trash.net (Patrick McHardy) Date: Wed May 16 19:57:11 2007 Subject: [NETFILTER 2/2]: nf_conntrack_ipv4: fix incorrect #ifdef config name Message-ID: <464B3751.8020902@trash.net> A non-text attachment was scrubbed... Name: 02.diff Type: text/x-diff Size: 1423 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20070516/c745cf86/02.bin From kaber at trash.net Wed May 16 18:54:37 2007 From: kaber at trash.net (Patrick McHardy) Date: Wed May 16 19:57:14 2007 Subject: [NETFILTER 1/2]: nf_conntrack: fix use-after-free in helper destroy callback invocation Message-ID: <464B374D.5000205@trash.net> These two patches fix an oops when unloading helper modules and a incorrect config ifdef. Please apply, thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: 01.diff Type: text/x-diff Size: 2587 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20070516/ba954cd4/01.bin From kaber at trash.net Wed May 16 18:56:11 2007 From: kaber at trash.net (Patrick McHardy) Date: Wed May 16 19:58:37 2007 Subject: [NETFILTER -stable]: {ip, nf}_conntrack: fix use-after-free in helper destroy callback invocation Message-ID: <464B37AB.5040802@trash.net> This patch for stable-2.6.21 fixes an oops when unloading conntrack helper modules. Please apply, thanks. -------------- next part -------------- [NETFILTER]: {ip,nf}_conntrack: fix use-after-free in helper destroy callback invocation When the helper module is removed for a master connection that has a fulfilled expectation, but has already timed out and got removed from the hash tables, nf_conntrack_helper_unregister can't find the master connection to unset the helper, causing a use-after-free when the expected connection is destroyed and releases the last reference to the master. The helper destroy callback was introduced for the PPtP helper to clean up expectations and expected connections when the master connection times out, but doing this from destroy_conntrack only works for unfulfilled expectations since expected connections hold a reference to the master, preventing its destruction. Move the destroy callback to the timeout function, which fixes both problems. Reported/tested by Gabor Burjan . Signed-off-by: Patrick McHardy --- commit 441f15ce23ef5c4d149b7e7985f63c1ddd334c45 tree 8783e067803def0fc2773ef3515190143ac47320 parent 8d8b10482fffcb72b15515231bb942e2ad6395c9 author Patrick McHardy Wed, 16 May 2007 18:52:36 +0200 committer Patrick McHardy Wed, 16 May 2007 18:52:36 +0200 net/ipv4/netfilter/ip_conntrack_core.c | 10 +++++----- net/netfilter/nf_conntrack_core.c | 8 ++++---- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c index 23b99ae..75bd597 100644 --- a/net/ipv4/netfilter/ip_conntrack_core.c +++ b/net/ipv4/netfilter/ip_conntrack_core.c @@ -302,7 +302,6 @@ destroy_conntrack(struct nf_conntrack *nfct) { struct ip_conntrack *ct = (struct ip_conntrack *)nfct; struct ip_conntrack_protocol *proto; - struct ip_conntrack_helper *helper; typeof(ip_conntrack_destroyed) destroyed; DEBUGP("destroy_conntrack(%p)\n", ct); @@ -312,10 +311,6 @@ destroy_conntrack(struct nf_conntrack *nfct) ip_conntrack_event(IPCT_DESTROY, ct); set_bit(IPS_DYING_BIT, &ct->status); - helper = ct->helper; - if (helper && helper->destroy) - helper->destroy(ct); - /* To make sure we don't get any weird locking issues here: * destroy_conntrack() MUST NOT be called with a write lock * to ip_conntrack_lock!!! -HW */ @@ -356,6 +351,11 @@ destroy_conntrack(struct nf_conntrack *nfct) static void death_by_timeout(unsigned long ul_conntrack) { struct ip_conntrack *ct = (void *)ul_conntrack; + struct ip_conntrack_helper *helper; + + helper = ct->helper; + if (helper && helper->destroy) + helper->destroy(ct); write_lock_bh(&ip_conntrack_lock); /* Inside lock so preempt is disabled on module removal path. diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index b3a70eb..ce28fdd 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -315,7 +315,6 @@ static void destroy_conntrack(struct nf_conntrack *nfct) { struct nf_conn *ct = (struct nf_conn *)nfct; - struct nf_conn_help *help = nfct_help(ct); struct nf_conntrack_l3proto *l3proto; struct nf_conntrack_l4proto *l4proto; typeof(nf_conntrack_destroyed) destroyed; @@ -327,9 +326,6 @@ destroy_conntrack(struct nf_conntrack *nfct) nf_conntrack_event(IPCT_DESTROY, ct); set_bit(IPS_DYING_BIT, &ct->status); - if (help && help->helper && help->helper->destroy) - help->helper->destroy(ct); - /* To make sure we don't get any weird locking issues here: * destroy_conntrack() MUST NOT be called with a write lock * to nf_conntrack_lock!!! -HW */ @@ -375,6 +371,10 @@ destroy_conntrack(struct nf_conntrack *nfct) static void death_by_timeout(unsigned long ul_conntrack) { struct nf_conn *ct = (void *)ul_conntrack; + struct nf_conn_help *help = nfct_help(ct); + + if (help && help->helper && help->helper->destroy) + help->helper->destroy(ct); write_lock_bh(&nf_conntrack_lock); /* Inside lock so preempt is disabled on module removal path. From Sarbeswar.Mohapatra at nethawkgroup.com Wed May 16 23:18:06 2007 From: Sarbeswar.Mohapatra at nethawkgroup.com (Sarbeswar Mohapatra) Date: Thu May 17 19:57:32 2007 Subject: MAC address update Message-ID: <00d401c797ff$b2f60230$9f0201c0@nethawk.fi> Hi, I am using netfilter hook (NF_POST_ROUTING) to create IP tunnel. In the nf hook function, the skb is expanded and added a new IP header (IP tunnel). When I see the packet in ethereal it does not update the MAC address according to the new IP header, rather the MAC address is the one for the original ip header (I am talking about the destination only, the source MAC header is the same as both src ip addresses belong to the local machine). Also for testing purpose, I tried to modify the destination ip address instead of adding a new IP header, it still has the old MAC address. What I understood was after the hook the skb should go to ip_finish_output2 and it should call use the ARP module to update the MAC address. Please send me your suggestion, if I am missing anything. Regards, Sarbeswar Sarbeswar Mohapatra NetHawk Corp 3400 Waterview Pkwy Suite 100 Richardson, TX - 75080 Email: Sarbeswar.Mohapatra@nethawkgroup.com Tel: +1 972 761 9271 Ext. 299 CELL: +1 214 682 5645 FAX: +1 972 761 9067 From zhaojingmin at vivecode.com Thu May 17 21:17:56 2007 From: zhaojingmin at vivecode.com (Jing Min Zhao) Date: Fri May 18 20:22:19 2007 Subject: [PATCH 3/4] H.323: Remove unnecessary process of Information signal Message-ID: <20070517191756.D5C8C3DA1FA@jzhao.vivecode.com> According to the implementation of H.323, it's not necessary to check the addresses in Information signals. Signed-off-by: Jing Min Zhao --- net/netfilter/nf_conntrack_h323_main.c | 29 ----------------------------- 1 files changed, 0 insertions(+), 29 deletions(-) diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c index 8bb99b3..6d668af 100644 --- a/net/netfilter/nf_conntrack_h323_main.c +++ b/net/netfilter/nf_conntrack_h323_main.c @@ -977,30 +977,6 @@ static int process_alerting(struct sk_buff **pskb, struct nf_conn *ct, } /****************************************************************************/ -static int process_information(struct sk_buff **pskb, - struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, int dataoff, - Information_UUIE *info) -{ - int ret; - int i; - - DEBUGP("nf_ct_q931: Information\n"); - - if (info->options & eInformation_UUIE_fastStart) { - for (i = 0; i < info->fastStart.count; i++) { - ret = process_olc(pskb, ct, ctinfo, data, dataoff, - &info->fastStart.item[i]); - if (ret < 0) - return -1; - } - } - - return 0; -} - -/****************************************************************************/ static int process_facility(struct sk_buff **pskb, struct nf_conn *ct, enum ip_conntrack_info ctinfo, unsigned char **data, int dataoff, @@ -1096,11 +1072,6 @@ static int process_q931(struct sk_buff **pskb, struct nf_conn *ct, ret = process_alerting(pskb, ct, ctinfo, data, dataoff, &pdu->h323_message_body.alerting); break; - case eH323_UU_PDU_h323_message_body_information: - ret = process_information(pskb, ct, ctinfo, data, dataoff, - &pdu->h323_message_body. - information); - break; case eH323_UU_PDU_h323_message_body_facility: ret = process_facility(pskb, ct, ctinfo, data, dataoff, &pdu->h323_message_body.facility); -- 1.4.4.3 From zhaojingmin at vivecode.com Thu May 17 21:17:56 2007 From: zhaojingmin at vivecode.com (Jing Min Zhao) Date: Fri May 18 20:22:21 2007 Subject: [PATCH 2/4] H.323: update get_h225_addr() for IPv6 address access Message-ID: <20070517191756.A7F5F3DA1F9@jzhao.vivecode.com> Update get_h225_addr() to meet the changes in ASN.1 types. It was using field ip6 to access IPv6 TransportAddress, it should be ip according the ASN.1 definition. Signed-off-by: Jing Min Zhao --- net/netfilter/nf_conntrack_h323_main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c index b284db7..8bb99b3 100644 --- a/net/netfilter/nf_conntrack_h323_main.c +++ b/net/netfilter/nf_conntrack_h323_main.c @@ -640,7 +640,7 @@ int get_h225_addr(struct nf_conn *ct, unsigned char *data, case eTransportAddress_ip6Address: if (family != AF_INET6) return 0; - p = data + taddr->ip6Address.ip6; + p = data + taddr->ip6Address.ip; len = 16; break; default: -- 1.4.4.3 From zhaojingmin at vivecode.com Thu May 17 21:17:56 2007 From: zhaojingmin at vivecode.com (Jing Min Zhao) Date: Fri May 18 20:22:23 2007 Subject: [PATCH 1/4] H.323: update ASN.1 types Message-ID: <20070517191756.728953DA1F7@jzhao.vivecode.com> nf_conntrack_h323_types.h and nf_conntrack_h323_types.c have been updated. 1. Add support for decoding IPv6 address. I know it was manually added in the header file, but not in the template file. That wouldn't work. 2. Add missing support for decoding T.120 address in OLCA. 3. Remove unnecessary decoding of Information signal. Signed-off-by: Jing Min Zhao --- include/linux/netfilter/nf_conntrack_h323_types.h | 23 ++------------- net/netfilter/nf_conntrack_h323_types.c | 31 +++++++++------------ 2 files changed, 16 insertions(+), 38 deletions(-) diff --git a/include/linux/netfilter/nf_conntrack_h323_types.h b/include/linux/netfilter/nf_conntrack_h323_types.h index 38d74d5..f35b6b4 100644 --- a/include/linux/netfilter/nf_conntrack_h323_types.h +++ b/include/linux/netfilter/nf_conntrack_h323_types.h @@ -1,4 +1,4 @@ -/* Generated by Jing Min Zhao's ASN.1 parser, Apr 20 2006 +/* Generated by Jing Min Zhao's ASN.1 parser, May 16 2007 * * Copyright (c) 2006 Jing Min Zhao * @@ -12,7 +12,7 @@ typedef struct TransportAddress_ipAddress { /* SEQUENCE */ typedef struct TransportAddress_ip6Address { /* SEQUENCE */ int options; /* No use */ - unsigned ip6; + unsigned ip; } TransportAddress_ip6Address; typedef struct TransportAddress { /* CHOICE */ @@ -364,23 +364,6 @@ typedef struct Alerting_UUIE { /* SEQUENCE */ 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, @@ -471,7 +454,6 @@ typedef struct H323_UU_PDU_h323_message_body { /* CHOICE */ CallProceeding_UUIE callProceeding; Connect_UUIE connect; Alerting_UUIE alerting; - Information_UUIE information; Facility_UUIE facility; Progress_UUIE progress; }; @@ -561,6 +543,7 @@ typedef struct OpenLogicalChannelAck { /* SEQUENCE */ } options; OpenLogicalChannelAck_reverseLogicalChannelParameters reverseLogicalChannelParameters; + NetworkAccessParameters separateStack; OpenLogicalChannelAck_forwardMultiplexAckParameters forwardMultiplexAckParameters; } OpenLogicalChannelAck; diff --git a/net/netfilter/nf_conntrack_h323_types.c b/net/netfilter/nf_conntrack_h323_types.c index 4c6f8b3..3a21fdf 100644 --- a/net/netfilter/nf_conntrack_h323_types.c +++ b/net/netfilter/nf_conntrack_h323_types.c @@ -1,4 +1,4 @@ -/* Generated by Jing Min Zhao's ASN.1 parser, Apr 20 2006 +/* Generated by Jing Min Zhao's ASN.1 parser, May 16 2007 * * Copyright (c) 2006 Jing Min Zhao * @@ -37,7 +37,7 @@ static field_t _TransportAddress_ipxAddress[] = { /* SEQUENCE */ static field_t _TransportAddress_ip6Address[] = { /* SEQUENCE */ {FNAME("ip") OCTSTR, FIXD, 16, 0, DECODE, - offsetof(TransportAddress_ip6Address, ip6), NULL}, + offsetof(TransportAddress_ip6Address, ip), NULL}, {FNAME("port") INT, WORD, 0, 0, SKIP, 0, NULL}, }; @@ -67,7 +67,8 @@ static field_t _TransportAddress[] = { /* CHOICE */ {FNAME("ipxAddress") SEQ, 0, 3, 3, SKIP, 0, _TransportAddress_ipxAddress}, {FNAME("ip6Address") SEQ, 0, 2, 2, DECODE | EXT, - offsetof(TransportAddress, ip6Address), _TransportAddress_ip6Address}, + offsetof(TransportAddress, ip6Address), + _TransportAddress_ip6Address}, {FNAME("netBios") OCTSTR, FIXD, 16, 0, SKIP, 0, NULL}, {FNAME("nsap") OCTSTR, 5, 1, 0, SKIP, 0, NULL}, {FNAME("nonStandardAddress") SEQ, 0, 2, 2, SKIP, 0, @@ -638,7 +639,8 @@ static field_t _UnicastAddress_iPXAddress[] = { /* SEQUENCE */ }; static field_t _UnicastAddress_iP6Address[] = { /* SEQUENCE */ - {FNAME("network") OCTSTR, FIXD, 16, 0, SKIP, 0, NULL}, + {FNAME("network") OCTSTR, FIXD, 16, 0, DECODE, + offsetof(UnicastAddress_iP6Address, network), NULL}, {FNAME("tsapIdentifier") INT, WORD, 0, 0, SKIP, 0, NULL}, }; @@ -665,8 +667,8 @@ static field_t _UnicastAddress[] = { /* CHOICE */ offsetof(UnicastAddress, iPAddress), _UnicastAddress_iPAddress}, {FNAME("iPXAddress") SEQ, 0, 3, 3, SKIP | EXT, 0, _UnicastAddress_iPXAddress}, - {FNAME("iP6Address") SEQ, 0, 2, 2, SKIP | EXT, 0, - _UnicastAddress_iP6Address}, + {FNAME("iP6Address") SEQ, 0, 2, 2, DECODE | EXT, + offsetof(UnicastAddress, iP6Address), _UnicastAddress_iP6Address}, {FNAME("netBios") OCTSTR, FIXD, 16, 0, SKIP, 0, NULL}, {FNAME("iPSourceRouteAddress") SEQ, 0, 4, 4, SKIP | EXT, 0, _UnicastAddress_iPSourceRouteAddress}, @@ -984,19 +986,12 @@ static field_t _Alerting_UUIE[] = { /* SEQUENCE */ {FNAME("featureSet") SEQ, 3, 4, 4, SKIP | EXT | OPT, 0, NULL}, }; -static field_t _Information_UUIE_fastStart[] = { /* SEQUENCE OF */ - {FNAME("item") SEQ, 1, 3, 5, DECODE | OPEN | EXT, - sizeof(OpenLogicalChannel), _OpenLogicalChannel} - , -}; - static field_t _Information_UUIE[] = { /* SEQUENCE */ {FNAME("protocolIdentifier") OID, BYTE, 0, 0, SKIP, 0, NULL}, {FNAME("callIdentifier") SEQ, 0, 1, 1, SKIP | EXT, 0, NULL}, {FNAME("tokens") SEQOF, SEMI, 0, 0, SKIP | OPT, 0, NULL}, {FNAME("cryptoTokens") SEQOF, SEMI, 0, 0, SKIP | OPT, 0, NULL}, - {FNAME("fastStart") SEQOF, SEMI, 0, 30, DECODE | OPT, - offsetof(Information_UUIE, fastStart), _Information_UUIE_fastStart}, + {FNAME("fastStart") SEQOF, SEMI, 0, 30, SKIP | OPT, 0, NULL}, {FNAME("fastConnectRefused") NUL, FIXD, 0, 0, SKIP | OPT, 0, NULL}, {FNAME("circuitInfo") SEQ, 3, 3, 3, SKIP | EXT | OPT, 0, NULL}, }; @@ -1343,9 +1338,7 @@ static field_t _H323_UU_PDU_h323_message_body[] = { /* CHOICE */ offsetof(H323_UU_PDU_h323_message_body, connect), _Connect_UUIE}, {FNAME("alerting") SEQ, 1, 3, 17, DECODE | EXT, offsetof(H323_UU_PDU_h323_message_body, alerting), _Alerting_UUIE}, - {FNAME("information") SEQ, 0, 1, 7, DECODE | EXT, - offsetof(H323_UU_PDU_h323_message_body, information), - _Information_UUIE}, + {FNAME("information") SEQ, 0, 1, 7, SKIP | EXT, 0, _Information_UUIE}, {FNAME("releaseComplete") SEQ, 1, 2, 11, SKIP | EXT, 0, _ReleaseComplete_UUIE}, {FNAME("facility") SEQ, 3, 5, 21, DECODE | EXT, @@ -1430,7 +1423,9 @@ static field_t _OpenLogicalChannelAck[] = { /* SEQUENCE */ DECODE | EXT | OPT, offsetof(OpenLogicalChannelAck, reverseLogicalChannelParameters), _OpenLogicalChannelAck_reverseLogicalChannelParameters}, - {FNAME("separateStack") SEQ, 2, 4, 5, SKIP | EXT | OPT, 0, NULL}, + {FNAME("separateStack") SEQ, 2, 4, 5, DECODE | EXT | OPT, + offsetof(OpenLogicalChannelAck, separateStack), + _NetworkAccessParameters}, {FNAME("forwardMultiplexAckParameters") CHOICE, 0, 1, 1, DECODE | EXT | OPT, offsetof(OpenLogicalChannelAck, forwardMultiplexAckParameters), -- 1.4.4.3 From zhaojingmin at vivecode.com Thu May 17 21:17:57 2007 From: zhaojingmin at vivecode.com (Jing Min Zhao) Date: Fri May 18 20:22:24 2007 Subject: [PATCH 4/4] H.323: Check range first in sequence extension Message-ID: <20070517191757.1047E3DA1FB@jzhao.vivecode.com> Check range before checking STOP flag. This optimization may save a nanosecond or less :) Signed-off-by: Jing Min Zhao --- net/netfilter/nf_conntrack_h323_asn1.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/net/netfilter/nf_conntrack_h323_asn1.c b/net/netfilter/nf_conntrack_h323_asn1.c index f6fad71..ceb39bd 100644 --- a/net/netfilter/nf_conntrack_h323_asn1.c +++ b/net/netfilter/nf_conntrack_h323_asn1.c @@ -555,15 +555,6 @@ int decode_seq(bitstr_t * bs, field_t * f, char *base, int level) /* Decode the extension components */ for (opt = 0; opt < bmp2_len; opt++, i++, son++) { - if (i < f->ub && son->attr & STOP) { - PRINT("%*.s%s\n", (level + 1) * TAB_SIZE, " ", - son->name); - return H323_ERROR_STOP; - } - - if (!((0x80000000 >> opt) & bmp2)) /* Not present */ - continue; - /* Check Range */ if (i >= f->ub) { /* Newer Version? */ CHECK_BOUND(bs, 2); @@ -573,6 +564,15 @@ int decode_seq(bitstr_t * bs, field_t * f, char *base, int level) continue; } + if (son->attr & STOP) { + PRINT("%*.s%s\n", (level + 1) * TAB_SIZE, " ", + son->name); + return H323_ERROR_STOP; + } + + if (!((0x80000000 >> opt) & bmp2)) /* Not present */ + continue; + CHECK_BOUND(bs, 2); len = get_len(bs); CHECK_BOUND(bs, len); -- 1.4.4.3 From zhaojingmin at vivecode.com Thu May 17 22:00:33 2007 From: zhaojingmin at vivecode.com (Jing Min Zhao) Date: Fri May 18 20:22:25 2007 Subject: [PATCH] H.323: Add missing T.120 address in OLCA Message-ID: <20070517200033.B49F93DA1F7@jzhao.vivecode.com> Add missing process of T.120 address in OpenLogicalChannelAck signal. Signed-off-by: Jing Min Zhao --- net/netfilter/nf_conntrack_h323_main.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c index 6d668af..a1b95ac 100644 --- a/net/netfilter/nf_conntrack_h323_main.c +++ b/net/netfilter/nf_conntrack_h323_main.c @@ -520,6 +520,16 @@ static int process_olca(struct sk_buff **pskb, struct nf_conn *ct, } } + if ((olca->options & eOpenLogicalChannelAck_separateStack) && + olca->separateStack.networkAddress.choice == + eNetworkAccessParameters_networkAddress_localAreaAddress) { + ret = expect_t120(pskb, ct, ctinfo, data, dataoff, + &olca->separateStack.networkAddress. + localAreaAddress); + if (ret < 0) + return -1; + } + return 0; } -- 1.4.4.3 From zhaojingmin at vivecode.com Fri May 18 19:24:27 2007 From: zhaojingmin at vivecode.com (Jing Min Zhao) Date: Fri May 18 20:29:29 2007 Subject: [PATCH] H.323: Call set_h225_addr instead of set_h225_addr_hook Message-ID: <20070518172427.C45313DA1F7@jzhao.vivecode.com> They're the same. Signed-off-by: Jing Min Zhao --- net/ipv4/netfilter/nf_nat_h323.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/net/ipv4/netfilter/nf_nat_h323.c b/net/ipv4/netfilter/nf_nat_h323.c index fcebc96..c5d2a2d 100644 --- a/net/ipv4/netfilter/nf_nat_h323.c +++ b/net/ipv4/netfilter/nf_nat_h323.c @@ -455,9 +455,9 @@ static int nat_q931(struct sk_buff **pskb, struct nf_conn *ct, if (idx > 0 && get_h225_addr(ct, *data, &taddr[0], &addr, &port) && (ntohl(addr.ip) & 0xff000000) == 0x7f000000) { - set_h225_addr_hook(pskb, data, 0, &taddr[0], - &ct->tuplehash[!dir].tuple.dst.u3, - info->sig_port[!dir]); + set_h225_addr(pskb, data, 0, &taddr[0], + &ct->tuplehash[!dir].tuple.dst.u3, + info->sig_port[!dir]); } } else { nf_conntrack_unexpect_related(exp); -- 1.4.4.3 From davem at davemloft.net Sat May 19 23:24:38 2007 From: davem at davemloft.net (David Miller) Date: Sun May 20 00:26:33 2007 Subject: [NETFILTER 1/2]: nf_conntrack: fix use-after-free in helper destroy callback invocation In-Reply-To: <464B374D.5000205@trash.net> References: <464B374D.5000205@trash.net> Message-ID: <20070519.142438.75431615.davem@davemloft.net> From: Patrick McHardy Date: Wed, 16 May 2007 18:54:37 +0200 > These two patches fix an oops when unloading helper modules and > a incorrect config ifdef. > > Please apply, thanks. Both applied, thanks a lot Patrick. From misak at misak.dk Fri May 18 21:40:22 2007 From: misak at misak.dk (Morten Isaksen) Date: Sun May 20 20:52:53 2007 Subject: [PATCH] libnetfilter_conntrack bug in snprintf_xml.c Message-ID: <20070518194016.872D7A50020@pfepb.post.tele.dk> The port numbers are wrong in the XML output. Index: src/conntrack/snprintf_xml.c =================================================================== --- src/conntrack/snprintf_xml.c (revision 6832) +++ src/conntrack/snprintf_xml.c (working copy) @@ -182,13 +182,13 @@ case IPPROTO_SCTP: if (type == __ADDR_SRC) { ret = snprintf(buf, len, "%u", - tuple->l4src.tcp.port); + htons(tuple->l4src.tcp.port)); if (ret == -1) return -1; buffer_size(ret, &size, &len); } else { ret = snprintf(buf, len, "%u", - tuple->l4dst.tcp.port); + htons(tuple->l4dst.tcp.port)); if (ret == -1) return -1; buffer_size(ret, &size, &len); Regards Morten Isaksen http://misak.dk/blog/ From riesebie at lxtec.de Sun May 20 13:18:09 2007 From: riesebie at lxtec.de (Elimar Riesebieter) Date: Sun May 20 20:52:56 2007 Subject: 2.6.22-rc2 built on ppc Message-ID: <20070520111809.GG3253@aragorn.home.lxtec.de> Hi, FYI, building the kernel with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... ipc/msg.c: In function 'sys_msgctl': ipc/msg.c:390: warning: 'setbuf.qbytes' may be used uninitialized in this function ipc/msg.c:390: warning: 'setbuf.uid' may be used uninitialized in this function ipc/msg.c:390: warning: 'setbuf.gid' may be used uninitialized in this function ipc/msg.c:390: warning: 'setbuf.mode' may be used uninitialized in this function ipc/sem.c: In function 'sys_semctl': ipc/sem.c:861: warning: 'setbuf.uid' may be used uninitialized in this function ipc/sem.c:861: warning: 'setbuf.gid' may be used uninitialized in this function ipc/sem.c:861: warning: 'setbuf.mode' may be used uninitialized in this function ... If more info is needed, please contact me via PM, as I am not subscribed. Thanks for your patience Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) -------------- 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/20070520/eadd47ce/attachment.pgp From kaber at trash.net Sun May 20 19:48:30 2007 From: kaber at trash.net (Patrick McHardy) Date: Sun May 20 20:53:03 2007 Subject: 2.6.22-rc2 built on ppc In-Reply-To: <20070520111809.GG3253@aragorn.home.lxtec.de> References: <20070520111809.GG3253@aragorn.home.lxtec.de> Message-ID: <465089EE.6080406@trash.net> Elimar Riesebieter wrote: > FYI, building the kernel with > gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) > on my powerbook (PPC) gives: > ... > ipc/msg.c: In function 'sys_msgctl': > ipc/msg.c:390: warning: 'setbuf.qbytes' may be used uninitialized in this function > ipc/msg.c:390: warning: 'setbuf.uid' may be used uninitialized in this function > ipc/msg.c:390: warning: 'setbuf.gid' may be used uninitialized in this function > ipc/msg.c:390: warning: 'setbuf.mode' may be used uninitialized in this function > ipc/sem.c: In function 'sys_semctl': > ipc/sem.c:861: warning: 'setbuf.uid' may be used uninitialized in this function > ipc/sem.c:861: warning: 'setbuf.gid' may be used uninitialized in this function > ipc/sem.c:861: warning: 'setbuf.mode' may be used uninitialized in this function Probably just another bogus gcc warning. In any case it has nothing to do with netfilter. From pablo at netfilter.org Sun May 20 21:31:59 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sun May 20 22:31:45 2007 Subject: [PATCH] libnetfilter_conntrack bug in snprintf_xml.c In-Reply-To: <20070518194016.872D7A50020@pfepb.post.tele.dk> References: <20070518194016.872D7A50020@pfepb.post.tele.dk> Message-ID: <4650A22F.2060502@netfilter.org> Morten Isaksen wrote: > The port numbers are wrong in the XML output. > > Index: src/conntrack/snprintf_xml.c > =================================================================== > --- src/conntrack/snprintf_xml.c (revision 6832) > +++ src/conntrack/snprintf_xml.c (working copy) > @@ -182,13 +182,13 @@ > case IPPROTO_SCTP: > if (type == __ADDR_SRC) { > ret = snprintf(buf, len, "%u", > - tuple->l4src.tcp.port); > + htons(tuple->l4src.tcp.port)); ^^^ Thanks for spotting this, I just committed a patch to fix this problem. BTW, this should be ntohs, snprintf_default has the same stupid mistake. Anyway this doesn't affect anything since ntohs and htons do the same :) -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From frozenspot at gmail.com Mon May 21 21:44:47 2007 From: frozenspot at gmail.com (fender) Date: Mon May 21 22:47:03 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <7e36c7130705110600l35d6af11m3247eabd22621439@mail.gmail.com> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> <46432820.8040602@trash.net> <7e36c7130705110600l35d6af11m3247eabd22621439@mail.gmail.com> Message-ID: <7e36c7130705211244i45ad22depc62e476dff5f30ce@mail.gmail.com> Hi Patrick, On 5/11/07, fender wrote: > Hi Patrick, > > On 5/10/07, Patrick McHardy wrote: > > fender wrote: > > > This is the link: > > > > > > http://portknocko.berlios.de/pom-ng/ > > > > > > Added to sources.list, thanks. > > I thought that you have read the last mail. This link doesn't work, > because the berlios repository doesn't let me to put external files > (the tarball). > > I will try with another server and I will send you the new link to the tarball. > This is the new link to the tarball: http://www.lugmen.org.ar/files/ http://www.lugmen.org.ar/files/index http://www.lugmen.org.ar/files/pom-ng-ipt_pknock.tgz Regards, -- J. Federico Hernandez From henrik at henriknordstrom.net Tue May 22 00:09:47 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Tue May 22 01:12:10 2007 Subject: MAC address update In-Reply-To: <00d401c797ff$b2f60230$9f0201c0@nethawk.fi> References: <00d401c797ff$b2f60230$9f0201c0@nethawk.fi> Message-ID: <1179785387.12033.9.camel@henriknordstrom.net> ons 2007-05-16 klockan 16:18 -0500 skrev Sarbeswar Mohapatra: > Hi, > I am using netfilter hook (NF_POST_ROUTING) to create IP tunnel. In the nf > hook function, the skb is expanded and added a new IP header (IP tunnel). Hmm.. shouldn't this be done before routing? After routing the kernel has already decided which next-hop the packet should be sent to. If you change this after the routing is done you need to re-route the packet, the kernel won't notice otherwise. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070522/0b8ca28b/attachment-0001.pgp From Darren.Reed at Sun.COM Tue May 22 00:27:05 2007 From: Darren.Reed at Sun.COM (Darren.Reed@Sun.COM) Date: Tue May 22 01:29:24 2007 Subject: Developing a user space library for filtering Message-ID: <46521CB9.2040309@Sun.COM> Hi, One of the core problems I see as people want to more and more with firewall/NAT technology is integrate using it into their application (whatever that may be.) As time goes by, this problem is becoming more and more acute and perhaps is doing us (those who develop said technologies) a disservice by making the "barrier to entry" too high. Currently, to interact with filtering software inside the kernel requires developers to build their application against whatever specific version of the filtering software runs in the kernel. For application developers, this is a PITA. What they want to see is the equivalent of a libc for firewalls with functions that have a similar stability to the likes of "fopen", "printf", etc. And therein lies the problem. Nothing currently exists, so if you engage in developing for any one particular firewall/NAT product then you wed yourself to using that product. Not a great place to be if you're the 3rd party. This problem/situation is one that I believe needs to be improved. Is anyone in the Linux netfilter community currently engaged on working on anything to address this problem? If there isn't, can I ask if anyone would be interested in being involved in designing and implementing a new library where the primary focus or target is going to be 3rd party developers that want to build applications on top of netfilter, etc? It is important to understand that my focus isn't just on netfilter or iptables, but also includes ipf/ipfw/pf and potentially others too if people become interested. The end goal isn't to build something that userland tools would be rewritten to use (although ostensible they could), just to provide what those on the outside need in order to build apps that are both portable and functional. Darren From c-d.hailfinger.devel.2006 at gmx.net Tue May 22 00:47:02 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue May 22 01:49:14 2007 Subject: Developing a user space library for filtering In-Reply-To: <46521CB9.2040309@Sun.COM> References: <46521CB9.2040309@Sun.COM> Message-ID: <46522166.1090603@gmx.net> Hi Darren, On 22.05.2007 00:27, Darren.Reed@Sun.COM wrote: > > One of the core problems I see as people want to more and > more with firewall/NAT technology is integrate using it into > their application (whatever that may be.) As time goes by, > this problem is becoming more and more acute and perhaps > is doing us (those who develop said technologies) a disservice > by making the "barrier to entry" too high. Sorry if I'm being dense. Do you want to target firewall frontends or applications which have the desire to punch holes into the firewall? > Currently, to interact with filtering software inside the kernel > requires developers to build their application against whatever > specific version of the filtering software runs in the kernel. For > application developers, this is a PITA. What they want to see is > the equivalent of a libc for firewalls with functions that have a > similar stability to the likes of "fopen", "printf", etc. > > And therein lies the problem. Nothing currently exists, so if you > engage in developing for any one particular firewall/NAT product > then you wed yourself to using that product. Not a great place > to be if you're the 3rd party. Maybe you're looking for the firewalling side of UPnP? Regards, Carl-Daniel From Darren.Reed at Sun.COM Tue May 22 00:52:48 2007 From: Darren.Reed at Sun.COM (Darren.Reed@Sun.COM) Date: Tue May 22 01:55:05 2007 Subject: Developing a user space library for filtering In-Reply-To: <46522166.1090603@gmx.net> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> Message-ID: <465222C0.8050601@Sun.COM> Carl-Daniel Hailfinger wrote: >Hi Darren, > >On 22.05.2007 00:27, Darren.Reed@Sun.COM wrote: > > >>One of the core problems I see as people want to more and >>more with firewall/NAT technology is integrate using it into >>their application (whatever that may be.) As time goes by, >>this problem is becoming more and more acute and perhaps >>is doing us (those who develop said technologies) a disservice >>by making the "barrier to entry" too high. >> >> > >Sorry if I'm being dense. Do you want to target firewall frontends >or applications which have the desire to punch holes into the >firewall? > > Neither. Applications that sit on top of firewall software. As an example, using squid on your Linux firewall/router in transparent proxying mode requires that squid has some code in it that knows how to talk to Linux in order to discover the original destination and change the outgoing connection such that the original address is used again. Doing that requires specific knowledge of the API that netfilter/iptables uses. Another example might be IDS software running on your Linux firewall/router. If that detects an attack, it should be able to talk to netfilter/iptables and do "something" to mitigate it. In both cases I'd like to see something developed such that the 3rd party applications don't need to know what NAT or firewall technology is being used. Darren From pablo at netfilter.org Tue May 22 01:13:44 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue May 22 02:16:01 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <7e36c7130705211244i45ad22depc62e476dff5f30ce@mail.gmail.com> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <4639C110.6000407@trash.net> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> <46432820.8040602@trash.net> <7e36c7130705110600l35d6af11m3247eabd22621439@mail.gmail.com> <7e36c7130705211244i45ad22depc62e476dff5f30ce@mail.gmail.com> Message-ID: <465227A8.8030105@netfilter.org> fender wrote: > This is the new link to the tarball: > > http://www.lugmen.org.ar/files/ > > http://www.lugmen.org.ar/files/index > http://www.lugmen.org.ar/files/pom-ng-ipt_pknock.tgz We're close to get it done. I just added your source to source.list, however ./runme --download complains with "could not get http://www.lugmen.org.ar/files//pknock.tar.gz". Please, fix the problem and contact us again. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From Sarbeswar.Mohapatra at nethawkgroup.com Tue May 22 02:26:43 2007 From: Sarbeswar.Mohapatra at nethawkgroup.com (Sarbeswar Mohapatra) Date: Tue May 22 03:28:59 2007 Subject: MAC address update In-Reply-To: <1179785387.12033.9.camel@henriknordstrom.net> Message-ID: <004301c79c07$e0b2d930$6502a8c0@nethawk.fi> Hi Henrik, Thanks for your response. I already figured that out before leaving the nf hook function, I had to update the routing and got it working. Regards, Sarbeswar Sarbeswar Mohapatra NetHawk Corp 3400 Waterview Pkwy Suite 100 Richardson, TX - 75080 Email: Sarbeswar.Mohapatra@nethawkgroup.com Tel: +1 972 761 9271 Ext. 299 CELL: +1 214 682 5645 FAX: +1 972 761 9067 -----Original Message----- From: Henrik Nordstrom [mailto:henrik@henriknordstrom.net] Sent: Monday, May 21, 2007 5:10 PM To: Sarbeswar Mohapatra Cc: netfilter-devel@lists.netfilter.org Subject: Re: MAC address update ons 2007-05-16 klockan 16:18 -0500 skrev Sarbeswar Mohapatra: > Hi, > I am using netfilter hook (NF_POST_ROUTING) to create IP tunnel. In > the nf hook function, the skb is expanded and added a new IP header (IP tunnel). Hmm.. shouldn't this be done before routing? After routing the kernel has already decided which next-hop the packet should be sent to. If you change this after the routing is done you need to re-route the packet, the kernel won't notice otherwise. Regards Henrik From chrisw at sous-sol.org Mon May 21 21:17:17 2007 From: chrisw at sous-sol.org (Chris Wright) Date: Tue May 22 04:40:32 2007 Subject: [patch 65/69] NETFILTER: {ip, nf}_conntrack: fix use-after-free in helper destroy callback invocation References: <20070521191612.800400000@sous-sol.org> Message-ID: <20070521191755.954599000@sous-sol.org> -stable review patch. If anyone has any objections, please let us know. --------------------- From: Patrick McHardy When the helper module is removed for a master connection that has a fulfilled expectation, but has already timed out and got removed from the hash tables, nf_conntrack_helper_unregister can't find the master connection to unset the helper, causing a use-after-free when the expected connection is destroyed and releases the last reference to the master. The helper destroy callback was introduced for the PPtP helper to clean up expectations and expected connections when the master connection times out, but doing this from destroy_conntrack only works for unfulfilled expectations since expected connections hold a reference to the master, preventing its destruction. Move the destroy callback to the timeout function, which fixes both problems. Reported/tested by Gabor Burjan . Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright --- commit 441f15ce23ef5c4d149b7e7985f63c1ddd334c45 tree 8783e067803def0fc2773ef3515190143ac47320 parent 8d8b10482fffcb72b15515231bb942e2ad6395c9 author Patrick McHardy Wed, 16 May 2007 18:52:36 +0200 committer Patrick McHardy Wed, 16 May 2007 18:52:36 +0200 net/ipv4/netfilter/ip_conntrack_core.c | 10 +++++----- net/netfilter/nf_conntrack_core.c | 8 ++++---- 2 files changed, 9 insertions(+), 9 deletions(-) --- linux-2.6.21.1.orig/net/ipv4/netfilter/ip_conntrack_core.c +++ linux-2.6.21.1/net/ipv4/netfilter/ip_conntrack_core.c @@ -302,7 +302,6 @@ destroy_conntrack(struct nf_conntrack *n { struct ip_conntrack *ct = (struct ip_conntrack *)nfct; struct ip_conntrack_protocol *proto; - struct ip_conntrack_helper *helper; typeof(ip_conntrack_destroyed) destroyed; DEBUGP("destroy_conntrack(%p)\n", ct); @@ -312,10 +311,6 @@ destroy_conntrack(struct nf_conntrack *n ip_conntrack_event(IPCT_DESTROY, ct); set_bit(IPS_DYING_BIT, &ct->status); - helper = ct->helper; - if (helper && helper->destroy) - helper->destroy(ct); - /* To make sure we don't get any weird locking issues here: * destroy_conntrack() MUST NOT be called with a write lock * to ip_conntrack_lock!!! -HW */ @@ -356,6 +351,11 @@ destroy_conntrack(struct nf_conntrack *n static void death_by_timeout(unsigned long ul_conntrack) { struct ip_conntrack *ct = (void *)ul_conntrack; + struct ip_conntrack_helper *helper; + + helper = ct->helper; + if (helper && helper->destroy) + helper->destroy(ct); write_lock_bh(&ip_conntrack_lock); /* Inside lock so preempt is disabled on module removal path. --- linux-2.6.21.1.orig/net/netfilter/nf_conntrack_core.c +++ linux-2.6.21.1/net/netfilter/nf_conntrack_core.c @@ -315,7 +315,6 @@ static void destroy_conntrack(struct nf_conntrack *nfct) { struct nf_conn *ct = (struct nf_conn *)nfct; - struct nf_conn_help *help = nfct_help(ct); struct nf_conntrack_l3proto *l3proto; struct nf_conntrack_l4proto *l4proto; typeof(nf_conntrack_destroyed) destroyed; @@ -327,9 +326,6 @@ destroy_conntrack(struct nf_conntrack *n nf_conntrack_event(IPCT_DESTROY, ct); set_bit(IPS_DYING_BIT, &ct->status); - if (help && help->helper && help->helper->destroy) - help->helper->destroy(ct); - /* To make sure we don't get any weird locking issues here: * destroy_conntrack() MUST NOT be called with a write lock * to nf_conntrack_lock!!! -HW */ @@ -375,6 +371,10 @@ destroy_conntrack(struct nf_conntrack *n static void death_by_timeout(unsigned long ul_conntrack) { struct nf_conn *ct = (void *)ul_conntrack; + struct nf_conn_help *help = nfct_help(ct); + + if (help && help->helper && help->helper->destroy) + help->helper->destroy(ct); write_lock_bh(&nf_conntrack_lock); /* Inside lock so preempt is disabled on module removal path. -- From chrisw at sous-sol.org Thu May 17 03:54:26 2007 From: chrisw at sous-sol.org (chrisw@sous-sol.org) Date: Tue May 22 04:40:36 2007 Subject: patch netfilter-ip-nf-_conntrack-fix-use-after-free-in-helper-destroy-callback-invocation.patch queued to 2.6.21-stable tree In-Reply-To: <464B37AB.5040802@trash.net> Message-ID: <200705170154.l4H1sRw1019014@sous-sol.org> This is a note to let you know that we have just queued up the patch titled Subject: NETFILTER: {ip,nf}_conntrack: fix use-after-free in helper destroy callback invocation to the 2.6.21-stable tree. Its filename is netfilter-ip-nf-_conntrack-fix-use-after-free-in-helper-destroy-callback-invocation.patch A git repo of this tree can be found at http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary >From stable-bounces@linux.kernel.org Wed May 16 09:58:34 2007 Message-ID: <464B37AB.5040802@trash.net> Date: Wed, 16 May 2007 18:56:11 +0200 From: Patrick McHardy To: stable@kernel.org Cc: Netfilter Development Mailinglist , "David S. Miller" Subject: NETFILTER: {ip,nf}_conntrack: fix use-after-free in helper destroy callback invocation When the helper module is removed for a master connection that has a fulfilled expectation, but has already timed out and got removed from the hash tables, nf_conntrack_helper_unregister can't find the master connection to unset the helper, causing a use-after-free when the expected connection is destroyed and releases the last reference to the master. The helper destroy callback was introduced for the PPtP helper to clean up expectations and expected connections when the master connection times out, but doing this from destroy_conntrack only works for unfulfilled expectations since expected connections hold a reference to the master, preventing its destruction. Move the destroy callback to the timeout function, which fixes both problems. Reported/tested by Gabor Burjan . Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright --- commit 441f15ce23ef5c4d149b7e7985f63c1ddd334c45 tree 8783e067803def0fc2773ef3515190143ac47320 parent 8d8b10482fffcb72b15515231bb942e2ad6395c9 author Patrick McHardy Wed, 16 May 2007 18:52:36 +0200 committer Patrick McHardy Wed, 16 May 2007 18:52:36 +0200 net/ipv4/netfilter/ip_conntrack_core.c | 10 +++++----- net/netfilter/nf_conntrack_core.c | 8 ++++---- 2 files changed, 9 insertions(+), 9 deletions(-) --- linux-2.6.21.1.orig/net/ipv4/netfilter/ip_conntrack_core.c +++ linux-2.6.21.1/net/ipv4/netfilter/ip_conntrack_core.c @@ -302,7 +302,6 @@ destroy_conntrack(struct nf_conntrack *n { struct ip_conntrack *ct = (struct ip_conntrack *)nfct; struct ip_conntrack_protocol *proto; - struct ip_conntrack_helper *helper; typeof(ip_conntrack_destroyed) destroyed; DEBUGP("destroy_conntrack(%p)\n", ct); @@ -312,10 +311,6 @@ destroy_conntrack(struct nf_conntrack *n ip_conntrack_event(IPCT_DESTROY, ct); set_bit(IPS_DYING_BIT, &ct->status); - helper = ct->helper; - if (helper && helper->destroy) - helper->destroy(ct); - /* To make sure we don't get any weird locking issues here: * destroy_conntrack() MUST NOT be called with a write lock * to ip_conntrack_lock!!! -HW */ @@ -356,6 +351,11 @@ destroy_conntrack(struct nf_conntrack *n static void death_by_timeout(unsigned long ul_conntrack) { struct ip_conntrack *ct = (void *)ul_conntrack; + struct ip_conntrack_helper *helper; + + helper = ct->helper; + if (helper && helper->destroy) + helper->destroy(ct); write_lock_bh(&ip_conntrack_lock); /* Inside lock so preempt is disabled on module removal path. --- linux-2.6.21.1.orig/net/netfilter/nf_conntrack_core.c +++ linux-2.6.21.1/net/netfilter/nf_conntrack_core.c @@ -315,7 +315,6 @@ static void destroy_conntrack(struct nf_conntrack *nfct) { struct nf_conn *ct = (struct nf_conn *)nfct; - struct nf_conn_help *help = nfct_help(ct); struct nf_conntrack_l3proto *l3proto; struct nf_conntrack_l4proto *l4proto; typeof(nf_conntrack_destroyed) destroyed; @@ -327,9 +326,6 @@ destroy_conntrack(struct nf_conntrack *n nf_conntrack_event(IPCT_DESTROY, ct); set_bit(IPS_DYING_BIT, &ct->status); - if (help && help->helper && help->helper->destroy) - help->helper->destroy(ct); - /* To make sure we don't get any weird locking issues here: * destroy_conntrack() MUST NOT be called with a write lock * to nf_conntrack_lock!!! -HW */ @@ -375,6 +371,10 @@ destroy_conntrack(struct nf_conntrack *n static void death_by_timeout(unsigned long ul_conntrack) { struct nf_conn *ct = (void *)ul_conntrack; + struct nf_conn_help *help = nfct_help(ct); + + if (help && help->helper && help->helper->destroy) + help->helper->destroy(ct); write_lock_bh(&nf_conntrack_lock); /* Inside lock so preempt is disabled on module removal path. Patches currently in stable-queue which might be from kaber@trash.net are queue-2.6.21/ip-nf-_nat_proto_gre-do-not-modify-corrupt-grev0-packets-through-nat.patch queue-2.6.21/netfilter-ip-nf-_conntrack-fix-use-after-free-in-helper-destroy-callback-invocation.patch From jengelh at linux01.gwdg.de Tue May 22 08:27:25 2007 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Tue May 22 09:30:27 2007 Subject: Developing a user space library for filtering In-Reply-To: <465222C0.8050601@Sun.COM> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> Message-ID: On May 21 2007 15:52, Darren.Reed@Sun.COM wrote: >> >> Sorry if I'm being dense. Do you want to target firewall frontends >> or applications which have the desire to punch holes into the >> firewall? > > Neither. Applications that sit on top of firewall software. > > As an example, using squid on your Linux firewall/router in > transparent proxying mode requires that squid has some code > in it that knows how to talk to Linux in order to discover the > original destination As with most client-side transparent proxies, it uses the Host: header. > and change the outgoing connection > such that the original address is used again. Doing that > requires specific knowledge of the API that netfilter/iptables > uses. Jan -- From bof at bof.de Tue May 22 08:46:13 2007 From: bof at bof.de (Patrick Schaaf) Date: Tue May 22 09:48:27 2007 Subject: Developing a user space library for filtering In-Reply-To: References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> Message-ID: <20070522064613.GA27619@oknodo.bof.de> > > As an example, using squid on your Linux firewall/router in > > transparent proxying mode requires that squid has some code > > in it that knows how to talk to Linux in order to discover the > > original destination > > As with most client-side transparent proxies, it uses the Host: header. And when the Host: header is missing, it uses the SO_GET_ORIGINAL_DESTINATION getsockopt call, a speciality of netfilter, as described by the $OP above. Anyway, regarding the original request, I don't think it is sensible to expect from netfilter developers to invent such a library, especially when the scope is desired to be abstracting from netfilter. As an analogy, it was neither Microsoft nor Unix vendors that invented the Apache Runtime Library, it was the Apache developers. Bringing back that analogy, it would be a task for the developers of a vastly successful high level firewall application running on all kinds of basic firewalls. Personally, I think that it would be bound to fail anyway, because different basic firewall structures are very different in what and how they operate. But that's just the fast opinion of somebody who has neither need nor vision for userlevel firewall applications and systems other than Linux/netfilter. best regards Patrick From aef at prismnet.com Tue May 22 09:11:47 2007 From: aef at prismnet.com (Allen Francom) Date: Tue May 22 10:14:10 2007 Subject: Developing a user space library for filtering In-Reply-To: <465222C0.8050601@Sun.COM> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> Message-ID: <20070522020457.M92606@tempest.prismnet.com> I worked a little bit with "Hogwash". http://hogwash.sourceforge.net/docs/overview.html This was a mangling of IDS/Snort into layer 2 for real-time filtering. With a little help from my friends there I got an IPTables "target" so that IPTables could direct traffic into the hogwash/snort. I like it that you said "libc". It would be nice to intercept traffic after stream reassembly which was always a problem. In that case what you're asking makes maybe more sense to focus on "libc" itself and having an "intercept" there. That way you could for example filter stream-reassembled data coming into a web server, or not, depending on the "rules engine" deciding to catch the traffic or not. I always thought that would be the place to be, in the call to get data, but hookable, like a library with a hook that checks to see if it should be "scrubbing" incoming traffic on a particular port. "Slick" is the word. Word. ;) -AEF On Mon, 21 May 2007, Darren.Reed@Sun.COM wrote: > Carl-Daniel Hailfinger wrote: > >> Hi Darren, >> >> On 22.05.2007 00:27, Darren.Reed@Sun.COM wrote: >> >>> One of the core problems I see as people want to more and >>> more with firewall/NAT technology is integrate using it into >>> their application (whatever that may be.) As time goes by, >>> this problem is becoming more and more acute and perhaps >>> is doing us (those who develop said technologies) a disservice >>> by making the "barrier to entry" too high. >>> >> >> Sorry if I'm being dense. Do you want to target firewall frontends >> or applications which have the desire to punch holes into the >> firewall? >> > > Neither. Applications that sit on top of firewall software. > > As an example, using squid on your Linux firewall/router in > transparent proxying mode requires that squid has some code > in it that knows how to talk to Linux in order to discover the > original destination and change the outgoing connection > such that the original address is used again. Doing that > requires specific knowledge of the API that netfilter/iptables > uses. > > Another example might be IDS software running on your Linux > firewall/router. If that detects an attack, it should be able to > talk to netfilter/iptables and do "something" to mitigate it. > > In both cases I'd like to see something developed such that > the 3rd party applications don't need to know what NAT or > firewall technology is being used. > > Darren > > > From yuhaitao at tsinghua.org.cn Tue May 22 08:24:37 2007 From: yuhaitao at tsinghua.org.cn (YU, Haitao) Date: Tue May 22 13:04:41 2007 Subject: bugs in ftp conntrack Message-ID: <379815077.04066@tsinghua.org.cn> Hi, If the order of ftp packets are wrong, function find_nl_seq() in net/ipv4/netfilter/ip_conntrack_ftp.c will make mistake. i.e., consider three ftp packets: "port", "list" and "noop", if the "list" and "noop" packets reach firewall before "port" packet, then info->seq_aft_nl will record the sequence of "noop". Kenerl will not parse "port" packet because the seq does not match the recored one . If kernel can't trace expect connection, then the attack described in [phrack-63, 0x13] will happen. Another problem is if the packet length is changed bye NAT, then the next packet will not be parsed. So kernel can not parse the 2nd "port" packet of two continual "port" packets. Though it's impossible in legal ftp connection, and I also don't know how to use this to hack firewall. Third, the value of "oldest" in function udpate_bl_seq() seem unchanged after four packets. Regards, YU, haitao From pablo at netfilter.org Tue May 22 19:00:01 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue May 22 20:02:22 2007 Subject: [ANNOUNCE] Release libnfnetlink_conntrack Message-ID: <46532191.3050705@netfilter.org> Hi! The netfilter project proudly presents libnetfilter_conntrack-0.0.75 libnetfilter_conntrack is a userspace library providing a programming interface (API) to the in-kernel connection tracking state table. You can download it from: http://www.netfilter.org/projects/libnetfilter_conntrack/files/libnetfilter_conntrack-0.0.75.tar.bz2 Happy tracking, Pablo (on behalf of the Netfilter Project) -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris -------------- next part -------------- libnetfilter_conntrack 0.0.75 ====================================================================== Changes from 0.0.50: - Fix inconsistency in the status flags bits [Pablo Neira] - Fix icmp_id setter and documentation [Phil Dibowitz] - Fix compilation with old glibc versions [Thomas Jarosch] - Fix inconsistency in the behaviour of nfct_set_attr with ATTR_STATUS [Pablo Neira] - Relax checkings in the NAT detector functions [Pablo Neira] - Fix wrong documentation in nfct_get_attr_u[*] [Pablo Neira] - introduce new expectation API [Pablo Neira] - fix wrong port display in the XML output [Morten Isaksen] - use ntohs instead htons in snprintf_default.c [Pablo Neira] - introduce examples files under utils/, remove old deprecated API test file [Pablo Neira] From Darren.Reed at Sun.COM Tue May 22 22:50:20 2007 From: Darren.Reed at Sun.COM (Darren.Reed@Sun.COM) Date: Tue May 22 23:53:04 2007 Subject: Developing a user space library for filtering In-Reply-To: <20070522064613.GA27619@oknodo.bof.de> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> <20070522064613.GA27619@oknodo.bof.de> Message-ID: <4653578C.3070407@Sun.COM> Patrick Schaaf wrote: >... >Anyway, regarding the original request, I don't think it is sensible to >expect from netfilter developers to invent such a library, especially >when the scope is desired to be abstracting from netfilter. > At this point in time, I was looking for people who might be interested in helping design such an API. In the end, what I'm hoping for is to have a common API delivered as part of OpenSolaris as well as both FreeBSD and NetBSD. Given that it's still being drafted, I'm opening the door and asking if there is anyone from Linux who's interested in participating. I should point out that I'm not interested in requesting anyone here write code that isn't [L]GPL'd. ... > Bringing back that >analogy, it would be a task for the developers of a vastly successful >high level firewall application running on all kinds of basic firewalls. > > Why should they have to do that? That requires: 1) they understand the API of every firewall they support 2) to track the API changes of every firewall they support 3) recompile/redeliver their software every time that API changes None of those 3 options are what I would call palatable. Imagine if everytime a new glibc was delivered you needed to recompile all of your programs, from ls all the way through to the X server, or... >Personally, I think that it would be bound to fail anyway, because >different basic firewall structures are very different in what and >how they operate. But that's just the fast opinion of somebody who >has neither need nor vision for userlevel firewall applications >and systems other than Linux/netfilter. > > The point of this is to understand that the low level/basic structures of firewall software are quite different but the "end goal" is the same. For example, all firewalls let you say "block traffic between X & Y", it is just how that is done which is different. The idea is to capture the high level goals (c.f. "block ..") into an API that applications can use. Darren From misak at misak.dk Tue May 22 23:02:42 2007 From: misak at misak.dk (Morten Isaksen) Date: Wed May 23 00:05:01 2007 Subject: libnfnetlink_conntrack performance Message-ID: <7194302c0705221402k14bfe9eco7ecc98910eaa1c87@mail.gmail.com> Hi! Do anyone have som experience with the performance of libnfnetlink_conntrack? I am using it to track and log NFCT_T_NEW and NFCT_T_DESTROY events. I am testing it on a firewall with about 15 Mbit/s traffic and 18-22K entries in ip_conntrack. The only difference I can spot so far is 300 more context switches pr. sec than usual. The events are collected in batches of 7 and then sent in an UDP packet to a log server. -- Morten Isaksen http://www.misak.dk/blog/ From phil at ipom.com Tue May 22 23:14:04 2007 From: phil at ipom.com (Phil Dibowitz) Date: Wed May 23 00:16:36 2007 Subject: Developing a user space library for filtering In-Reply-To: <4653578C.3070407@Sun.COM> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> <20070522064613.GA27619@oknodo.bof.de> <4653578C.3070407@Sun.COM> Message-ID: <20070522211404.GC24990@ipom.com> On Tue, May 22, 2007 at 01:50:20PM -0700, Darren.Reed@Sun.COM wrote: > Patrick Schaaf wrote: > > >... > >Anyway, regarding the original request, I don't think it is sensible to > >expect from netfilter developers to invent such a library, especially > >when the scope is desired to be abstracting from netfilter. > > > > At this point in time, I was looking for people who might be interested > in helping design such an API. In the end, what I'm hoping for is to > have a common API delivered as part of OpenSolaris as well as both > FreeBSD and NetBSD. Given that it's still being drafted, I'm opening > the door and asking if there is anyone from Linux who's interested in > participating. I should point out that I'm not interested in requesting > anyone here write code that isn't [L]GPL'd. Actually the netfilter folks wrote an entire infrastructure for just this purpose. netfilter is a generic infrastructure for firewall software with a defined kernel-user API and they're now writing many libraries on top of that. My software, iptstate, uses libnetfilter-conntrack, which is built upon the netfilter framework. All this is not to be confused with iptables, which is simply an implmentation of netfilter coincidentally written by the same people who write the netfilter framework. Or so I understand it. > None of those 3 options are what I would call palatable. > > Imagine if everytime a new glibc was delivered you needed to > recompile all of your programs, from ls all the way through to the > X server, or... Darren, you're correct, this is definitely needed. If IPF and IPtables and everyone else all used a common core kernel-userspace API, with a standard library on top of it, that would be awesome. Netfilter brings a lot of of this to the table, but the people involved in writing the specs mostly worked on ipchains, and iptables, so they may have made linux-specific assumptions without realizing it - but it was very much purposed to be OS-agnostic. -- Phil Dibowitz phil@ipom.com Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming -------------- 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/20070523/c6cf61b1/attachment.pgp From henrik at henriknordstrom.net Wed May 23 00:58:18 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Wed May 23 02:00:42 2007 Subject: Developing a user space library for filtering In-Reply-To: <20070522211404.GC24990@ipom.com> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> <20070522064613.GA27619@oknodo.bof.de> <4653578C.3070407@Sun.COM> <20070522211404.GC24990@ipom.com> Message-ID: <1179874698.18674.22.camel@henriknordstrom.net> tis 2007-05-22 klockan 14:14 -0700 skrev Phil Dibowitz: > Darren, you're correct, this is definitely needed. If IPF and IPtables and > everyone else all used a common core kernel-userspace API, with a standard > library on top of it, that would be awesome. As things is today I am not sure how this would work in a general sense for what is proposed. The way you structure rules is quite different in the different firewall implementations. But sure, for things like connection tracking and related events it's surely doable. Also, writing a generic firewall ruleset "compiler" which can translate to ipf, iptables and a few others is doable, but the actual installed ruleset will need to be somewhat different in both structure and syntax in the different implementations, not only syntax. Having an API which says things like "Add a rule to accept this kind of traffic" is only possible cross the different firewall implementations if there also is a defined firewall ruleset structure requirement defining suitable places in the ruleset where this API can make it's modifications. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070523/0397aead/attachment-0001.pgp From Darren.Reed at Sun.COM Wed May 23 01:55:07 2007 From: Darren.Reed at Sun.COM (Darren.Reed@Sun.COM) Date: Wed May 23 02:57:40 2007 Subject: Developing a user space library for filtering In-Reply-To: <1179874698.18674.22.camel@henriknordstrom.net> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> <20070522064613.GA27619@oknodo.bof.de> <4653578C.3070407@Sun.COM> <20070522211404.GC24990@ipom.com> <1179874698.18674.22.camel@henriknordstrom.net> Message-ID: <465382DB.3080106@Sun.COM> Henrik Nordstrom wrote: >tis 2007-05-22 klockan 14:14 -0700 skrev Phil Dibowitz: > > > >>Darren, you're correct, this is definitely needed. If IPF and IPtables and >>everyone else all used a common core kernel-userspace API, with a standard >>library on top of it, that would be awesome. >> >> > >As things is today I am not sure how this would work in a general sense >for what is proposed. The way you structure rules is quite different in >the different firewall implementations. > >But sure, for things like connection tracking and related events it's >surely doable. Also, writing a generic firewall ruleset "compiler" which >can translate to ipf, iptables and a few others is doable, but the >actual installed ruleset will need to be somewhat different in both >structure and syntax in the different implementations, not only syntax. > >Having an API which says things like "Add a rule to accept this kind of >traffic" is only possible cross the different firewall implementations >if there also is a defined firewall ruleset structure requirement >defining suitable places in the ruleset where this API can make it's >modifications. > > Which means that coming up with a design that works won't necessarily be a slam-dunk. Darren From philipc at snapgear.com Wed May 23 02:29:27 2007 From: philipc at snapgear.com (Philip Craig) Date: Wed May 23 04:03:14 2007 Subject: Developing a user space library for filtering In-Reply-To: <465382DB.3080106@Sun.COM> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> <20070522064613.GA27619@oknodo.bof.de> <4653578C.3070407@Sun.COM> <20070522211404.GC24990@ipom.com> <1179874698.18674.22.camel@henriknordstrom.net> <465382DB.3080106@Sun.COM> Message-ID: <46538AE7.8040405@snapgear.com> Darren.Reed@Sun.COM wrote: > Henrik Nordstrom wrote: >> Having an API which says things like "Add a rule to accept this kind of >> traffic" is only possible cross the different firewall implementations >> if there also is a defined firewall ruleset structure requirement >> defining suitable places in the ruleset where this API can make it's >> modifications. >> >> > > Which means that coming up with a design that works won't > necessarily be a slam-dunk. It means the API must an interface to a firewall policy, not to a kernel mechanism. For example, the API should enable you to tell shorewall that you want to accept something, rather than directly generating an iptables rule. (Although a simple implementation for the case where you have no firewall policy may directly generate an iptables rule.) From andang76 at gmail.com Wed May 23 09:47:02 2007 From: andang76 at gmail.com (Andrea) Date: Wed May 23 10:49:18 2007 Subject: problems applying ipset patch Message-ID: <4653F176.4040604@gmail.com> I've tried to apply the ipset patch in my CentOS 4.4 distribution, without success. I've followed instructions here http://www.howtoforge.com/kernel_compilation_centos_p2?s=aabdb730a09fa747d00f2b9a3ff431cc& (CentOS Kernel Compile) and here http://ipset.netfilter.org/install.html (ipset patch apply). The patch is applied successfully, but when I try to recompile, I obtain these errors (after a long list of compiled files): ... LD .tmp_vmlinux1 net/built-in.o(.init.text+0x16f1): In function `ipt_ipset_init': net/ipv4/netfilter/ipt_set.c:133: undefined reference to `xt_register_match' net/built-in.o(.init.text+0x1700): In function `ipt_SET_init': net/ipv4/netfilter/ipt_SET.c:151: undefined reference to `xt_register_target' net/built-in.o(.exit.text+0x41): In function `ipt_ipset_fini': net/ipv4/netfilter/ipt_set.c:138: undefined reference to `xt_unregister_match' net/built-in.o(.exit.text+0x50): In function `ipt_SET_fini': net/ipv4/netfilter/ipt_SET.c:156: undefined reference to `xt_unregister_target' make: *** [.tmp_vmlinux1] Error 1 I've tried twice, using two combinations of kernel (downloaded from www.kernel.org) and patch-o-matic (downloaded first time from http://ipset.netfilter.org/, second from patch-o-matic snaptshots). I've applied only the ipset patch (launching only the ./runme set command, just as explained in the ipset site). Maybe do I need to apply other patches from patch-o-matic? Thanks for the help From henrik at henriknordstrom.net Wed May 23 10:19:50 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Wed May 23 11:22:20 2007 Subject: Developing a user space library for filtering In-Reply-To: <465382DB.3080106@Sun.COM> References: <46521CB9.2040309@Sun.COM> <46522166.1090603@gmx.net> <465222C0.8050601@Sun.COM> <20070522064613.GA27619@oknodo.bof.de> <4653578C.3070407@Sun.COM> <20070522211404.GC24990@ipom.com> <1179874698.18674.22.camel@henriknordstrom.net> <465382DB.3080106@Sun.COM> Message-ID: <1179908390.18674.36.camel@henriknordstrom.net> tis 2007-05-22 klockan 16:55 -0700 skrev Darren.Reed@Sun.COM: > Which means that coming up with a design that works won't > necessarily be a slam-dunk. More that you are aiming this API at the wrong level. This API needs to be to the firewall (Smoothwall, Astaro, MARA, Cisco, Netgear, Checkpoint, etc etc), not the firewall packet engine. plain iptables might be one target, but only as a reference implementation under well defined conditions. To get going you need to first define a couple of target applications. Trying to make this discussion without some well defined targets will not gain good results. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070523/66d16328/attachment.pgp From henrik at henriknordstrom.net Wed May 23 10:26:24 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Wed May 23 11:28:47 2007 Subject: problems applying ipset patch In-Reply-To: <4653F176.4040604@gmail.com> References: <4653F176.4040604@gmail.com> Message-ID: <1179908784.18674.39.camel@henriknordstrom.net> ons 2007-05-23 klockan 09:47 +0200 skrev Andrea: > I've tried to apply the ipset patch in my CentOS 4.4 distribution, > without success. > > I've followed instructions here > http://www.howtoforge.com/kernel_compilation_cent?os_p2?s=aabdb730a09fa747d00f2b9a3ff431cc& > (CentOS Kernel Compile) and here > http://ipset.netfilter.org/install.html (ipset patch apply). > > The patch is applied successfully, but when I try to recompile, I obtain > these errors (after a long list of compiled files): Which kernel version? Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070523/faf5c2ff/attachment.pgp From andang76 at gmail.com Wed May 23 10:50:53 2007 From: andang76 at gmail.com (Andrea) Date: Wed May 23 11:53:13 2007 Subject: problems applying ipset patch In-Reply-To: <1179908784.18674.39.camel@henriknordstrom.net> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> Message-ID: <4654006D.9050704@gmail.com> Henrik Nordstrom ha scritto: > > Which kernel version? In the second try used linux-2.6.16.51.tar from www.kernel.org and patch-o-matic-ng-20070521 From henrik at henriknordstrom.net Wed May 23 11:02:19 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Wed May 23 12:04:49 2007 Subject: problems applying ipset patch In-Reply-To: <4654006D.9050704@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> Message-ID: <1179910939.18674.46.camel@henriknordstrom.net> ons 2007-05-23 klockan 10:50 +0200 skrev Andrea: > Henrik Nordstrom ha scritto: > > > > > Which kernel version? > > > In the second try used linux-2.6.16.51.tar from www.kernel.org and > patch-o-matic-ng-20070521 Try with a newer kernel. There is more than a year difference between your kernel and your pom-ng release. Also make sure CONFIG_NETFILTER_XTABLES is enabled in your kernel config. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070523/42131f24/attachment.pgp From andang76 at gmail.com Wed May 23 11:10:54 2007 From: andang76 at gmail.com (Andrea) Date: Wed May 23 12:13:11 2007 Subject: problems applying ipset patch In-Reply-To: <1179910939.18674.46.camel@henriknordstrom.net> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> Message-ID: <4654051E.8060508@gmail.com> Henrik Nordstrom ha scritto: > ons 2007-05-23 klockan 10:50 +0200 skrev Andrea: >> Henrik Nordstrom ha scritto: >> >>> Which kernel version? >> >> In the second try used linux-2.6.16.51.tar from www.kernel.org and >> patch-o-matic-ng-20070521 > > Try with a newer kernel. There is more than a year difference between > your kernel and your pom-ng release. ???? 2.6.16.51 has been released in 09 May 2007, as stated in http://www.kernel.org/pub/linux/kernel/v2.6/?C=M;O=A > > Also make sure CONFIG_NETFILTER_XTABLES is enabled in your kernel > config. it seems it's not set. Maybe the problem is here. I'll try again. Thanks From henrik at henriknordstrom.net Wed May 23 11:54:53 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Wed May 23 12:57:21 2007 Subject: problems applying ipset patch In-Reply-To: <4654051E.8060508@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> Message-ID: <1179914093.18674.65.camel@henriknordstrom.net> ons 2007-05-23 klockan 11:10 +0200 skrev Andrea: > 2.6.16.51 has been released in 09 May 2007, as stated in > http://www.kernel.org/pub/linux/kernel/v2.6/?C=M;O=A Well, it's mostly 2.6.16 which is more than a year old. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070523/71eb2046/attachment-0001.pgp From pablo at netfilter.org Wed May 23 15:04:01 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed May 23 15:59:38 2007 Subject: libnfnetlink_conntrack performance In-Reply-To: <7194302c0705221402k14bfe9eco7ecc98910eaa1c87@mail.gmail.com> References: <7194302c0705221402k14bfe9eco7ecc98910eaa1c87@mail.gmail.com> Message-ID: <46543BC1.8090106@netfilter.org> Morten Isaksen wrote: > Do anyone have som experience with the performance of libnfnetlink_conntrack? > > I am using it to track and log NFCT_T_NEW and NFCT_T_DESTROY events. I > am testing it on a firewall with about 15 Mbit/s traffic and 18-22K > entries in ip_conntrack. The only difference I can spot so far is 300 > more context switches pr. sec than usual. Using conntrack_events example available under utils/ with a little hack (removed the counter). $ ./bench 192.168.1.2 10000 # generate 10000 HTTP GET requests time taken: 19.613752000 seconds request per seconds: 509.846344 Cyclesoak says: System load: 10.1% System load: 1.6% System load: 3.4% System load: 6.8% System load: 13.7% System load: 23.2% System load: 4.2% System load: 1.7% System load: 3.5% System load: 6.8% System load: 13.6% System load: 20.8% System load: 6.8% System load: 1.7% System load: 3.4% System load: 7.0% System load: 14.1% System load: 22.5% System load: 5.4% System load: 1.7% System load: 2.1% processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 33 model name : Dual Core AMD Opteron(tm) Processor 275 stepping : 2 cpu MHz : 2210.189 cache size : 1024 KB One optimization that we can apply here is that libnetfilter_conntrack listen to update events even if you don't want to do it. These introduces an extra cost, of course. I have a patch somewhere to improve this, even I plan to introduce more fine grain events groups like protocol/state specific, eg. only listen to TCP syn_sent events. > The events are collected in batches of 7 and then sent in an UDP > packet to a log server. Did you ever have a look at conntrackd? It is available in the conntrack-tools package that I'll release today. It has a statistics mode that still needs some work, this option that you have implemented could be quite interesting for it. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From andang76 at gmail.com Wed May 23 15:17:17 2007 From: andang76 at gmail.com (Andrea) Date: Wed May 23 16:19:42 2007 Subject: problems applying ipset patch In-Reply-To: <1179914093.18674.65.camel@henriknordstrom.net> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> Message-ID: <46543EDD.8040009@gmail.com> Henrik Nordstrom ha scritto: > ons 2007-05-23 klockan 11:10 +0200 skrev Andrea: > >> 2.6.16.51 has been released in 09 May 2007, as stated in >> http://www.kernel.org/pub/linux/kernel/v2.6/?C=M;O=A > > Well, it's mostly 2.6.16 which is more than a year old. ok, you are right, I've choose wrong version (I had ordered the page according to modified date, latest file was 2.6.16.51) :-) From frozenspot at gmail.com Wed May 23 15:26:15 2007 From: frozenspot at gmail.com (fender) Date: Wed May 23 16:28:38 2007 Subject: [ANNOUNCE] new match extension about Port Knocking and SPA In-Reply-To: <465227A8.8030105@netfilter.org> References: <7e36c7130705021606kcbae516g1e34adabd3b441f@mail.gmail.com> <7e36c7130705031101i636da079k8077da93ebe1f29a@mail.gmail.com> <463B3515.9090207@trash.net> <7e36c7130705050036w75e63294jed76f68b87b77e41@mail.gmail.com> <463DF61F.50509@netfilter.org> <7e36c7130705081207l5c14807cr1bf715748b1975eb@mail.gmail.com> <46432820.8040602@trash.net> <7e36c7130705110600l35d6af11m3247eabd22621439@mail.gmail.com> <7e36c7130705211244i45ad22depc62e476dff5f30ce@mail.gmail.com> <465227A8.8030105@netfilter.org> Message-ID: <7e36c7130705230626j1de7a1day8c616c37defaf70a@mail.gmail.com> Hi Pabo, On 5/21/07, Pablo Neira Ayuso wrote: > fender wrote: > > This is the new link to the tarball: > > > > http://www.lugmen.org.ar/files/ > > > > http://www.lugmen.org.ar/files/index > > http://www.lugmen.org.ar/files/pom-ng-ipt_pknock.tgz > > We're close to get it done. I just added your source to source.list, > however ./runme --download complains with "could not get > http://www.lugmen.org.ar/files//pknock.tar.gz". Please, fix the problem > and contact us again. Thanks for your help. I will fix it and send it to you later. Regards, -- J. Federico Hernandez From misak at misak.dk Wed May 23 20:30:31 2007 From: misak at misak.dk (Morten Isaksen) Date: Wed May 23 21:32:53 2007 Subject: libnfnetlink_conntrack performance In-Reply-To: <46543BC1.8090106@netfilter.org> References: <7194302c0705221402k14bfe9eco7ecc98910eaa1c87@mail.gmail.com> <46543BC1.8090106@netfilter.org> Message-ID: <7194302c0705231130h2938dc22sea8ca26126c52ed6@mail.gmail.com> Hi! On 5/23/07, Pablo Neira Ayuso wrote: > One optimization that we can apply here is that libnetfilter_conntrack > listen to update events even if you don't want to do it. These > introduces an extra cost, of course. I have a patch somewhere to improve > this, even I plan to introduce more fine grain events groups like > protocol/state specific, eg. only listen to TCP syn_sent events. I am very interested in this patch. > > The events are collected in batches of 7 and then sent in an UDP > > packet to a log server. > > Did you ever have a look at conntrackd? It is available in the > conntrack-tools package that I'll release today. It has a statistics > mode that still needs some work, this option that you have implemented > could be quite interesting for it. I looked at it briefly, but as far as I could tell it did not support the log-part I am interested in, so I decided to write my own log program (very much based on the conntrack_event program). Also from a performance point of view I like the program as small as possible. -- Morten Isaksen http://www.misak.dk/blog/ From pablo at netfilter.org Wed May 23 21:41:45 2007 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed May 23 22:44:19 2007 Subject: [ANNOUNCE] Release conntrack-tools 0.9.3 Message-ID: <465498F9.8000804@netfilter.org> Hi! The netfilter project proudly presents conntrack-tools-0.9.3 The userspace daemon conntrackd covers the specific aspects of stateful Linux firewalls to enable high availability solutions, and can be used as statistics collector of the firewall use as well. The daemon is highly configurable and easily extensible. On the other hand, the command line conntrack provides an interface to add, delete and update flow entries, list current active flows and flush the complete connection tracking table. You can download it from: http://www.netfilter.org/projects/conntrack-tools/files/conntrack-tools-0.9.3.tar.bz2 Enjoy, Pablo (on behalf of the Netfilter Project) -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris -------------- next part -------------- version 0.9.3 ------------- = conntrackd = o fix commit of confirmed expectations (reported by Nishit Shah) o fix double increment of counters in cache_update_force() (Niko Tyni) o nl_dump_handler must return NFCT_CB_CONTINUE (Niko Tyni) o initialize buffer in nl_event_handler() and nl_dump_handler() (Niko Tyni) o CacheCommit value can be set via conntrackd.conf for the NACK approach o fix leaks in the hashtable/cache flush path (Niko Tyni) o fix leak if a connection already exists in the cache (Niko Tyni) o introduce a new header that encapsulates netlink messages o remove all '_entry' tail from all functions in cache.c o split cache.c: move cache iterators to file cache_iterators.c o fix inconsistencies in the cache API related to counters o cleanup 'usage' message o fix typo in examples/sync/nack/node1/conntrackd.conf o introduce message checksumming as described in RFC1071 (enabled by default) o major cleanups in the synchronization code o just warn once that the maximum netlink socket buffer has been reached o fix ignore conntrack entries by IP and introduce ignore pool abstraction layer o introduce netlink socket buffer overrun handler o constification of hash, compare and hashtable_test functions in hash.c o introduce ACKnowledgement mechanisms to reduce the size of the resend queue o remove OK messages at startup since provide useless data o fix compilation warning in mcast.c: recvfrom takes socklen_t not size_t o add a lock per buffer: makes buffer code thread safe o introduce 'Replicate' clause to explicitely set states to be replicated o kill cache feature abuse: introduce nicer cache hooks for sync algorithms o fix oversized buffer allocated in the stack in the cache functions o add support to dump internal/external cache in XML format '-x' o add script for keepalived fault state (eg. unplugged cable/link down) = conntrack = o port conntrack to the new libnetfilter_conntrack API o introduce '--output xml,extended,timestamp' option for '-L', '-G' and '-E' o deprecated '--id' o replace '-a' by '--src-nat' and '--dst-nat' o use positive logic in error handling o remove sctp support until is fully supported in the kernel side o update conntrack manpage o update test.sh file in examples/cli/ o several fixes for the output of usage messages From degraaf at cpsc.ucalgary.ca Wed May 23 23:12:57 2007 From: degraaf at cpsc.ucalgary.ca (Rennie deGraaf) Date: Thu May 24 01:59:12 2007 Subject: ip_rt_bug in mangle/OUTPUT Message-ID: <4654AE59.3090506@cpsc.ucalgary.ca> I seem to be getting the error message ip_rt_bug: 10.1.1.1 -> 10.0.1.2, ? whenever I attempt to send a packet with a non-local source IP address (my local IP address is 10.0.1.2) from libipq in mangle/OUTPUT. I have observed this behaviour under Linux kernels 2.6.20.7 and 2.6.18-1.2257.fc5smp (Fedora Core 5), and iptables versions 1.3.5 and 1.3.7. I'm trying to simulate connections with remote hosts by redirecting packets to servers listening on localhost. My strategy is to send packets to IP_QUEUE from rules in the mangle/OUTPUT chain: destination addresses are re-written on packets that I want to redirect, source addresses are re-written on packets on responses to redirected packets, and other packets are passed without modification. A simplified, highly stripped down version of my program is attached. To run my example program, you need rules in your mangle/OUTPUT chain forwarding packets to 10.1.1.1:123/TCP and from 127.0.0.1:22/TCP to QUEUE, and something listening on 127.0.0.1:22/TCP. If it worked properly, a connection could be successfully established to 127.0.0.1:22/TCP by connecting to 10.1.1.1:123/TCP (using telnet, for instance). Do any of the gurus on this list know how I might fix or work around this issue? This issue seems to have been discussed before (such as http://www.ussg.iu.edu/hypermail/linux/kernel/0504.3/0159.html), but doesn't seem to have been resolved. Thanks, Rennie deGraaf ----------------- #include #include #include #include #include #include u_int16_t ip_checksum(u_int32_t init, const u_int8_t* buf, size_t len) { u_int32_t sum = init; u_int16_t* shorts = (u_int16_t*)buf; while (len > 1) { sum += *shorts++; len -= 2; } if (len == 1) sum += *(u_int8_t*)shorts; while (sum >> 16) sum = (sum >> 16) + (sum & 0xFFFF); return ~sum; } u_int16_t tcp_checksum(const struct iphdr* iph, const struct tcphdr* tcph, size_t len) { u_int32_t cksum = 0; cksum += (iph->saddr >> 16) & 0x0000ffff; cksum += iph->saddr & 0x0000ffff; cksum += (iph->daddr >> 16) & 0x0000ffff; cksum += iph->daddr & 0x0000ffff; cksum += htons(iph->protocol & 0x00ff); cksum += htons(len); return ip_checksum(cksum, (unsigned char*)tcph, len); } void handle_packet(unsigned char* pkt, size_t len) { struct iphdr* iph = (struct iphdr*) pkt; struct tcphdr* tcph = (struct tcphdr*)(pkt+iph->ihl*4); if ((iph->daddr == htonl(0x0a010101)) && (tcph->dest == htons(123))) { printf("forward\n"); iph->daddr = htonl(0x7f000001); tcph->dest = htons(22); iph->check = 0; iph->check = ip_checksum(0, pkt, iph->ihl*4); tcph->check = 0; tcph->check = tcp_checksum(iph, tcph, len-(iph->ihl*4)); } else if ((iph->saddr == htonl(0x7f000001)) && (tcph->source == htons(22))) { printf("reverse\n"); iph->saddr = htonl(0x0a010101); tcph->source = htons(123); iph->check = 0; iph->check = ip_checksum(0, pkt, iph->ihl*4); tcph->check = 0; tcph->check = tcp_checksum(iph, tcph, len-(iph->ihl*4)); } else printf("wrong packet!\n"); } int main() { struct ipq_handle* handle; unsigned char buf[10000]; ipq_packet_msg_t* pkt; handle = ipq_create_handle(0, PF_INET); ipq_set_mode(handle, IPQ_COPY_PACKET, 65535); while (1) { ipq_read(handle, buf, 10000, 0); pkt = ipq_get_packet(buf); handle_packet(pkt->payload, pkt->data_len); ipq_set_verdict(handle, pkt->packet_id, NF_ACCEPT, pkt->data_len, pkt->payload); } ipq_destroy_handle(handle); return 0; } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : /pipermail/netfilter-devel/attachments/20070524/d3e44668/signature.pgp From edmonds at debian.org Thu May 24 03:57:58 2007 From: edmonds at debian.org (Robert Edmonds) Date: Thu May 24 05:00:30 2007 Subject: [PATCH]: ROUTE: convert hh_lock to seqlock Message-ID: <20070524015758.GA6544@mycre.ws> hh_cache's lock has been converted to a seqlock in recent kernels. Signed-off-by: Robert S. Edmonds --- ipv4/netfilter/ipt_ROUTE.c | 19 +++++++++++-------- ipv6/netfilter/ip6t_ROUTE.c | 8 +++++--- 2 files changed, 16 insertions(+), 11 deletions(-) diff -urNad netfilter-extensions-20070520+debian~/net/ipv4/netfilter/ipt_ROUTE.c netfilter-extensions-20070520+debian/net/ipv4/netfilter/ipt_ROUTE.c --- netfilter-extensions-20070520+debian~/net/ipv4/netfilter/ipt_ROUTE.c 2007-05-23 19:47:12.000000000 -0400 +++ netfilter-extensions-20070520+debian/net/ipv4/netfilter/ipt_ROUTE.c 2007-05-23 20:54:22.000000000 -0400 @@ -118,6 +118,7 @@ struct hh_cache *hh = dst->hh; struct net_device *dev = dst->dev; int hh_len = LL_RESERVED_SPACE(dev); + unsigned seq; /* Be paranoid, rather than too clever. */ if (unlikely(skb_headroom(skb) < hh_len && dev->hard_header)) { @@ -135,12 +136,13 @@ } if (hh) { - int hh_alen; + do { + int hh_alen; - read_lock_bh(&hh->hh_lock); - hh_alen = HH_DATA_ALIGN(hh->hh_len); - memcpy(skb->data - hh_alen, hh->hh_data, hh_alen); - read_unlock_bh(&hh->hh_lock); + seq = read_seqbegin(&hh->hh_lock); + hh_alen = HH_DATA_ALIGN(hh->hh_len); + memcpy(skb->data - hh_alen, hh->hh_data, hh_alen); + } while (read_seqretry(&hh->hh_lock, seq)); skb_push(skb, hh->hh_len); hh->hh_output(skb); } else if (dst->neighbour) diff -urNad netfilter-extensions-20070520+debian~/net/ipv6/netfilter/ip6t_ROUTE.c netfilter-extensions-20070520+debian/net/ipv6/netfilter/ip6t_ROUTE.c --- netfilter-extensions-20070520+debian~/net/ipv6/netfilter/ip6t_ROUTE.c 2007-05-23 20:54:13.000000000 -0400 +++ netfilter-extensions-20070520+debian/net/ipv6/netfilter/ip6t_ROUTE.c 2007-05-23 21:00:47.000000000 -0400 @@ -120,11 +120,13 @@ { struct dst_entry *dst = skb->dst; struct hh_cache *hh = dst->hh; + unsigned seq; if (hh) { - read_lock_bh(&hh->hh_lock); - memcpy(skb->data - 16, hh->hh_data, 16); - read_unlock_bh(&hh->hh_lock); + do { + seq = read_seqbegin(&hh->hh_lock); + memcpy(skb->data - 16, hh->hh_data, 16); + } while (read_seqretry(&hh->hh_lock, seq)); skb_push(skb, hh->hh_len); hh->hh_output(skb); } else if (dst->neighbour) From philipc at snapgear.com Thu May 24 07:55:23 2007 From: philipc at snapgear.com (Philip Craig) Date: Thu May 24 08:59:00 2007 Subject: [RFC][PATCH] optimise iptables interface matching Message-ID: <465528CB.4020108@snapgear.com> Optimise iptables for rules that specify 0 or 1 interface matches, which is the more common case (at least for my rulesets). Below are the oprofile cpu cycle percentages from a 30 second period of an iperf throughput test on a 667MHz IXP465 with Realtek 8169 network interfaces. rules iface % cpu before % cpu after saving (adjusted) 0 7.7662 4.9191 2.8471 10 0 15.9798 9.8453 3.2874 20 0 23.6914 14.2051 6.6392 10 1 14.6068 11.7332 0.0265 20 1 21.1646 17.1905 1.1270 10 2 14.6497 13.0306 -1.2280 20 2 21.1647 20.3536 -2.0360 - saving with 0 rules is due to policies - adjusted saving means with the 0 rules saving subtracted - iface 0 means "iptables -I FORWARD" - iface 1 means "iptables -I FORWARD -i eth0" - iface 2 means "iptables -I FORWARD -i eth0 -o eth1" If you think this is an acceptable approach then I can update the patch for IPv6. Any suggestions for other parts of netfilter/iptables to look at optimising are also welcome. Signed-off-by: Philip Craig -------------- next part -------------- --- linux-2.6.x/include/linux/netfilter_ipv4/ip_tables.h 26 Apr 2007 13:13:50 -0000 1.2 +++ linux-2.6.x/include/linux/netfilter_ipv4/ip_tables.h 24 May 2007 04:46:59 -0000 @@ -63,6 +63,10 @@ struct ipt_ip { #define IPT_F_GOTO 0x02 /* Set if jump is a goto */ #define IPT_F_MASK 0x03 /* All possible flag bits mask. */ +/* Internal values used for optimisation */ +#define IPT_F_VIA_IN 0x10 /* Set if rule has iif match */ +#define IPT_F_VIA_OUT 0x20 /* Set if rule has oif match */ + /* Values for "inv" field in struct ipt_ip. */ #define IPT_INV_VIA_IN 0x01 /* Invert the sense of IN IFACE. */ #define IPT_INV_VIA_OUT 0x02 /* Invert the sense of OUT IFACE */ --- linux-2.6.x/net/ipv4/netfilter/ip_tables.c 26 Apr 2007 11:17:49 -0000 1.1.1.29 +++ linux-2.6.x/net/ipv4/netfilter/ip_tables.c 24 May 2007 04:46:59 -0000 @@ -112,30 +112,34 @@ ip_packet_match(const struct iphdr *ip, } /* Look for ifname matches; this should unroll nicely. */ - for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { - ret |= (((const unsigned long *)indev)[i] - ^ ((const unsigned long *)ipinfo->iniface)[i]) - & ((const unsigned long *)ipinfo->iniface_mask)[i]; - } + if (ipinfo->flags & IPT_F_VIA_IN) { + for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { + ret |= (((const unsigned long *)indev)[i] + ^ ((const unsigned long *)ipinfo->iniface)[i]) + & ((const unsigned long *)ipinfo->iniface_mask)[i]; + } - if (FWINV(ret != 0, IPT_INV_VIA_IN)) { - dprintf("VIA in mismatch (%s vs %s).%s\n", - indev, ipinfo->iniface, - ipinfo->invflags&IPT_INV_VIA_IN ?" (INV)":""); - return 0; + if (FWINV(ret != 0, IPT_INV_VIA_IN)) { + dprintf("VIA in mismatch (%s vs %s).%s\n", + indev, ipinfo->iniface, + ipinfo->invflags&IPT_INV_VIA_IN ?" (INV)":""); + return 0; + } } - for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { - ret |= (((const unsigned long *)outdev)[i] - ^ ((const unsigned long *)ipinfo->outiface)[i]) - & ((const unsigned long *)ipinfo->outiface_mask)[i]; - } + if (ipinfo->flags & IPT_F_VIA_OUT) { + for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { + ret |= (((const unsigned long *)outdev)[i] + ^ ((const unsigned long *)ipinfo->outiface)[i]) + & ((const unsigned long *)ipinfo->outiface_mask)[i]; + } - if (FWINV(ret != 0, IPT_INV_VIA_OUT)) { - dprintf("VIA out mismatch (%s vs %s).%s\n", - outdev, ipinfo->outiface, - ipinfo->invflags&IPT_INV_VIA_OUT ?" (INV)":""); - return 0; + if (FWINV(ret != 0, IPT_INV_VIA_OUT)) { + dprintf("VIA out mismatch (%s vs %s).%s\n", + outdev, ipinfo->outiface, + ipinfo->invflags&IPT_INV_VIA_OUT ?" (INV)":""); + return 0; + } } /* Check specific protocol */ @@ -159,13 +163,21 @@ ip_packet_match(const struct iphdr *ip, } static inline int -ip_checkentry(const struct ipt_ip *ip) +ip_checkentry(struct ipt_ip *ip) { + size_t i; + if (ip->flags & ~IPT_F_MASK) { duprintf("Unknown flag bits set: %08X\n", ip->flags & ~IPT_F_MASK); return 0; } + for (i = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { + if (ip->iniface_mask[i]) + ip->flags |= IPT_F_VIA_IN; + if (ip->outiface_mask[i]) + ip->flags |= IPT_F_VIA_OUT; + } if (ip->invflags & ~IPT_INV_MASK) { duprintf("Unknown invflag bits set: %08X\n", ip->invflags & ~IPT_INV_MASK); @@ -869,8 +881,9 @@ copy_entries_to_user(unsigned int total_ } /* FIXME: use iterator macros --RR */ - /* ... then go back and fix counters and names */ + /* ... then go back and fix counters, flags, and names */ for (off = 0, num = 0; off < total_size; off += e->next_offset, num++){ + u_int8_t flags; unsigned int i; struct ipt_entry_match *m; struct ipt_entry_target *t; @@ -884,6 +897,15 @@ copy_entries_to_user(unsigned int total_ goto free_counters; } + flags = e->ip.flags & IPT_F_MASK; + if (copy_to_user(userptr + off + + offsetof(struct ipt_entry, ip.flags), + &flags, + sizeof(flags)) != 0) { + ret = -EFAULT; + goto free_counters; + } + for (i = sizeof(struct ipt_entry); i < e->target_offset; i += m->u.match_size) { From andang76 at gmail.com Thu May 24 11:39:40 2007 From: andang76 at gmail.com (Andrea) Date: Thu May 24 12:42:07 2007 Subject: problems applying ipset patch In-Reply-To: <46543EDD.8040009@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> Message-ID: <46555D5C.7030406@gmail.com> Andrea ha scritto: > Henrik Nordstrom ha scritto: >> ons 2007-05-23 klockan 11:10 +0200 skrev Andrea: >> >>> 2.6.16.51 has been released in 09 May 2007, as stated in >>> http://www.kernel.org/pub/linux/kernel/v2.6/?C=M;O=A >> >> Well, it's mostly 2.6.16 which is more than a year old. > Tried again with linux-2.6.21.1 kernel. It seems that kernet has been compiled, but I've these warnings and errors: make all .... Root device is (253, 0) Boot sector 512 bytes. Setup is 7354 bytes. System is 1559 kB Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 758 modules WARNING: drivers/atm/lanai.o - Section mismatch: reference to .init.text: from . text between 'sram_test_pass' (at offset 0x171) and 'sram_test_and_clear' WARNING: drivers/net/sis900.o - Section mismatch: reference to .init.text:sis900 _mii_probe from .text between 'sis900_probe' (at offset 0x4ce) and 'sis900_defau lt_phy' WARNING: drivers/net/sunhme.o - Section mismatch: reference to .init.text: from .text between 'happy_meal_pci_probe' (at offset 0x289c) and 'happy_meal_pci_remo ve' WARNING: drivers/net/tokenring/3c359.o - Section mismatch: reference to .init.te xt:xl_init from .text between 'xl_probe' (at offset 0x203) and 'xl_hw_reset' WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Maybe because I've iptables just installed, before kernel recompilation? are these warnings important? From henrik at henriknordstrom.net Thu May 24 11:50:51 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Thu May 24 12:53:27 2007 Subject: problems applying ipset patch In-Reply-To: <46555D5C.7030406@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> Message-ID: <1180000251.2028.8.camel@henriknordstrom.net> tor 2007-05-24 klockan 11:39 +0200 skrev Andrea: > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] > undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] > undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] > undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] > undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > > Maybe because I've iptables just installed, before kernel > recompilation? > are these warnings important? The driver warnings is something to send to the kernel janitor to take care of.. not related to ipset. But the above warnings is important. The module won't work with these warnings.. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070524/8676534b/attachment.pgp From kadlec at blackhole.kfki.hu Thu May 24 11:55:38 2007 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Thu May 24 12:58:29 2007 Subject: problems applying ipset patch In-Reply-To: <46555D5C.7030406@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> Message-ID: On Thu, 24 May 2007, Andrea wrote: > Tried again with linux-2.6.21.1 kernel. It seems that kernet has been > compiled, but I've these warnings and errors: > > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! Please check out patch-o-matic-ng from the svn repository: I committed the required changes yesterday to support kernel versions 2.6.21 and above. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From andang76 at gmail.com Thu May 24 12:18:51 2007 From: andang76 at gmail.com (Andrea) Date: Thu May 24 13:21:15 2007 Subject: problems applying ipset patch In-Reply-To: References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> Message-ID: <4655668B.6000401@gmail.com> > Please check out patch-o-matic-ng from the svn repository: I committed > the required changes yesterday to support kernel versions 2.6.21 and above. is this snapshot compatible with 2.6.21? http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070523.tar.bz2 From kadlec at blackhole.kfki.hu Thu May 24 12:25:55 2007 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Thu May 24 13:28:24 2007 Subject: problems applying ipset patch In-Reply-To: <4655668B.6000401@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> Message-ID: On Thu, 24 May 2007, Andrea wrote: >> Please check out patch-o-matic-ng from the svn repository: I committed the >> required changes yesterday to support kernel versions 2.6.21 and above. > > is this snapshot compatible with 2.6.21? > > http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070523.tar.bz2 I believe the snapshot is created early in the morning, so it's not. Download http://ipset.netfilter.org/patch-o-matic-ng-20070524.tar.bz2 instead. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From henrik at henriknordstrom.net Thu May 24 12:32:56 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Thu May 24 13:35:32 2007 Subject: problems applying ipset patch In-Reply-To: <4655668B.6000401@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> Message-ID: <1180002776.17774.18.camel@henriknordstrom.net> tor 2007-05-24 klockan 12:18 +0200 skrev Andrea: > > Please check out patch-o-matic-ng from the svn repository: I committed > > the required changes yesterday to support kernel versions 2.6.21 and above. > > is this snapshot compatible with 2.6.21? > > http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070523.tar.bz2 Should be fine. That snapshot is 10.5 hours old, and Jozsef's changed ipset 25 hours ago. If in doubt verify that patchlets/set/linux-2.6/net/ipv4/netfilter/ipt_SET.c is modified yesterday after unpacking the snapshot. ls -l patchlets/set/linux-2.6/net/ipv4/netfilter/ipt_SET.c Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070524/587ea179/attachment.pgp From henrik at henriknordstrom.net Thu May 24 12:39:00 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Thu May 24 13:41:31 2007 Subject: problems applying ipset patch In-Reply-To: References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> Message-ID: <1180003140.17774.21.camel@henriknordstrom.net> tor 2007-05-24 klockan 12:25 +0200 skrev Jozsef Kadlecsik: > I believe the snapshot is created early in the morning, so it's not. From what I can tell the snapshots is generated late in the evening 23:55 CEST (21:55 GMT). Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070524/809750f6/attachment-0001.pgp From andang76 at gmail.com Thu May 24 12:45:18 2007 From: andang76 at gmail.com (Andrea) Date: Thu May 24 13:47:42 2007 Subject: problems applying ipset patch In-Reply-To: <1180002776.17774.18.camel@henriknordstrom.net> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> Message-ID: <46556CBE.9000408@gmail.com> Henrik Nordstrom ha scritto: > tor 2007-05-24 klockan 12:18 +0200 skrev Andrea: >>> Please check out patch-o-matic-ng from the svn repository: I committed >>> the required changes yesterday to support kernel versions 2.6.21 and above. >> is this snapshot compatible with 2.6.21? >> >> http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070523.tar.bz2 > > Should be fine. That snapshot is 10.5 hours old, and Jozsef's changed > ipset 25 hours ago. > > If in doubt verify that > patchlets/set/linux-2.6/net/ipv4/netfilter/ipt_SET.c is modified > yesterday after unpacking the snapshot. > > ls -l patchlets/set/linux-2.6/net/ipv4/netfilter/ipt_SET.c I've just patched with patch-o-matic-ng-20070524.tar.bz2. So my config is: -linux-2.6.21.1.tar.bz2 -patch-o-matic-ng-20070524.tar.bz2 -iptables-1.3.7.tar.bz2 -ipset-2.2.9a-20061009.tar.bz2 (maybe too old?) Waiting compile-phase done, some questions: - in make oldconfig I've set ipsets entries as modules (m): am I right? - do I need to uninstall iptables before patch-compile-reinstall new version of iptables? Thanks for the patience From kadlec at blackhole.kfki.hu Thu May 24 13:26:09 2007 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Thu May 24 14:28:36 2007 Subject: problems applying ipset patch In-Reply-To: <46556CBE.9000408@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> Message-ID: On Thu, 24 May 2007, Andrea wrote: > Henrik Nordstrom ha scritto: >>> >>> http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070523.tar.bz2 >> >> Should be fine. That snapshot is 10.5 hours old, and Jozsef's changed >> ipset 25 hours ago. >> >> If in doubt verify that >> patchlets/set/linux-2.6/net/ipv4/netfilter/ipt_SET.c is modified >> yesterday after unpacking the snapshot. >> >> ls -l patchlets/set/linux-2.6/net/ipv4/netfilter/ipt_SET.c > > I've just patched with patch-o-matic-ng-20070524.tar.bz2. So my config is: > > -linux-2.6.21.1.tar.bz2 > -patch-o-matic-ng-20070524.tar.bz2 > -iptables-1.3.7.tar.bz2 > -ipset-2.2.9a-20061009.tar.bz2 (maybe too old?) That's good. (There was no need to fix the userspace tool since then.) > Waiting compile-phase done, some questions: > > - in make oldconfig I've set ipsets entries as modules (m): am I right? Fine. > - do I need to uninstall iptables before patch-compile-reinstall new version > of iptables? No, 'make install' will overwrite existing shared libraries and binaries. Just make sure you use the correct iptables binary if you have got one installed in another directory, too, from your distribution. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From andang76 at gmail.com Thu May 24 15:41:44 2007 From: andang76 at gmail.com (Andrea) Date: Thu May 24 16:44:13 2007 Subject: problems applying ipset patch In-Reply-To: References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> Message-ID: <46559618.8040708@gmail.com> > > No, 'make install' will overwrite existing shared libraries and > binaries. Just make sure you use the correct iptables binary if you have > got one installed in another directory, too, from your distribution. > Kernel now works fine! I've rebooted the system with the new kernel, compiled and installed iptables and ipset, rebooted again. At the startup, however, iptables failed to start, (and so the shorewall script), with the message "iptables-restore: line 10 failed" From kadlec at blackhole.kfki.hu Thu May 24 15:46:23 2007 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Thu May 24 16:48:50 2007 Subject: problems applying ipset patch In-Reply-To: <46559618.8040708@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> Message-ID: On Thu, 24 May 2007, Andrea wrote: >> No, 'make install' will overwrite existing shared libraries and binaries. >> Just make sure you use the correct iptables binary if you have got one >> installed in another directory, too, from your distribution. > > Kernel now works fine! > > I've rebooted the system with the new kernel, compiled and installed iptables > and ipset, rebooted again. > > At the startup, however, iptables failed to start, (and so the shorewall > script), with the message "iptables-restore: line 10 failed" What's in line 10?? Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From andang76 at gmail.com Thu May 24 15:56:14 2007 From: andang76 at gmail.com (Andrea) Date: Thu May 24 16:58:39 2007 Subject: problems applying ipset patch In-Reply-To: References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> Message-ID: <4655997E.7010407@gmail.com> Jozsef Kadlecsik ha scritto: > On Thu, 24 May 2007, Andrea wrote: > >>> No, 'make install' will overwrite existing shared libraries and >>> binaries. Just make sure you use the correct iptables binary if you >>> have got one installed in another directory, too, from your >>> distribution. >> >> Kernel now works fine! >> >> I've rebooted the system with the new kernel, compiled and installed >> iptables and ipset, rebooted again. >> >> At the startup, however, iptables failed to start, (and so the >> shorewall script), with the message "iptables-restore: line 10 failed" > > What's in line 10?? In what file do I have to find? /etc/sysconfig/iptables, maybe? Here it is: # Generated by iptables-save v1.2.11 on Mon May 14 10:59:07 2007 *filter :FORWARD ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth2 -j ACCEPT -A FORWARD -o eth2 -j ACCEPT -A OUTPUT -j ACCEPT COMMIT # Completed on Mon May 14 10:59:07 2007 # Generated by iptables-save v1.2.11 on Mon May 14 10:59:07 2007 *nat :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Mon May 14 10:59:07 2007 # Generated by iptables-save v1.2.11 on Mon May 14 10:59:07 2007 *mangle :PREROUTING ACCEPT [10461:714412] :INPUT ACCEPT [5007:406609] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [3176:400160] :POSTROUTING ACCEPT [3176:400160] COMMIT # Completed on Mon May 14 10:59:07 2007 From hdemir at metu.edu.tr Thu May 24 16:48:15 2007 From: hdemir at metu.edu.tr (husnu demir) Date: Thu May 24 17:50:43 2007 Subject: Compile errors for debian-amd64 In-Reply-To: <20070511081629.GA2289802@metu.edu.tr> References: <20070508112319.GA2953330@metu.edu.tr> <20070509060534.GA3117230@metu.edu.tr> <20070509105159.GA970840@metu.edu.tr> <20070511081629.GA2289802@metu.edu.tr> Message-ID: <20070524144815.GA332018@metu.edu.tr> thank to all. At last the patch came out and it worked for ipset :). hdemir. On Fri, May 11, 2007 at 11:16:29AM +0300, husnu demir wrote: > Hi, > > I am trying to compile kernel 2.6.21.1 with ipset from pom-ng snapshot of 10.05.2007. However, there is problem as; > > > Kernel: arch/x86_64/boot/bzImage is ready (#1) > Building modules, stage 2. > MODPOST 725 modules > WARNING: "ip6t_register_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ip6t_unregister_target" [net/ipv6/netfilter/ip6t_ROUTE.ko] undefined! > WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_set.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_SET.ko] undefined! > WARNING: "ipt_register_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > WARNING: "ipt_unregister_target" [net/ipv4/netfilter/ipt_ROUTE.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > > When I change the ipt_unregister_match(&set_match); to xt_reg... etc., it compiles but does not work. I think it needs something elses. > > # iptables -A OUTPUT -m set --set izinli src -j ACCEPT > iptables: No chain/target/match by that name > > > # ipset -nL izinli > Name: izinli > Type: iphash > References: 0 > Default binding: > Header: hashsize: 1024 probes: 8 resize: 50 > Members: > 10.10.144.156 > Bindings: > > > > Do I only need help on this subject? I could not find any patches available on the dev-list and also for the ROUTE as said before?? > > > Thanks. > > hdemir. > > From andang76 at gmail.com Thu May 24 17:26:46 2007 From: andang76 at gmail.com (Andrea) Date: Thu May 24 18:29:13 2007 Subject: problems applying ipset patch In-Reply-To: <4655997E.7010407@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> Message-ID: <4655AEB6.5060004@gmail.com> when I reboot with the old kernel, iptables works even if this it's patched and updated to the version 1.3.7. I suspect that I've forgotten some module or some kernel setting From andang76 at gmail.com Thu May 24 17:47:52 2007 From: andang76 at gmail.com (Andrea) Date: Thu May 24 18:50:18 2007 Subject: problems applying ipset patch In-Reply-To: <4655AEB6.5060004@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> Message-ID: <4655B3A8.10809@gmail.com> Another issue: trying to modify iptables rules file, I obtain something like: "iptables-restore v1.2.11: no command specified" Maybe is there a mess between old and new version of iptables? From kaber at trash.net Thu May 24 19:43:12 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 20:46:18 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <465528CB.4020108@snapgear.com> References: <465528CB.4020108@snapgear.com> Message-ID: <4655CEB0.4060306@trash.net> Philip Craig wrote: > Optimise iptables for rules that specify 0 or 1 interface matches, > which is the more common case (at least for my rulesets). > > Below are the oprofile cpu cycle percentages from a 30 second > period of an iperf throughput test on a 667MHz IXP465 with > Realtek 8169 network interfaces. > > rules iface % cpu before % cpu after saving (adjusted) > 0 7.7662 4.9191 2.8471 > 10 0 15.9798 9.8453 3.2874 > 20 0 23.6914 14.2051 6.6392 > 10 1 14.6068 11.7332 0.0265 > 20 1 21.1646 17.1905 1.1270 > 10 2 14.6497 13.0306 -1.2280 > 20 2 21.1647 20.3536 -2.0360 > > - saving with 0 rules is due to policies > - adjusted saving means with the 0 rules saving subtracted > - iface 0 means "iptables -I FORWARD" > - iface 1 means "iptables -I FORWARD -i eth0" > - iface 2 means "iptables -I FORWARD -i eth0 -o eth1" > > If you think this is an acceptable approach then I can update > the patch for IPv6. Any suggestions for other parts of > netfilter/iptables to look at optimising are also welcome. I don't like the kernel-internal fiddling with the flags too much, but I don't see a way around it. But even if there is no other way, > @@ -884,6 +897,15 @@ copy_entries_to_user(unsigned int total_ > goto free_counters; > } > > + flags = e->ip.flags & IPT_F_MASK; > + if (copy_to_user(userptr + off > + + offsetof(struct ipt_entry, ip.flags), > + &flags, > + sizeof(flags)) != 0) { > + ret = -EFAULT; > + goto free_counters; > + } > + userspace should just ignore unknown flags. From kaber at trash.net Thu May 24 19:45:02 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 20:48:08 2007 Subject: [PATCH]: ROUTE: convert hh_lock to seqlock In-Reply-To: <20070524015758.GA6544@mycre.ws> References: <20070524015758.GA6544@mycre.ws> Message-ID: <4655CF1E.3050500@trash.net> Robert Edmonds wrote: > hh_cache's lock has been converted to a seqlock in recent kernels. Applied, thanks. I wish someone else could take care of ROUTE maintenance. From kaber at trash.net Thu May 24 19:50:59 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 20:54:05 2007 Subject: ip_rt_bug in mangle/OUTPUT In-Reply-To: <4654AE59.3090506@cpsc.ucalgary.ca> References: <4654AE59.3090506@cpsc.ucalgary.ca> Message-ID: <4655D083.8070309@trash.net> Rennie deGraaf wrote: > I seem to be getting the error message > ip_rt_bug: 10.1.1.1 -> 10.0.1.2, ? > whenever I attempt to send a packet with a non-local source IP address > (my local IP address is 10.0.1.2) from libipq in mangle/OUTPUT. I have > observed this behaviour under Linux kernels 2.6.20.7 and > 2.6.18-1.2257.fc5smp (Fedora Core 5), and iptables versions 1.3.5 and > 1.3.7. > > I'm trying to simulate connections with remote hosts by redirecting > packets to servers listening on localhost. My strategy is to send > packets to IP_QUEUE from rules in the mangle/OUTPUT chain: destination > addresses are re-written on packets that I want to redirect, source > addresses are re-written on packets on responses to redirected packets, > and other packets are passed without modification. A simplified, highly > stripped down version of my program is attached. > > To run my example program, you need rules in your mangle/OUTPUT chain > forwarding packets to 10.1.1.1:123/TCP and from 127.0.0.1:22/TCP to > QUEUE, and something listening on 127.0.0.1:22/TCP. If it worked > properly, a connection could be successfully established to > 127.0.0.1:22/TCP by connecting to 10.1.1.1:123/TCP (using telnet, for > instance). > > Do any of the gurus on this list know how I might fix or work around > this issue? If you don't need the rerouting to be happen (you only change the source address and don't use routing rules based on that) you can simply return NF_STOP instead of NF_ACCEPT. It will do exactly the same thing but avoid rerouting. > This issue seems to have been discussed before (such as > http://www.ussg.iu.edu/hypermail/linux/kernel/0504.3/0159.html), but > doesn't seem to have been resolved. The solution suggested there doesn't work since we've moved the okfn invocation to the caller of nf_hook_slow() and I'm hoping we can some day get rid of the okfn function pointer entirely. From kaber at trash.net Thu May 24 20:16:05 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 21:19:12 2007 Subject: bugs in ftp conntrack In-Reply-To: <379815077.04066@tsinghua.org.cn> References: <379815077.04066@tsinghua.org.cn> Message-ID: <4655D665.1050905@trash.net> YU, Haitao wrote: > If the order of ftp packets are wrong, function find_nl_seq() in > net/ipv4/netfilter/ip_conntrack_ftp.c will make mistake. > > i.e., consider three ftp packets: "port", "list" and "noop", > if the "list" and "noop" packets reach firewall before "port" packet, > then info->seq_aft_nl will record the sequence of "noop". Kenerl will > not parse "port" packet because the seq does not match the recored one . There's not much we can do about this case, we already keep a history of sequence numbers. As you note below that code is pretty broken currently, but I have patches queued to fix it (attached to this mail). > If kernel can't trace expect connection, then the attack described in > [phrack-63, 0x13] will happen. Shouldn't be, we don't assign helpers to expected connections except when the first helper explicitly want us to. > Another problem is if the packet length is changed bye NAT, then the > next packet will not be parsed. So kernel can not parse the 2nd "port" > packet of two continual "port" packets. Though it's impossible in legal > ftp connection, and I also don't know how to use this to hack firewall. Good catch, that is broken since about 2.6.11. > Third, the value of "oldest" in function udpate_bl_seq() seem unchanged > after four packets. Its changes randomly because the saved sequence number is compared to the index of the oldest entry. -------------- next part -------------- [NETFILTER]: nf_conntrack_ftp: fix newline sequence number update When trying to locate the oldest entry in the history of newline character sequence numbers, the sequence number of the current entry is incorrectly compared with the index of the oldest sequence number instead of the number itself. Additionally it is not made sure that the current sequence number really is after the oldest known one. Based on report by YU, Haitao Signed-off-by: Patrick McHardy --- commit ce7fed0c554b66ea7ea36abb91d69fa74fa3a3e2 tree 156e9de9fc8105096623d98506b0c563f1eefbca parent ff33b5e57721b1f2a7c8b9fcef32acdb55816131 author Patrick McHardy Thu, 24 May 2007 20:05:19 +0200 committer Patrick McHardy Thu, 24 May 2007 20:05:19 +0200 net/netfilter/nf_conntrack_ftp.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c index a186799..3357642 100644 --- a/net/netfilter/nf_conntrack_ftp.c +++ b/net/netfilter/nf_conntrack_ftp.c @@ -335,15 +335,17 @@ static void update_nl_seq(u32 nl_seq, struct nf_ct_ftp_master *info, int dir, if (info->seq_aft_nl[dir][i] == nl_seq) return; - if (oldest == info->seq_aft_nl_num[dir] - || before(info->seq_aft_nl[dir][i], oldest)) + if (oldest == info->seq_aft_nl_num[dir] || + before(info->seq_aft_nl[dir][i], + info->seq_aft_nl[dir][oldest])) oldest = i; } if (info->seq_aft_nl_num[dir] < NUM_SEQ_TO_REMEMBER) { info->seq_aft_nl[dir][info->seq_aft_nl_num[dir]++] = nl_seq; nf_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); - } else if (oldest != NUM_SEQ_TO_REMEMBER) { + } else if (oldest != NUM_SEQ_TO_REMEMBER && + after(nl_seq, info->seq_aft_nl[dir][oldest])) { info->seq_aft_nl[dir][oldest] = nl_seq; nf_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); } -------------- next part -------------- [NETFILTER]: nf_conntrack_ftp: fix newline sequence number calculation When the packet size is changed by the FTP NAT helper, the connection tracking helper adjusts the sequence number of the newline character by the size difference. This is wrong because NAT sequence number adjustment happens after helpers are called, so the unadjusted number is compared to the already adjusted one. Based on report by YU, Haitao Signed-off-by: Patrick McHardy --- commit 4aa8feb60ca94d73f6ebb186b088e78970e2dcc7 tree 3245b16e02ec807d8535ad3e84c9fa974ba68e85 parent ce7fed0c554b66ea7ea36abb91d69fa74fa3a3e2 author Patrick McHardy Thu, 24 May 2007 20:05:57 +0200 committer Patrick McHardy Thu, 24 May 2007 20:05:57 +0200 include/linux/netfilter/nf_conntrack_ftp.h | 3 +-- net/ipv4/netfilter/nf_nat_ftp.c | 20 ++++++-------------- net/netfilter/nf_conntrack_ftp.c | 5 ++--- 3 files changed, 9 insertions(+), 19 deletions(-) diff --git a/include/linux/netfilter/nf_conntrack_ftp.h b/include/linux/netfilter/nf_conntrack_ftp.h index 81453ea..b7c360f 100644 --- a/include/linux/netfilter/nf_conntrack_ftp.h +++ b/include/linux/netfilter/nf_conntrack_ftp.h @@ -37,8 +37,7 @@ extern unsigned int (*nf_nat_ftp_hook)(struct sk_buff **pskb, enum nf_ct_ftp_type type, unsigned int matchoff, unsigned int matchlen, - struct nf_conntrack_expect *exp, - u32 *seq); + struct nf_conntrack_expect *exp); #endif /* __KERNEL__ */ #endif /* _NF_CONNTRACK_FTP_H */ diff --git a/net/ipv4/netfilter/nf_nat_ftp.c b/net/ipv4/netfilter/nf_nat_ftp.c index 751b598..e6bc8e5 100644 --- a/net/ipv4/netfilter/nf_nat_ftp.c +++ b/net/ipv4/netfilter/nf_nat_ftp.c @@ -40,8 +40,7 @@ mangle_rfc959_packet(struct sk_buff **pskb, unsigned int matchoff, unsigned int matchlen, struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - u32 *seq) + enum ip_conntrack_info ctinfo) { char buffer[sizeof("nnn,nnn,nnn,nnn,nnn,nnn")]; @@ -50,7 +49,6 @@ mangle_rfc959_packet(struct sk_buff **pskb, DEBUGP("calling nf_nat_mangle_tcp_packet\n"); - *seq += strlen(buffer) - matchlen; return nf_nat_mangle_tcp_packet(pskb, ct, ctinfo, matchoff, matchlen, buffer, strlen(buffer)); } @@ -63,8 +61,7 @@ mangle_eprt_packet(struct sk_buff **pskb, unsigned int matchoff, unsigned int matchlen, struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - u32 *seq) + enum ip_conntrack_info ctinfo) { char buffer[sizeof("|1|255.255.255.255|65535|")]; @@ -72,7 +69,6 @@ mangle_eprt_packet(struct sk_buff **pskb, DEBUGP("calling nf_nat_mangle_tcp_packet\n"); - *seq += strlen(buffer) - matchlen; return nf_nat_mangle_tcp_packet(pskb, ct, ctinfo, matchoff, matchlen, buffer, strlen(buffer)); } @@ -85,8 +81,7 @@ mangle_epsv_packet(struct sk_buff **pskb, unsigned int matchoff, unsigned int matchlen, struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - u32 *seq) + enum ip_conntrack_info ctinfo) { char buffer[sizeof("|||65535|")]; @@ -94,14 +89,13 @@ mangle_epsv_packet(struct sk_buff **pskb, DEBUGP("calling nf_nat_mangle_tcp_packet\n"); - *seq += strlen(buffer) - matchlen; return nf_nat_mangle_tcp_packet(pskb, ct, ctinfo, matchoff, matchlen, buffer, strlen(buffer)); } static int (*mangle[])(struct sk_buff **, __be32, u_int16_t, unsigned int, unsigned int, struct nf_conn *, - enum ip_conntrack_info, u32 *seq) + enum ip_conntrack_info) = { [NF_CT_FTP_PORT] = mangle_rfc959_packet, [NF_CT_FTP_PASV] = mangle_rfc959_packet, @@ -116,8 +110,7 @@ static unsigned int nf_nat_ftp(struct sk_buff **pskb, enum nf_ct_ftp_type type, unsigned int matchoff, unsigned int matchlen, - struct nf_conntrack_expect *exp, - u32 *seq) + struct nf_conntrack_expect *exp) { __be32 newip; u_int16_t port; @@ -145,8 +138,7 @@ static unsigned int nf_nat_ftp(struct sk_buff **pskb, if (port == 0) return NF_DROP; - if (!mangle[type](pskb, newip, port, matchoff, matchlen, ct, ctinfo, - seq)) { + if (!mangle[type](pskb, newip, port, matchoff, matchlen, ct, ctinfo)) { nf_conntrack_unexpect_related(exp); return NF_DROP; } diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c index 3357642..09add2f 100644 --- a/net/netfilter/nf_conntrack_ftp.c +++ b/net/netfilter/nf_conntrack_ftp.c @@ -48,8 +48,7 @@ unsigned int (*nf_nat_ftp_hook)(struct sk_buff **pskb, enum nf_ct_ftp_type type, unsigned int matchoff, unsigned int matchlen, - struct nf_conntrack_expect *exp, - u32 *seq); + struct nf_conntrack_expect *exp); EXPORT_SYMBOL_GPL(nf_nat_ftp_hook); #if 0 @@ -521,7 +520,7 @@ static int help(struct sk_buff **pskb, nf_nat_ftp = rcu_dereference(nf_nat_ftp_hook); if (nf_nat_ftp && ct->status & IPS_NAT_MASK) ret = nf_nat_ftp(pskb, ctinfo, search[dir][i].ftptype, - matchoff, matchlen, exp, &seq); + matchoff, matchlen, exp); else { /* Can't expect this? Best to drop packet now. */ if (nf_conntrack_expect_related(exp) != 0) From kaber at trash.net Thu May 24 20:48:53 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 21:55:30 2007 Subject: [PATCH 1/4] H.323: update ASN.1 types In-Reply-To: <20070517191756.728953DA1F7@jzhao.vivecode.com> References: <20070517191756.728953DA1F7@jzhao.vivecode.com> Message-ID: <4655DE15.9080906@trash.net> Jing Min Zhao wrote: > nf_conntrack_h323_types.h and nf_conntrack_h323_types.c have been updated. > > 1. Add support for decoding IPv6 address. I know it was manually added in the header file, but not in the template file. That wouldn't work. > 2. Add missing support for decoding T.120 address in OLCA. > 3. Remove unnecessary decoding of Information signal. > > Signed-off-by: Jing Min Zhao Applied, thanks a lot. From kaber at trash.net Thu May 24 20:52:22 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 21:58:50 2007 Subject: [PATCH 2/4] H.323: update get_h225_addr() for IPv6 address access In-Reply-To: <20070517191756.A7F5F3DA1F9@jzhao.vivecode.com> References: <20070517191756.A7F5F3DA1F9@jzhao.vivecode.com> Message-ID: <4655DEE6.8030805@trash.net> Jing Min Zhao wrote: > Update get_h225_addr() to meet the changes in ASN.1 types. It was using field ip6 to access IPv6 TransportAddress, it should be ip according the ASN.1 definition. > > Signed-off-by: Jing Min Zhao Also applied, thanks. BTW, I've replaced "update" by "fix" in the patch title since these really are fixes and the merge window is already closed. From kaber at trash.net Thu May 24 20:54:45 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 22:01:12 2007 Subject: [PATCH 3/4] H.323: Remove unnecessary process of Information signal In-Reply-To: <20070517191756.D5C8C3DA1FA@jzhao.vivecode.com> References: <20070517191756.D5C8C3DA1FA@jzhao.vivecode.com> Message-ID: <4655DF75.3040809@trash.net> Jing Min Zhao wrote: > According to the implementation of H.323, it's not necessary to check the addresses in Information signals. Applied, thanks. From kaber at trash.net Thu May 24 20:55:38 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 22:02:13 2007 Subject: [PATCH 4/4] H.323: Check range first in sequence extension In-Reply-To: <20070517191757.1047E3DA1FB@jzhao.vivecode.com> References: <20070517191757.1047E3DA1FB@jzhao.vivecode.com> Message-ID: <4655DFAA.10107@trash.net> Jing Min Zhao wrote: > Check range before checking STOP flag. This optimization may save a nanosecond or less :) I'll queue this one for 2.6.23 since its a not too important optimization. From kaber at trash.net Thu May 24 20:58:47 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 22:05:17 2007 Subject: [PATCH] H.323: Add missing T.120 address in OLCA In-Reply-To: <20070517200033.B49F93DA1F7@jzhao.vivecode.com> References: <20070517200033.B49F93DA1F7@jzhao.vivecode.com> Message-ID: <4655E067.2010507@trash.net> Jing Min Zhao wrote: > Add missing process of T.120 address in OpenLogicalChannelAck signal. Applied, thanks. From kaber at trash.net Thu May 24 20:59:59 2007 From: kaber at trash.net (Patrick McHardy) Date: Thu May 24 22:06:26 2007 Subject: [PATCH] H.323: Call set_h225_addr instead of set_h225_addr_hook In-Reply-To: <20070518172427.C45313DA1F7@jzhao.vivecode.com> References: <20070518172427.C45313DA1F7@jzhao.vivecode.com> Message-ID: <4655E0AF.7060903@trash.net> Jing Min Zhao wrote: > They're the same. Also applied, thanks. From degraaf at cpsc.ucalgary.ca Thu May 24 23:22:23 2007 From: degraaf at cpsc.ucalgary.ca (Rennie deGraaf) Date: Fri May 25 00:25:48 2007 Subject: ip_rt_bug in mangle/OUTPUT In-Reply-To: <4655D083.8070309@trash.net> References: <4654AE59.3090506@cpsc.ucalgary.ca> <4655D083.8070309@trash.net> Message-ID: <4656020F.2060607@cpsc.ucalgary.ca> Patrick McHardy wrote: > Rennie deGraaf wrote: >> I seem to be getting the error message >> ip_rt_bug: 10.1.1.1 -> 10.0.1.2, ? >> whenever I attempt to send a packet with a non-local source IP address >> (my local IP address is 10.0.1.2) from libipq in mangle/OUTPUT. I have >> observed this behaviour under Linux kernels 2.6.20.7 and >> 2.6.18-1.2257.fc5smp (Fedora Core 5), and iptables versions 1.3.5 and >> 1.3.7. > > If you don't need the rerouting to be happen (you only change the > source address and don't use routing rules based on that) you can > simply return NF_STOP instead of NF_ACCEPT. It will do exactly > the same thing but avoid rerouting. Thanks; that did the trick. Rennie deGraaf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : /pipermail/netfilter-devel/attachments/20070525/fcb9b277/signature.pgp From kaber at trash.net Fri May 25 00:02:07 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:05:13 2007 Subject: [NETFILTER 01/07]: nf_conntrack_ftp: fix newline sequence number update In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524215835.14308.87748.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack_ftp: fix newline sequence number update When trying to locate the oldest entry in the history of newline character sequence numbers, the sequence number of the current entry is incorrectly compared with the index of the oldest sequence number instead of the number itself. Additionally it is not made sure that the current sequence number really is after the oldest known one. Based on report by YU, Haitao Signed-off-by: Patrick McHardy --- commit 5e09b4a295e2aed7cb6fe60f86bafba4d8e77836 tree fb2d6e90d04c155578a5fe3321f9b2297426bdee parent 0076b2cfaee8fa7109d6c923144b88f0032ffb8b author Patrick McHardy Thu, 24 May 2007 23:49:57 +0200 committer Patrick McHardy Thu, 24 May 2007 23:49:57 +0200 net/netfilter/nf_conntrack_ftp.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c index a186799..3357642 100644 --- a/net/netfilter/nf_conntrack_ftp.c +++ b/net/netfilter/nf_conntrack_ftp.c @@ -335,15 +335,17 @@ static void update_nl_seq(u32 nl_seq, struct nf_ct_ftp_master *info, int dir, if (info->seq_aft_nl[dir][i] == nl_seq) return; - if (oldest == info->seq_aft_nl_num[dir] - || before(info->seq_aft_nl[dir][i], oldest)) + if (oldest == info->seq_aft_nl_num[dir] || + before(info->seq_aft_nl[dir][i], + info->seq_aft_nl[dir][oldest])) oldest = i; } if (info->seq_aft_nl_num[dir] < NUM_SEQ_TO_REMEMBER) { info->seq_aft_nl[dir][info->seq_aft_nl_num[dir]++] = nl_seq; nf_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); - } else if (oldest != NUM_SEQ_TO_REMEMBER) { + } else if (oldest != NUM_SEQ_TO_REMEMBER && + after(nl_seq, info->seq_aft_nl[dir][oldest])) { info->seq_aft_nl[dir][oldest] = nl_seq; nf_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); } From kaber at trash.net Fri May 25 00:02:06 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:05:14 2007 Subject: [NETFILTER 00/07]: Netfilter fixes Message-ID: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Hi Dave, following are a couple of netfilter patches, fixing newline sequence number tracking problems with the FTP helper and a few problems with the H.323 helper, mostly related to tracking IPv6 connections. Please apply, thanks. include/linux/netfilter/nf_conntrack_ftp.h | 3 - include/linux/netfilter/nf_conntrack_h323_types.h | 23 +----------- net/ipv4/netfilter/nf_nat_ftp.c | 20 +++------- net/ipv4/netfilter/nf_nat_h323.c | 6 +-- net/netfilter/nf_conntrack_ftp.c | 13 +++--- net/netfilter/nf_conntrack_h323_main.c | 41 +++++----------------- net/netfilter/nf_conntrack_h323_types.c | 31 ++++++---------- 7 files changed, 44 insertions(+), 93 deletions(-) Jing Min Zhao (5): [NETFILTER]: nf_conntrack_h323: fix ASN.1 types [NETFILTER]: nf_conntrack_h323: fix get_h225_addr() for IPv6 address access [NETFILTER]: nf_conntrack_h323: remove unnecessary process of Information signal [NETFILTER]: nf_conntrack_h323: add missing T.120 address in OLCA [NETFILTER]: nf_nat_h323: call set_h225_addr instead of set_h225_addr_hook Patrick McHardy (2): [NETFILTER]: nf_conntrack_ftp: fix newline sequence number update [NETFILTER]: nf_conntrack_ftp: fix newline sequence number calculation From kaber at trash.net Fri May 25 00:02:09 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:05:15 2007 Subject: [NETFILTER 02/07]: nf_conntrack_ftp: fix newline sequence number calculation In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524215836.14308.55840.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack_ftp: fix newline sequence number calculation When the packet size is changed by the FTP NAT helper, the connection tracking helper adjusts the sequence number of the newline character by the size difference. This is wrong because NAT sequence number adjustment happens after helpers are called, so the unadjusted number is compared to the already adjusted one. Based on report by YU, Haitao Signed-off-by: Patrick McHardy --- commit 5dcf6ca671036446403108df0dbc025887e81fb4 tree 8a9e36277001fc9f4f6c2bf1d409f1c8a7c6964d parent 5e09b4a295e2aed7cb6fe60f86bafba4d8e77836 author Patrick McHardy Thu, 24 May 2007 23:49:57 +0200 committer Patrick McHardy Thu, 24 May 2007 23:49:57 +0200 include/linux/netfilter/nf_conntrack_ftp.h | 3 +-- net/ipv4/netfilter/nf_nat_ftp.c | 20 ++++++-------------- net/netfilter/nf_conntrack_ftp.c | 5 ++--- 3 files changed, 9 insertions(+), 19 deletions(-) diff --git a/include/linux/netfilter/nf_conntrack_ftp.h b/include/linux/netfilter/nf_conntrack_ftp.h index 81453ea..b7c360f 100644 --- a/include/linux/netfilter/nf_conntrack_ftp.h +++ b/include/linux/netfilter/nf_conntrack_ftp.h @@ -37,8 +37,7 @@ extern unsigned int (*nf_nat_ftp_hook)(struct sk_buff **pskb, enum nf_ct_ftp_type type, unsigned int matchoff, unsigned int matchlen, - struct nf_conntrack_expect *exp, - u32 *seq); + struct nf_conntrack_expect *exp); #endif /* __KERNEL__ */ #endif /* _NF_CONNTRACK_FTP_H */ diff --git a/net/ipv4/netfilter/nf_nat_ftp.c b/net/ipv4/netfilter/nf_nat_ftp.c index 751b598..e6bc8e5 100644 --- a/net/ipv4/netfilter/nf_nat_ftp.c +++ b/net/ipv4/netfilter/nf_nat_ftp.c @@ -40,8 +40,7 @@ mangle_rfc959_packet(struct sk_buff **pskb, unsigned int matchoff, unsigned int matchlen, struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - u32 *seq) + enum ip_conntrack_info ctinfo) { char buffer[sizeof("nnn,nnn,nnn,nnn,nnn,nnn")]; @@ -50,7 +49,6 @@ mangle_rfc959_packet(struct sk_buff **pskb, DEBUGP("calling nf_nat_mangle_tcp_packet\n"); - *seq += strlen(buffer) - matchlen; return nf_nat_mangle_tcp_packet(pskb, ct, ctinfo, matchoff, matchlen, buffer, strlen(buffer)); } @@ -63,8 +61,7 @@ mangle_eprt_packet(struct sk_buff **pskb, unsigned int matchoff, unsigned int matchlen, struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - u32 *seq) + enum ip_conntrack_info ctinfo) { char buffer[sizeof("|1|255.255.255.255|65535|")]; @@ -72,7 +69,6 @@ mangle_eprt_packet(struct sk_buff **pskb, DEBUGP("calling nf_nat_mangle_tcp_packet\n"); - *seq += strlen(buffer) - matchlen; return nf_nat_mangle_tcp_packet(pskb, ct, ctinfo, matchoff, matchlen, buffer, strlen(buffer)); } @@ -85,8 +81,7 @@ mangle_epsv_packet(struct sk_buff **pskb, unsigned int matchoff, unsigned int matchlen, struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - u32 *seq) + enum ip_conntrack_info ctinfo) { char buffer[sizeof("|||65535|")]; @@ -94,14 +89,13 @@ mangle_epsv_packet(struct sk_buff **pskb, DEBUGP("calling nf_nat_mangle_tcp_packet\n"); - *seq += strlen(buffer) - matchlen; return nf_nat_mangle_tcp_packet(pskb, ct, ctinfo, matchoff, matchlen, buffer, strlen(buffer)); } static int (*mangle[])(struct sk_buff **, __be32, u_int16_t, unsigned int, unsigned int, struct nf_conn *, - enum ip_conntrack_info, u32 *seq) + enum ip_conntrack_info) = { [NF_CT_FTP_PORT] = mangle_rfc959_packet, [NF_CT_FTP_PASV] = mangle_rfc959_packet, @@ -116,8 +110,7 @@ static unsigned int nf_nat_ftp(struct sk_buff **pskb, enum nf_ct_ftp_type type, unsigned int matchoff, unsigned int matchlen, - struct nf_conntrack_expect *exp, - u32 *seq) + struct nf_conntrack_expect *exp) { __be32 newip; u_int16_t port; @@ -145,8 +138,7 @@ static unsigned int nf_nat_ftp(struct sk_buff **pskb, if (port == 0) return NF_DROP; - if (!mangle[type](pskb, newip, port, matchoff, matchlen, ct, ctinfo, - seq)) { + if (!mangle[type](pskb, newip, port, matchoff, matchlen, ct, ctinfo)) { nf_conntrack_unexpect_related(exp); return NF_DROP; } diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c index 3357642..09add2f 100644 --- a/net/netfilter/nf_conntrack_ftp.c +++ b/net/netfilter/nf_conntrack_ftp.c @@ -48,8 +48,7 @@ unsigned int (*nf_nat_ftp_hook)(struct sk_buff **pskb, enum nf_ct_ftp_type type, unsigned int matchoff, unsigned int matchlen, - struct nf_conntrack_expect *exp, - u32 *seq); + struct nf_conntrack_expect *exp); EXPORT_SYMBOL_GPL(nf_nat_ftp_hook); #if 0 @@ -521,7 +520,7 @@ static int help(struct sk_buff **pskb, nf_nat_ftp = rcu_dereference(nf_nat_ftp_hook); if (nf_nat_ftp && ct->status & IPS_NAT_MASK) ret = nf_nat_ftp(pskb, ctinfo, search[dir][i].ftptype, - matchoff, matchlen, exp, &seq); + matchoff, matchlen, exp); else { /* Can't expect this? Best to drop packet now. */ if (nf_conntrack_expect_related(exp) != 0) From kaber at trash.net Fri May 25 00:02:11 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:05:18 2007 Subject: [NETFILTER 04/07]: nf_conntrack_h323: fix get_h225_addr() for IPv6 address access In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524215839.14308.34047.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack_h323: fix get_h225_addr() for IPv6 address access Update get_h225_addr() to meet the changes in ASN.1 types. It was using field ip6 to access IPv6 TransportAddress, it should be ip according the ASN.1 definition. Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit e71d7c2a5a69f20bd077b91bcc240f7bada53e48 tree 32a4cdeaa054fe66448d43d0255337e8f330d61b parent bd086e2d746d2c730c5701b09a1198bf6d335287 author Jing Min Zhao Thu, 24 May 2007 23:49:58 +0200 committer Patrick McHardy Thu, 24 May 2007 23:49:58 +0200 net/netfilter/nf_conntrack_h323_main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c index b284db7..8bb99b3 100644 --- a/net/netfilter/nf_conntrack_h323_main.c +++ b/net/netfilter/nf_conntrack_h323_main.c @@ -640,7 +640,7 @@ int get_h225_addr(struct nf_conn *ct, unsigned char *data, case eTransportAddress_ip6Address: if (family != AF_INET6) return 0; - p = data + taddr->ip6Address.ip6; + p = data + taddr->ip6Address.ip; len = 16; break; default: From kaber at trash.net Fri May 25 00:02:10 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:05:20 2007 Subject: [NETFILTER 03/07]: nf_conntrack_h323: fix ASN.1 types In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524215837.14308.73241.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack_h323: fix ASN.1 types 1. Add support for decoding IPv6 address. I know it was manually added in the header file, but not in the template file. That wouldn't work. 2. Add missing support for decoding T.120 address in OLCA. 3. Remove unnecessary decoding of Information signal. Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit bd086e2d746d2c730c5701b09a1198bf6d335287 tree 10f40e7fa3be7d93b4e6a39ffefad839c295b778 parent 5dcf6ca671036446403108df0dbc025887e81fb4 author Jing Min Zhao Thu, 24 May 2007 23:49:57 +0200 committer Patrick McHardy Thu, 24 May 2007 23:49:57 +0200 include/linux/netfilter/nf_conntrack_h323_types.h | 23 ++-------------- net/netfilter/nf_conntrack_h323_types.c | 31 +++++++++------------ 2 files changed, 16 insertions(+), 38 deletions(-) diff --git a/include/linux/netfilter/nf_conntrack_h323_types.h b/include/linux/netfilter/nf_conntrack_h323_types.h index 38d74d5..f35b6b4 100644 --- a/include/linux/netfilter/nf_conntrack_h323_types.h +++ b/include/linux/netfilter/nf_conntrack_h323_types.h @@ -1,4 +1,4 @@ -/* Generated by Jing Min Zhao's ASN.1 parser, Apr 20 2006 +/* Generated by Jing Min Zhao's ASN.1 parser, May 16 2007 * * Copyright (c) 2006 Jing Min Zhao * @@ -12,7 +12,7 @@ typedef struct TransportAddress_ipAddress { /* SEQUENCE */ typedef struct TransportAddress_ip6Address { /* SEQUENCE */ int options; /* No use */ - unsigned ip6; + unsigned ip; } TransportAddress_ip6Address; typedef struct TransportAddress { /* CHOICE */ @@ -364,23 +364,6 @@ typedef struct Alerting_UUIE { /* SEQUENCE */ 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, @@ -471,7 +454,6 @@ typedef struct H323_UU_PDU_h323_message_body { /* CHOICE */ CallProceeding_UUIE callProceeding; Connect_UUIE connect; Alerting_UUIE alerting; - Information_UUIE information; Facility_UUIE facility; Progress_UUIE progress; }; @@ -561,6 +543,7 @@ typedef struct OpenLogicalChannelAck { /* SEQUENCE */ } options; OpenLogicalChannelAck_reverseLogicalChannelParameters reverseLogicalChannelParameters; + NetworkAccessParameters separateStack; OpenLogicalChannelAck_forwardMultiplexAckParameters forwardMultiplexAckParameters; } OpenLogicalChannelAck; diff --git a/net/netfilter/nf_conntrack_h323_types.c b/net/netfilter/nf_conntrack_h323_types.c index 4c6f8b3..3a21fdf 100644 --- a/net/netfilter/nf_conntrack_h323_types.c +++ b/net/netfilter/nf_conntrack_h323_types.c @@ -1,4 +1,4 @@ -/* Generated by Jing Min Zhao's ASN.1 parser, Apr 20 2006 +/* Generated by Jing Min Zhao's ASN.1 parser, May 16 2007 * * Copyright (c) 2006 Jing Min Zhao * @@ -37,7 +37,7 @@ static field_t _TransportAddress_ipxAddress[] = { /* SEQUENCE */ static field_t _TransportAddress_ip6Address[] = { /* SEQUENCE */ {FNAME("ip") OCTSTR, FIXD, 16, 0, DECODE, - offsetof(TransportAddress_ip6Address, ip6), NULL}, + offsetof(TransportAddress_ip6Address, ip), NULL}, {FNAME("port") INT, WORD, 0, 0, SKIP, 0, NULL}, }; @@ -67,7 +67,8 @@ static field_t _TransportAddress[] = { /* CHOICE */ {FNAME("ipxAddress") SEQ, 0, 3, 3, SKIP, 0, _TransportAddress_ipxAddress}, {FNAME("ip6Address") SEQ, 0, 2, 2, DECODE | EXT, - offsetof(TransportAddress, ip6Address), _TransportAddress_ip6Address}, + offsetof(TransportAddress, ip6Address), + _TransportAddress_ip6Address}, {FNAME("netBios") OCTSTR, FIXD, 16, 0, SKIP, 0, NULL}, {FNAME("nsap") OCTSTR, 5, 1, 0, SKIP, 0, NULL}, {FNAME("nonStandardAddress") SEQ, 0, 2, 2, SKIP, 0, @@ -638,7 +639,8 @@ static field_t _UnicastAddress_iPXAddress[] = { /* SEQUENCE */ }; static field_t _UnicastAddress_iP6Address[] = { /* SEQUENCE */ - {FNAME("network") OCTSTR, FIXD, 16, 0, SKIP, 0, NULL}, + {FNAME("network") OCTSTR, FIXD, 16, 0, DECODE, + offsetof(UnicastAddress_iP6Address, network), NULL}, {FNAME("tsapIdentifier") INT, WORD, 0, 0, SKIP, 0, NULL}, }; @@ -665,8 +667,8 @@ static field_t _UnicastAddress[] = { /* CHOICE */ offsetof(UnicastAddress, iPAddress), _UnicastAddress_iPAddress}, {FNAME("iPXAddress") SEQ, 0, 3, 3, SKIP | EXT, 0, _UnicastAddress_iPXAddress}, - {FNAME("iP6Address") SEQ, 0, 2, 2, SKIP | EXT, 0, - _UnicastAddress_iP6Address}, + {FNAME("iP6Address") SEQ, 0, 2, 2, DECODE | EXT, + offsetof(UnicastAddress, iP6Address), _UnicastAddress_iP6Address}, {FNAME("netBios") OCTSTR, FIXD, 16, 0, SKIP, 0, NULL}, {FNAME("iPSourceRouteAddress") SEQ, 0, 4, 4, SKIP | EXT, 0, _UnicastAddress_iPSourceRouteAddress}, @@ -984,19 +986,12 @@ static field_t _Alerting_UUIE[] = { /* SEQUENCE */ {FNAME("featureSet") SEQ, 3, 4, 4, SKIP | EXT | OPT, 0, NULL}, }; -static field_t _Information_UUIE_fastStart[] = { /* SEQUENCE OF */ - {FNAME("item") SEQ, 1, 3, 5, DECODE | OPEN | EXT, - sizeof(OpenLogicalChannel), _OpenLogicalChannel} - , -}; - static field_t _Information_UUIE[] = { /* SEQUENCE */ {FNAME("protocolIdentifier") OID, BYTE, 0, 0, SKIP, 0, NULL}, {FNAME("callIdentifier") SEQ, 0, 1, 1, SKIP | EXT, 0, NULL}, {FNAME("tokens") SEQOF, SEMI, 0, 0, SKIP | OPT, 0, NULL}, {FNAME("cryptoTokens") SEQOF, SEMI, 0, 0, SKIP | OPT, 0, NULL}, - {FNAME("fastStart") SEQOF, SEMI, 0, 30, DECODE | OPT, - offsetof(Information_UUIE, fastStart), _Information_UUIE_fastStart}, + {FNAME("fastStart") SEQOF, SEMI, 0, 30, SKIP | OPT, 0, NULL}, {FNAME("fastConnectRefused") NUL, FIXD, 0, 0, SKIP | OPT, 0, NULL}, {FNAME("circuitInfo") SEQ, 3, 3, 3, SKIP | EXT | OPT, 0, NULL}, }; @@ -1343,9 +1338,7 @@ static field_t _H323_UU_PDU_h323_message_body[] = { /* CHOICE */ offsetof(H323_UU_PDU_h323_message_body, connect), _Connect_UUIE}, {FNAME("alerting") SEQ, 1, 3, 17, DECODE | EXT, offsetof(H323_UU_PDU_h323_message_body, alerting), _Alerting_UUIE}, - {FNAME("information") SEQ, 0, 1, 7, DECODE | EXT, - offsetof(H323_UU_PDU_h323_message_body, information), - _Information_UUIE}, + {FNAME("information") SEQ, 0, 1, 7, SKIP | EXT, 0, _Information_UUIE}, {FNAME("releaseComplete") SEQ, 1, 2, 11, SKIP | EXT, 0, _ReleaseComplete_UUIE}, {FNAME("facility") SEQ, 3, 5, 21, DECODE | EXT, @@ -1430,7 +1423,9 @@ static field_t _OpenLogicalChannelAck[] = { /* SEQUENCE */ DECODE | EXT | OPT, offsetof(OpenLogicalChannelAck, reverseLogicalChannelParameters), _OpenLogicalChannelAck_reverseLogicalChannelParameters}, - {FNAME("separateStack") SEQ, 2, 4, 5, SKIP | EXT | OPT, 0, NULL}, + {FNAME("separateStack") SEQ, 2, 4, 5, DECODE | EXT | OPT, + offsetof(OpenLogicalChannelAck, separateStack), + _NetworkAccessParameters}, {FNAME("forwardMultiplexAckParameters") CHOICE, 0, 1, 1, DECODE | EXT | OPT, offsetof(OpenLogicalChannelAck, forwardMultiplexAckParameters), From kaber at trash.net Fri May 25 00:02:14 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:05:50 2007 Subject: [NETFILTER 06/07]: nf_conntrack_h323: add missing T.120 address in OLCA In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524215841.14308.81491.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack_h323: add missing T.120 address in OLCA Add missing process of T.120 address in OpenLogicalChannelAck signal. Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit 9a545fc8e2ac3c8c7bbb7315469d96bb4e7d8748 tree c06c911468eaf5c32531a940c5b740cdb41ab0fa parent 6fdca918957ecf41e1b5c416df341cfa48080fcd author Jing Min Zhao Thu, 24 May 2007 23:49:59 +0200 committer Patrick McHardy Thu, 24 May 2007 23:49:59 +0200 net/netfilter/nf_conntrack_h323_main.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c index 6d668af..a1b95ac 100644 --- a/net/netfilter/nf_conntrack_h323_main.c +++ b/net/netfilter/nf_conntrack_h323_main.c @@ -520,6 +520,16 @@ static int process_olca(struct sk_buff **pskb, struct nf_conn *ct, } } + if ((olca->options & eOpenLogicalChannelAck_separateStack) && + olca->separateStack.networkAddress.choice == + eNetworkAccessParameters_networkAddress_localAreaAddress) { + ret = expect_t120(pskb, ct, ctinfo, data, dataoff, + &olca->separateStack.networkAddress. + localAreaAddress); + if (ret < 0) + return -1; + } + return 0; } From kaber at trash.net Fri May 25 00:02:15 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:05:58 2007 Subject: [NETFILTER 07/07]: nf_nat_h323: call set_h225_addr instead of set_h225_addr_hook In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524215843.14308.46250.sendpatchset@localhost.localdomain> [NETFILTER]: nf_nat_h323: call set_h225_addr instead of set_h225_addr_hook They're the same. Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit ed22d6f07f4ac4b69b915df2d1798e171b501a47 tree 1accab86c105558c5ac6a9c094ac6bc9aef3288d parent 9a545fc8e2ac3c8c7bbb7315469d96bb4e7d8748 author Jing Min Zhao Thu, 24 May 2007 23:50:52 +0200 committer Patrick McHardy Thu, 24 May 2007 23:50:52 +0200 net/ipv4/netfilter/nf_nat_h323.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/net/ipv4/netfilter/nf_nat_h323.c b/net/ipv4/netfilter/nf_nat_h323.c index fcebc96..c5d2a2d 100644 --- a/net/ipv4/netfilter/nf_nat_h323.c +++ b/net/ipv4/netfilter/nf_nat_h323.c @@ -455,9 +455,9 @@ static int nat_q931(struct sk_buff **pskb, struct nf_conn *ct, if (idx > 0 && get_h225_addr(ct, *data, &taddr[0], &addr, &port) && (ntohl(addr.ip) & 0xff000000) == 0x7f000000) { - set_h225_addr_hook(pskb, data, 0, &taddr[0], - &ct->tuplehash[!dir].tuple.dst.u3, - info->sig_port[!dir]); + set_h225_addr(pskb, data, 0, &taddr[0], + &ct->tuplehash[!dir].tuple.dst.u3, + info->sig_port[!dir]); } } else { nf_conntrack_unexpect_related(exp); From kaber at trash.net Fri May 25 00:02:13 2007 From: kaber at trash.net (Patrick McHardy) Date: Fri May 25 01:06:00 2007 Subject: [NETFILTER 05/07]: nf_conntrack_h323: remove unnecessary process of Information signal In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524215840.14308.13646.sendpatchset@localhost.localdomain> [NETFILTER]: nf_conntrack_h323: remove unnecessary process of Information signal According to the implementation of H.323, it's not necessary to check the addresses in Information signals. Signed-off-by: Jing Min Zhao Signed-off-by: Patrick McHardy --- commit 6fdca918957ecf41e1b5c416df341cfa48080fcd tree 16a0761c152686fb74b89e81d4d67d6a329ab540 parent e71d7c2a5a69f20bd077b91bcc240f7bada53e48 author Jing Min Zhao Thu, 24 May 2007 23:49:58 +0200 committer Patrick McHardy Thu, 24 May 2007 23:49:58 +0200 net/netfilter/nf_conntrack_h323_main.c | 29 ----------------------------- 1 files changed, 0 insertions(+), 29 deletions(-) diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c index 8bb99b3..6d668af 100644 --- a/net/netfilter/nf_conntrack_h323_main.c +++ b/net/netfilter/nf_conntrack_h323_main.c @@ -977,30 +977,6 @@ static int process_alerting(struct sk_buff **pskb, struct nf_conn *ct, } /****************************************************************************/ -static int process_information(struct sk_buff **pskb, - struct nf_conn *ct, - enum ip_conntrack_info ctinfo, - unsigned char **data, int dataoff, - Information_UUIE *info) -{ - int ret; - int i; - - DEBUGP("nf_ct_q931: Information\n"); - - if (info->options & eInformation_UUIE_fastStart) { - for (i = 0; i < info->fastStart.count; i++) { - ret = process_olc(pskb, ct, ctinfo, data, dataoff, - &info->fastStart.item[i]); - if (ret < 0) - return -1; - } - } - - return 0; -} - -/****************************************************************************/ static int process_facility(struct sk_buff **pskb, struct nf_conn *ct, enum ip_conntrack_info ctinfo, unsigned char **data, int dataoff, @@ -1096,11 +1072,6 @@ static int process_q931(struct sk_buff **pskb, struct nf_conn *ct, ret = process_alerting(pskb, ct, ctinfo, data, dataoff, &pdu->h323_message_body.alerting); break; - case eH323_UU_PDU_h323_message_body_information: - ret = process_information(pskb, ct, ctinfo, data, dataoff, - &pdu->h323_message_body. - information); - break; case eH323_UU_PDU_h323_message_body_facility: ret = process_facility(pskb, ct, ctinfo, data, dataoff, &pdu->h323_message_body.facility); From philipc at snapgear.com Fri May 25 01:07:11 2007 From: philipc at snapgear.com (Philip Craig) Date: Fri May 25 02:10:50 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <4655CEB0.4060306@trash.net> References: <465528CB.4020108@snapgear.com> <4655CEB0.4060306@trash.net> Message-ID: <46561A9F.2010800@snapgear.com> Patrick McHardy wrote: > I don't like the kernel-internal fiddling with the flags too > much, but I don't see a way around it. The other idea I had was moving the interface matching into an internal match that would be checked by IPT_MATCH_ITERATE(). Not sure if this is feasible yet. > userspace should just ignore unknown flags. I was trying to completely hide them from userspace so that we still have the option to use them for something else later on. If we ever send them to userspace, then they are taken forever, otherwise a newer iptables userspace may not work with an older kernel. From davem at davemloft.net Fri May 25 01:41:25 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:43:53 2007 Subject: [NETFILTER 01/07]: nf_conntrack_ftp: fix newline sequence number update In-Reply-To: <20070524215835.14308.87748.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> <20070524215835.14308.87748.sendpatchset@localhost.localdomain> Message-ID: <20070524.164125.102140251.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:07 +0200 (MEST) > [NETFILTER]: nf_conntrack_ftp: fix newline sequence number update > > When trying to locate the oldest entry in the history of newline character > sequence numbers, the sequence number of the current entry is incorrectly > compared with the index of the oldest sequence number instead of the number > itself. > > Additionally it is not made sure that the current sequence number really > is after the oldest known one. > > Based on report by YU, Haitao > > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Fri May 25 01:41:59 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:44:28 2007 Subject: [NETFILTER 02/07]: nf_conntrack_ftp: fix newline sequence number calculation In-Reply-To: <20070524215836.14308.55840.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> <20070524215836.14308.55840.sendpatchset@localhost.localdomain> Message-ID: <20070524.164159.82356841.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:09 +0200 (MEST) > [NETFILTER]: nf_conntrack_ftp: fix newline sequence number calculation > > When the packet size is changed by the FTP NAT helper, the connection > tracking helper adjusts the sequence number of the newline character > by the size difference. This is wrong because NAT sequence number > adjustment happens after helpers are called, so the unadjusted number > is compared to the already adjusted one. > > Based on report by YU, Haitao > > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Fri May 25 01:42:37 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:45:06 2007 Subject: [NETFILTER 03/07]: nf_conntrack_h323: fix ASN.1 types In-Reply-To: <20070524215837.14308.73241.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> <20070524215837.14308.73241.sendpatchset@localhost.localdomain> Message-ID: <20070524.164237.40815199.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:10 +0200 (MEST) > [NETFILTER]: nf_conntrack_h323: fix ASN.1 types > > 1. Add support for decoding IPv6 address. I know it was manually added in > the header file, but not in the template file. That wouldn't work. > 2. Add missing support for decoding T.120 address in OLCA. > 3. Remove unnecessary decoding of Information signal. > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Fri May 25 01:43:16 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:45:44 2007 Subject: [NETFILTER 04/07]: nf_conntrack_h323: fix get_h225_addr() for IPv6 address access In-Reply-To: <20070524215839.14308.34047.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> <20070524215839.14308.34047.sendpatchset@localhost.localdomain> Message-ID: <20070524.164316.116369836.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:11 +0200 (MEST) > [NETFILTER]: nf_conntrack_h323: fix get_h225_addr() for IPv6 address access > > Update get_h225_addr() to meet the changes in ASN.1 types. It was using > field ip6 to access IPv6 TransportAddress, it should be ip according the > ASN.1 definition. > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Fri May 25 01:43:50 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:46:17 2007 Subject: [NETFILTER 05/07]: nf_conntrack_h323: remove unnecessary process of Information signal In-Reply-To: <20070524215840.14308.13646.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> <20070524215840.14308.13646.sendpatchset@localhost.localdomain> Message-ID: <20070524.164350.00947834.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:13 +0200 (MEST) > [NETFILTER]: nf_conntrack_h323: remove unnecessary process of Information signal > > According to the implementation of H.323, it's not necessary to check the > addresses in Information signals. > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Fri May 25 01:44:21 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:46:50 2007 Subject: [NETFILTER 06/07]: nf_conntrack_h323: add missing T.120 address in OLCA In-Reply-To: <20070524215841.14308.81491.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> <20070524215841.14308.81491.sendpatchset@localhost.localdomain> Message-ID: <20070524.164421.78476503.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:14 +0200 (MEST) > [NETFILTER]: nf_conntrack_h323: add missing T.120 address in OLCA > > Add missing process of T.120 address in OpenLogicalChannelAck signal. > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Fri May 25 01:44:49 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:47:24 2007 Subject: [NETFILTER 07/07]: nf_nat_h323: call set_h225_addr instead of set_h225_addr_hook In-Reply-To: <20070524215843.14308.46250.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> <20070524215843.14308.46250.sendpatchset@localhost.localdomain> Message-ID: <20070524.164449.123904257.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:15 +0200 (MEST) > [NETFILTER]: nf_nat_h323: call set_h225_addr instead of set_h225_addr_hook > > They're the same. > > Signed-off-by: Jing Min Zhao > Signed-off-by: Patrick McHardy Applied. From davem at davemloft.net Fri May 25 01:45:01 2007 From: davem at davemloft.net (David Miller) Date: Fri May 25 02:47:36 2007 Subject: [NETFILTER 00/07]: Netfilter fixes In-Reply-To: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> References: <20070524215833.14308.60841.sendpatchset@localhost.localdomain> Message-ID: <20070524.164501.99474219.davem@davemloft.net> From: Patrick McHardy Date: Fri, 25 May 2007 00:02:06 +0200 (MEST) > following are a couple of netfilter patches, fixing newline sequence number > tracking problems with the FTP helper and a few problems with the H.323 > helper, mostly related to tracking IPv6 connections. > > Please apply, thanks. All applied, thanks Patrick. From yasuyuki.kozakai at toshiba.co.jp Fri May 25 02:44:03 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri May 25 03:46:52 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <465528CB.4020108@snapgear.com> References: <465528CB.4020108@snapgear.com> Message-ID: <200705250044.l4P0i3f8007580@toshiba.co.jp> Hi, Philip, From: Philip Craig Date: Thu, 24 May 2007 15:55:23 +1000 > Optimise iptables for rules that specify 0 or 1 interface matches, > which is the more common case (at least for my rulesets). > /* Look for ifname matches; this should unroll nicely. */ > - for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { > - ret |= (((const unsigned long *)indev)[i] > - ^ ((const unsigned long *)ipinfo->iniface)[i]) > - & ((const unsigned long *)ipinfo->iniface_mask)[i]; > - } > + if (ipinfo->flags & IPT_F_VIA_IN) { > + for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { > + ret |= (((const unsigned long *)indev)[i] > + ^ ((const unsigned long *)ipinfo->iniface)[i]) > + & ((const unsigned long *)ipinfo->iniface_mask)[i]; > + } This breaks binary compatibility. The current userspace programs do not set this bit. And ip_checkentry() in all kernel before you change will reject unknown flags from new userspace programs. Actually, we cannot add a new flag to 'struct ipt_ip'. It does not have revision field. Unfortunately it has no field such as name[] in 'struct xt_entry_match' to steal one octet for revision. I expect that this optimization will be done when we introduce netlink interface. -- Yasuyuki Kozakai From philipc at snapgear.com Fri May 25 02:56:10 2007 From: philipc at snapgear.com (Philip Craig) Date: Fri May 25 03:59:45 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <200705250044.l4P0i3f8007580@toshiba.co.jp> References: <465528CB.4020108@snapgear.com> <200705250044.l4P0i3f8007580@toshiba.co.jp> Message-ID: <4656342A.5040202@snapgear.com> Yasuyuki KOZAKAI wrote: > This breaks binary compatibility. The current userspace programs do not set > this bit. And ip_checkentry() in all kernel before you change will reject > unknown flags from new userspace programs. Userspace doesn't need to set it because the kernel can derive it automatically (which I've done in ip_checkentry). Basically I just needed two bits of internal state, and the flags field looked like a convenient place for this. Userspace should be completely ignorant of these bits. > Actually, we cannot add a new flag to 'struct ipt_ip'. It does not have > revision field. Unfortunately it has no field such as name[] in > 'struct xt_entry_match' to steal one octet for revision. If we can never add new flags, then that would be a reason for me to not bother with clearing the internal bits before sending to userspace. > I expect that this optimization will be done when we introduce netlink > interface. Yes, I'm happy to just keep a local patch until then if you don't think it is worth it. From yuhaitao at tsinghua.org.cn Fri May 25 03:10:57 2007 From: yuhaitao at tsinghua.org.cn (YU, Haitao) Date: Fri May 25 04:26:48 2007 Subject: bugs in ftp conntrack Message-ID: <380055457.11873@tsinghua.org.cn> In your mail: >From: Patrick McHardy >Reply-To: >To: "YU, Haitao" >Subject: Re: bugs in ftp conntrack >Date:Thu, 24 May 2007 20:16:05 +0200 > > >There's not much we can do about this case, we already keep a history >of sequence numbers. As you note below that code is pretty broken >currently, but I have patches queued to fix it (attached to this mail). > I think if it's possible that we don't record the new seqence of too new packets. "Too new packets" means the sequence of the packet is greater than all seq_aft_nl[] values. We just wait until another "port", "227", etc. packet is parsed correctly. So the return value of function find_nl_seq() shoule be three: 1: too new, then parse pattern, only if found > 0, then update seq, else keep current seq_aft_nl; 0: match one of the remembered seq, then parse pattern, update seq when found >= 0; -1: too old(less than all remembered seq), just goto out, (not goto out_update_nl) Thanks, YU, Haitao From yasuyuki.kozakai at toshiba.co.jp Fri May 25 06:11:41 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri May 25 07:14:34 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <4656342A.5040202@snapgear.com> References: <465528CB.4020108@snapgear.com> <200705250044.l4P0i3f8007580@toshiba.co.jp> <4656342A.5040202@snapgear.com> Message-ID: <200705250411.l4P4Bg6U021261@toshiba.co.jp> From: Philip Craig Date: Fri, 25 May 2007 10:56:10 +1000 > Yasuyuki KOZAKAI wrote: > > This breaks binary compatibility. The current userspace programs do not set > > this bit. And ip_checkentry() in all kernel before you change will reject > > unknown flags from new userspace programs. > > Userspace doesn't need to set it because the kernel can derive it > automatically (which I've done in ip_checkentry). > Basically I just needed two bits of internal state, and the flags > field looked like a convenient place for this. Userspace should > be completely ignorant of these bits. Ah, indeed, thanks for explanation. -- Yasuyuki Kozakai From yasuyuki.kozakai at toshiba.co.jp Fri May 25 10:10:01 2007 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri May 25 11:12:41 2007 Subject: [PATCH]: ip6_tables: Fixes explanation of valid upper protocol number Message-ID: <200705250810.l4P8A2ab020658@toshiba.co.jp> This explains the allowed upper protocol numbers. IP6T_F_NOPROTO was introduced to use 0 as Hop-by-Hop option header, not wildcard. But that seemed to be forgotten. 0 has been used as wildcard since 2002-08-23. Signed-off-by: Yasuyuki Kozakai --- include/linux/netfilter_ipv6/ip6_tables.h | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/linux/netfilter_ipv6/ip6_tables.h b/include/linux/netfilter_ipv6/ip6_tables.h index 4686f83..5641f03 100644 --- a/include/linux/netfilter_ipv6/ip6_tables.h +++ b/include/linux/netfilter_ipv6/ip6_tables.h @@ -44,8 +44,14 @@ struct ip6t_ip6 { char iniface[IFNAMSIZ], outiface[IFNAMSIZ]; unsigned char iniface_mask[IFNAMSIZ], outiface_mask[IFNAMSIZ]; - /* ARGH, HopByHop uses 0, so can't do 0 = ANY, - instead IP6T_F_NOPROTO must be set */ + /* Upper protocol number + * - The allowed value is 0 (any) or protocol number of last parsable + * header, which is 50 (ESP), 59 (No Next Header), 135 (MH), or + * the non IPv6 extension headers. + * - The protocol numbers of IPv6 extension headers except of ESP and + * MH do not match any packets. + * - You also need to set IP6T_FLAGS_PROTO to "flags" to check protocol. + */ u_int16_t proto; /* TOS to match iff flags & IP6T_F_TOS */ u_int8_t tos; -- 1.4.4 From kadlec at blackhole.kfki.hu Fri May 25 16:04:51 2007 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Fri May 25 17:07:44 2007 Subject: problems applying ipset patch In-Reply-To: <4655B3A8.10809@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> Message-ID: On Thu, 24 May 2007, Andrea wrote: > Another issue: trying to modify iptables rules file, I obtain something like: > > "iptables-restore v1.2.11: no command specified" > > Maybe is there a mess between old and new version of iptables? Yes, it seem so. You wrote that you upgraded to the version 1.3.7. So there must be at least two sets of iptables(-save|restore) commands on your machine. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From andang76 at gmail.com Fri May 25 18:53:18 2007 From: andang76 at gmail.com (Andrea) Date: Fri May 25 19:56:00 2007 Subject: problems applying ipset patch In-Reply-To: References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> Message-ID: <4657147E.7040602@gmail.com> Jozsef Kadlecsik ha scritto: > Yes, it seem so. You wrote that you upgraded to the version 1.3.7. > So there must be at least two sets of iptables(-save|restore) commands > on your machine. is there a method to resolve this mess? I could try to remove old version of iptables with "yum remove iptables", but this command also removes dependency of Shorewall, wich I would preserve. From henrik at henriknordstrom.net Sat May 26 05:24:39 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Sat May 26 06:27:28 2007 Subject: problems applying ipset patch In-Reply-To: <4657147E.7040602@gmail.com> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> <4657147E.7040602@gmail.com> Message-ID: <1180149879.304.16.camel@henriknordstrom.net> fre 2007-05-25 klockan 18:53 +0200 skrev Andrea: > is there a method to resolve this mess? I could try to remove old > version of iptables with "yum remove iptables", but this command also > removes dependency of Shorewall, wich I would preserve. Specify the full path to the correct binary. You most likely have the yum installed one in /sbin, and the manually installed one in /usr/local/sbin/ Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070526/c66c76a0/attachment.pgp From henrik at henriknordstrom.net Sat May 26 05:28:52 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Sat May 26 06:31:38 2007 Subject: bugs in ftp conntrack In-Reply-To: <380055457.11873@tsinghua.org.cn> References: <380055457.11873@tsinghua.org.cn> Message-ID: <1180150132.304.21.camel@henriknordstrom.net> fre 2007-05-25 klockan 09:10 +0800 skrev YU, Haitao: > I think if it's possible that we don't record the new seqence of too new packets. > "Too new packets" means the sequence of the packet is greater than all > seq_aft_nl[] values. We just wait until another "port", "227", etc. packet is > parsed correctly. The best (save for doing a full TCP stream reassembly or proxying) would be to drop such out-of-order packets, relying on the sender to retransmit them later.. Might result in quite inefficient communication, but will make the protocol parsing behave correctly. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070526/195eadce/attachment.pgp From kaber at trash.net Sat May 26 10:47:56 2007 From: kaber at trash.net (Patrick McHardy) Date: Sat May 26 11:51:34 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <46561A9F.2010800@snapgear.com> References: <465528CB.4020108@snapgear.com> <4655CEB0.4060306@trash.net> <46561A9F.2010800@snapgear.com> Message-ID: <4657F43C.2000306@trash.net> Philip Craig wrote: > Patrick McHardy wrote: > >>I don't like the kernel-internal fiddling with the flags too >>much, but I don't see a way around it. > > > The other idea I had was moving the interface matching into > an internal match that would be checked by IPT_MATCH_ITERATE(). > Not sure if this is feasible yet. Mhh .. probably not since you would have to put it somewhere in the blob. >>userspace should just ignore unknown flags. > > > I was trying to completely hide them from userspace so that we > still have the option to use them for something else later on. > If we ever send them to userspace, then they are taken forever, > otherwise a newer iptables userspace may not work with an older > kernel. We could do that, but we would need some other place to store them since once we want to use them for something new we can't put them in ->flags anymore. From kaber at trash.net Sat May 26 11:03:35 2007 From: kaber at trash.net (Patrick McHardy) Date: Sat May 26 12:07:14 2007 Subject: bugs in ftp conntrack In-Reply-To: <380055457.11873@tsinghua.org.cn> References: <380055457.11873@tsinghua.org.cn> Message-ID: <4657F7E7.8040605@trash.net> YU, Haitao wrote: >>From: Patrick McHardy >> >>There's not much we can do about this case, we already keep a history >>of sequence numbers. As you note below that code is pretty broken >>currently, but I have patches queued to fix it (attached to this mail). >> > > > > I think if it's possible that we don't record the new seqence of too new packets. > "Too new packets" means the sequence of the packet is greater than all > seq_aft_nl[] values. We just wait until another "port", "227", etc. packet is > parsed correctly. > > > So the return value of function find_nl_seq() shoule be three: > 1: too new, then parse pattern, only if found > 0, then update seq, else keep > current seq_aft_nl; > 0: match one of the remembered seq, then parse pattern, update seq when found >= > 0; > -1: too old(less than all remembered seq), just goto out, (not goto > out_update_nl) Would you mind sending a patch to demonstrate your idea? From kaber at trash.net Sat May 26 11:07:32 2007 From: kaber at trash.net (Patrick McHardy) Date: Sat May 26 12:11:11 2007 Subject: bugs in ftp conntrack In-Reply-To: <1180150132.304.21.camel@henriknordstrom.net> References: <380055457.11873@tsinghua.org.cn> <1180150132.304.21.camel@henriknordstrom.net> Message-ID: <4657F8D4.8070202@trash.net> Henrik Nordstrom wrote: > fre 2007-05-25 klockan 09:10 +0800 skrev YU, Haitao: > > >>I think if it's possible that we don't record the new seqence of too new packets. >>"Too new packets" means the sequence of the packet is greater than all >>seq_aft_nl[] values. We just wait until another "port", "227", etc. packet is >>parsed correctly. > > > The best (save for doing a full TCP stream reassembly or proxying) would > be to drop such out-of-order packets, relying on the sender to > retransmit them later.. Might result in quite inefficient > communication, but will make the protocol parsing behave correctly. That also sounds like a good idea. We shouldn't see any reordering in FTP command streams since clients usually wait for an reply before sending the next command (at least I believe so, or is it always?), so I'm not too worried about inefficient communication. That would also allow to find silly bugs in newline sequence number tracking faster :) From kaber at trash.net Sat May 26 11:20:20 2007 From: kaber at trash.net (Patrick McHardy) Date: Sat May 26 12:23:58 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <4656342A.5040202@snapgear.com> References: <465528CB.4020108@snapgear.com> <200705250044.l4P0i3f8007580@toshiba.co.jp> <4656342A.5040202@snapgear.com> Message-ID: <4657FBD4.80506@trash.net> Philip Craig wrote: > Yasuyuki KOZAKAI wrote: > >>Actually, we cannot add a new flag to 'struct ipt_ip'. It does not have >>revision field. Unfortunately it has no field such as name[] in >>'struct xt_entry_match' to steal one octet for revision. > > > If we can never add new flags, then that would be a reason for me to > not bother with clearing the internal bits before sending to userspace. We can add flags for new features, but not flags that are required to be set to behave compatible since that would break iptables userspace for old kernels. From kaber at trash.net Sat May 26 15:44:05 2007 From: kaber at trash.net (Patrick McHardy) Date: Sat May 26 16:47:17 2007 Subject: [PATCH]: ip6_tables: Fixes explanation of valid upper protocol number In-Reply-To: <200705250810.l4P8A2DL002869@toshiba.co.jp> References: <200705250810.l4P8A2DL002869@toshiba.co.jp> Message-ID: <465839A5.7080805@trash.net> Yasuyuki KOZAKAI wrote: > This explains the allowed upper protocol numbers. IP6T_F_NOPROTO was > introduced to use 0 as Hop-by-Hop option header, not wildcard. But that > seemed to be forgotten. 0 has been used as wildcard since 2002-08-23. > > Signed-off-by: Yasuyuki Kozakai Queued for 2.6.23, thanks Yasuyuki. From yuhaitao at tsinghua.org.cn Sun May 27 03:35:13 2007 From: yuhaitao at tsinghua.org.cn (YU, Haitao) Date: Sun May 27 04:51:22 2007 Subject: bugs in ftp conntrack Message-ID: <380229713.32127@tsinghua.org.cn> In your mail: >From: Patrick McHardy >Reply-To: >To: "YU, Haitao" >Subject: Re: bugs in ftp conntrack >Date:Sat, 26 May 2007 11:03:35 +0200 > >YU, Haitao wrote: >>>From: Patrick McHardy >>> >>>There's not much we can do about this case, we already keep a history >>>of sequence numbers. As you note below that code is pretty broken >>>currently, but I have patches queued to fix it (attached to this mail). >>> >> >> >> >> I think if it's possible that we don't record the new seqence of too new packets. >> "Too new packets" means the sequence of the packet is greater than all >> seq_aft_nl[] values. We just wait until another "port", "227", etc. packet is >> parsed correctly. >> >> >> So the return value of function find_nl_seq() shoule be three: >> 1: too new, then parse pattern, only if found > 0, then update seq, else keep >> current seq_aft_nl; >> 0: match one of the remembered seq, then parse pattern, update seq when found >= >> 0; >> -1: too old(less than all remembered seq), just goto out, (not goto >> out_update_nl) > > >Would you mind sending a patch to demonstrate your idea? > > > patch for 2.4.21.1 --- linux-2.4.21.1/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-04-28 05:49:26.000000000 +0800 +++ linux-2.4.21.1-new/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-05-27 09:31:35.000000000 +0800 @@ -263,10 +263,19 @@ static int find_nl_seq(u32 seq, const struct ip_ct_ftp_master *info, int dir) { unsigned int i; + int old=0, new=0; - for (i = 0; i < info->seq_aft_nl_num[dir]; i++) + for (i = 0; i < info->seq_aft_nl_num[dir]; i++){ if (info->seq_aft_nl[dir][i] == seq) - return 1; + return 0; + else if(before(seq, info->seq_aft_nl[dir][i])) + old++; + else + new++; + } + if( i == 0 ) return 0; + if( old == info->seq_aft_nl_num[dir] ) return -1; + if( new == info->seq_aft_nl_num[dir] ) return 1; return 0; } @@ -281,15 +290,17 @@ if (info->seq_aft_nl[dir][i] == nl_seq) return; - if (oldest == info->seq_aft_nl_num[dir] - || before(info->seq_aft_nl[dir][i], oldest)) + if (oldest == info->seq_aft_nl_num[dir] || + before(info->seq_aft_nl[dir][i], + info->seq_aft_nl[dir][oldest])) oldest = i; } if (info->seq_aft_nl_num[dir] < NUM_SEQ_TO_REMEMBER) { info->seq_aft_nl[dir][info->seq_aft_nl_num[dir]++] = nl_seq; ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); - } else if (oldest != NUM_SEQ_TO_REMEMBER) { + } else if (oldest != NUM_SEQ_TO_REMEMBER && + after(nl_seq, info->seq_aft_nl[dir][oldest])) { info->seq_aft_nl[dir][oldest] = nl_seq; ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); } @@ -309,7 +320,8 @@ struct ip_ct_ftp_master *ct_ftp_info = &ct->help.ct_ftp_info; struct ip_conntrack_expect *exp; unsigned int i; - int found = 0, ends_in_nl; + int found = 0, ends_in_nl, seq_type; + __u32 parse_ip; typeof(ip_nat_ftp_hook) ip_nat_ftp; /* Until there's been traffic both ways, don't look in packets. */ @@ -341,13 +353,14 @@ seq = ntohl(th->seq) + datalen; /* Look up to see if we're just after a \n. */ - if (!find_nl_seq(ntohl(th->seq), ct_ftp_info, dir)) { + seq_type = find_nl_seq(ntohl(th->seq), ct_ftp_info, dir); + if(seq_type < 0) { /* Now if this ends in \n, update ftp info. */ DEBUGP("ip_conntrack_ftp_help: wrong seq pos %s(%u) or %s(%u)\n", ct_ftp_info->seq_aft_nl[0][dir] old_seq_aft_nl_set ? "":"(UNSET) ", old_seq_aft_nl); ret = NF_ACCEPT; - goto out_update_nl; + goto out; } /* Initialize IP array to expected address (it's not mentioned @@ -399,8 +412,9 @@ * Doesn't matter unless NAT is happening. */ exp->tuple.dst.ip = ct->tuplehash[!dir].tuple.dst.ip; - if (htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3]) - != ct->tuplehash[dir].tuple.src.ip) { + parse_ip=htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3]); + if(parse_ip != ct->tuplehash[dir].tuple.src.ip + && parse_ip != ct->tuplehash[!dir].tuple.dst.ip) { /* Enrico Scholz's passive FTP to partially RNAT'd ftp server: it really wants us to connect to a different IP address. Simply don't record it for @@ -415,6 +429,7 @@ networks, or the packet filter itself). */ if (!loose) { ret = NF_ACCEPT; + found=0; goto out_put_expect; } exp->tuple.dst.ip = htonl((array[0] << 24) | (array[1] << 16) @@ -437,7 +452,7 @@ ip_nat_ftp = rcu_dereference(ip_nat_ftp_hook); if (ip_nat_ftp) ret = ip_nat_ftp(pskb, ctinfo, search[dir][i].ftptype, - matchoff, matchlen, exp, &seq); + matchoff, matchlen, exp); else { /* Can't expect this? Best to drop packet now. */ if (ip_conntrack_expect_related(exp) != 0) @@ -452,7 +467,7 @@ out_update_nl: /* Now if this ends in \n, update ftp info. Seq may have been * adjusted by NAT code. */ - if (ends_in_nl) + if (ends_in_nl && (found > 0 || seq_type == 0)) update_nl_seq(seq, ct_ftp_info,dir, *pskb); out: spin_unlock_bh(&ip_ftp_lock); From yuhaitao at tsinghua.org.cn Mon May 28 05:04:30 2007 From: yuhaitao at tsinghua.org.cn (YU, Haitao) Date: Mon May 28 06:21:05 2007 Subject: bugs in ftp conntrack Message-ID: <380321470.06341@tsinghua.org.cn> In your mail: >From: Patrick McHardy >Reply-To: >To: "YU, Haitao" >Subject: Re: bugs in ftp conntrack >Date:Sat, 26 May 2007 11:03:35 +0200 > >> I think if it's possible that we don't record the new seqence of too new packets. >> "Too new packets" means the sequence of the packet is greater than all >> seq_aft_nl[] values. We just wait until another "port", "227", etc. packet is >> parsed correctly. >> >> >> So the return value of function find_nl_seq() shoule be three: >> 1: too new, then parse pattern, only if found > 0, then update seq, else keep >> current seq_aft_nl; >> 0: match one of the remembered seq, then parse pattern, update seq when found >= >> 0; >> -1: too old(less than all remembered seq), just goto out, (not goto >> out_update_nl) > > >Would you mind sending a patch to demonstrate your idea? > > > Sorry , make a mistake. It is for 2.6, not 2.4. patch for 2.6.21.1 --- linux-2.6.21.1/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-04-28 05:49:26.000000000 +0800 +++ linux-2.6.21.1-new/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-05-27 09:31:35.000000000 +0800 @@ -263,10 +263,19 @@ static int find_nl_seq(u32 seq, const struct ip_ct_ftp_master *info, int dir) { unsigned int i; + int old=0, new=0; - for (i = 0; i < info->seq_aft_nl_num[dir]; i++) + for (i = 0; i < info->seq_aft_nl_num[dir]; i++){ if (info->seq_aft_nl[dir][i] == seq) - return 1; + return 0; + else if(before(seq, info->seq_aft_nl[dir][i])) + old++; + else + new++; + } + if( i == 0 ) return 0; + if( old == info->seq_aft_nl_num[dir] ) return -1; + if( new == info->seq_aft_nl_num[dir] ) return 1; return 0; } @@ -281,15 +290,17 @@ if (info->seq_aft_nl[dir][i] == nl_seq) return; - if (oldest == info->seq_aft_nl_num[dir] - || before(info->seq_aft_nl[dir][i], oldest)) + if (oldest == info->seq_aft_nl_num[dir] || + before(info->seq_aft_nl[dir][i], + info->seq_aft_nl[dir][oldest])) oldest = i; } if (info->seq_aft_nl_num[dir] < NUM_SEQ_TO_REMEMBER) { info->seq_aft_nl[dir][info->seq_aft_nl_num[dir]++] = nl_seq; ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); - } else if (oldest != NUM_SEQ_TO_REMEMBER) { + } else if (oldest != NUM_SEQ_TO_REMEMBER && + after(nl_seq, info->seq_aft_nl[dir][oldest])) { info->seq_aft_nl[dir][oldest] = nl_seq; ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); } @@ -309,7 +320,8 @@ struct ip_ct_ftp_master *ct_ftp_info = &ct->help.ct_ftp_info; struct ip_conntrack_expect *exp; unsigned int i; - int found = 0, ends_in_nl; + int found = 0, ends_in_nl, seq_type; + __u32 parse_ip; typeof(ip_nat_ftp_hook) ip_nat_ftp; /* Until there's been traffic both ways, don't look in packets. */ @@ -341,13 +353,14 @@ seq = ntohl(th->seq) + datalen; /* Look up to see if we're just after a \n. */ - if (!find_nl_seq(ntohl(th->seq), ct_ftp_info, dir)) { + seq_type = find_nl_seq(ntohl(th->seq), ct_ftp_info, dir); + if(seq_type < 0) { /* Now if this ends in \n, update ftp info. */ DEBUGP("ip_conntrack_ftp_help: wrong seq pos %s(%u) or %s(%u)\n", ct_ftp_info->seq_aft_nl[0][dir] old_seq_aft_nl_set ? "":"(UNSET) ", old_seq_aft_nl); ret = NF_ACCEPT; - goto out_update_nl; + goto out; } /* Initialize IP array to expected address (it's not mentioned @@ -399,8 +412,9 @@ * Doesn't matter unless NAT is happening. */ exp->tuple.dst.ip = ct->tuplehash[!dir].tuple.dst.ip; - if (htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3]) - != ct->tuplehash[dir].tuple.src.ip) { + parse_ip=htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3]); + if(parse_ip != ct->tuplehash[dir].tuple.src.ip + && parse_ip != ct->tuplehash[!dir].tuple.dst.ip) { /* Enrico Scholz's passive FTP to partially RNAT'd ftp server: it really wants us to connect to a different IP address. Simply don't record it for @@ -415,6 +429,7 @@ networks, or the packet filter itself). */ if (!loose) { ret = NF_ACCEPT; + found=0; goto out_put_expect; } exp->tuple.dst.ip = htonl((array[0] << 24) | (array[1] << 16) @@ -437,7 +452,7 @@ ip_nat_ftp = rcu_dereference(ip_nat_ftp_hook); if (ip_nat_ftp) ret = ip_nat_ftp(pskb, ctinfo, search[dir][i].ftptype, - matchoff, matchlen, exp, &seq); + matchoff, matchlen, exp); else { /* Can't expect this? Best to drop packet now. */ if (ip_conntrack_expect_related(exp) != 0) @@ -452,7 +467,7 @@ out_update_nl: /* Now if this ends in \n, update ftp info. Seq may have been * adjusted by NAT code. */ - if (ends_in_nl) + if (ends_in_nl && (found > 0 || seq_type == 0)) update_nl_seq(seq, ct_ftp_info,dir, *pskb); out: spin_unlock_bh(&ip_ftp_lock); From andang76 at gmail.com Mon May 28 11:02:20 2007 From: andang76 at gmail.com (Andrea) Date: Mon May 28 12:05:19 2007 Subject: problems applying ipset patch In-Reply-To: <1180149879.304.16.camel@henriknordstrom.net> References: <4653F176.4040604@gmail.com> <1179908784.18674.39.camel@henriknordstrom.net> <4654006D.9050704@gmail.com> <1179910939.18674.46.camel@henriknordstrom.net> <4654051E.8060508@gmail.com> <1179914093.18674.65.camel@henriknordstrom.net> <46543EDD.8040009@gmail.com> <46555D5C.7030406@gmail.com> <4655668B.6000401@gmail.com> <1180002776.17774.18.camel@henriknordstrom.net> <46556CBE.9000408@gmail.com> <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> <4657147E.7040602@gmail.com> <1180149879.304.16.camel@henriknordstrom.net> Message-ID: <465A9A9C.2030304@gmail.com> Henrik Nordstrom ha scritto: > fre 2007-05-25 klockan 18:53 +0200 skrev Andrea: > >> is there a method to resolve this mess? I could try to remove old >> version of iptables with "yum remove iptables", but this command also >> removes dependency of Shorewall, wich I would preserve. > > Specify the full path to the correct binary. You most likely have the > yum installed one in /sbin, and the manually installed one > in /usr/local/sbin/ I've unistalled the original iptables, then I've tried to manually pass rules: - iptables -A FORWARD -i eth1 -j ACCEPT ---- ok - iptables -A FORWARD -o eth1 -j ACCEPT ---- ok but - iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ===> iptables v1.3.7: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. At this point I think the problem is in some missing settings in the kernel conf From max at rfc2324.org Mon May 28 14:48:11 2007 From: max at rfc2324.org (Maximilian Wilhelm) Date: Mon May 28 15:51:12 2007 Subject: problems applying ipset patch In-Reply-To: <465A9A9C.2030304@gmail.com> References: <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> <4657147E.7040602@gmail.com> <1180149879.304.16.camel@henriknordstrom.net> <465A9A9C.2030304@gmail.com> Message-ID: <20070528124811.GA22826@outback.rfc2324.org> Am Monday, den 28 May hub Andrea folgendes in die Tasten: [...] > - iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ===> > iptables v1.3.7: can't initialize iptables table `nat': Table does not > exist (do you need to insmod?) > Perhaps iptables or your kernel needs to be upgraded. > At this point I think the problem is in some missing settings in the > kernel conf I guess, that you do not have the 'CONFIG_NF_NAT' option activated? So your kernel will also lack the 'CONFIG_IP_NF_TARGET_MASQUERADE' option. If you use the "old" layer 3 depended conntrack, you need 'CONFIG_IP_NF_NAT' instead of 'CONFIG_NF_NAT'. You can check this looking in "menuconfig" at: Networking -> Networking options -> Network packet filtering framework (Netfilter) -> Core Netfilter Configuration -> Netfilter connection tracking support HTH Ciao Max -- Follow the white penguin. From andang76 at gmail.com Mon May 28 18:29:31 2007 From: andang76 at gmail.com (Andrea) Date: Mon May 28 19:32:31 2007 Subject: problems applying ipset patch In-Reply-To: <20070528124811.GA22826@outback.rfc2324.org> References: <46559618.8040708@gmail.com> <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> <4657147E.7040602@gmail.com> <1180149879.304.16.camel@henriknordstrom.net> <465A9A9C.2030304@gmail.com> <20070528124811.GA22826@outback.rfc2324.org> Message-ID: <465B036B.4080405@gmail.com> Maximilian Wilhelm ha scritto: > Am Monday, den 28 May hub Andrea folgendes in die Tasten: > > [...] >> - iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ===> > >> iptables v1.3.7: can't initialize iptables table `nat': Table does not >> exist (do you need to insmod?) >> Perhaps iptables or your kernel needs to be upgraded. > >> At this point I think the problem is in some missing settings in the >> kernel conf > > I guess, that you do not have the 'CONFIG_NF_NAT' option activated? > So your kernel will also lack the 'CONFIG_IP_NF_TARGET_MASQUERADE' > option. > > If you use the "old" layer 3 depended conntrack, you need > 'CONFIG_IP_NF_NAT' instead of 'CONFIG_NF_NAT'. In the old .config there's CONFIG_IP_NF_NAT=m, instead in the new .config there aren't neither CONFIG_IP_NF_NAT nor CONFIG_NF_NAT. I thought that the "make oldconfig" had imported the full old kernel configuration. So, I have do add this option and recompile again (argh!); and how can I be sure that the oldconfig has not missed other entries again? From henrik at henriknordstrom.net Mon May 28 21:53:11 2007 From: henrik at henriknordstrom.net (Henrik Nordstrom) Date: Mon May 28 22:56:21 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <4657FBD4.80506@trash.net> References: <465528CB.4020108@snapgear.com> <200705250044.l4P0i3f8007580@toshiba.co.jp> <4656342A.5040202@snapgear.com> <4657FBD4.80506@trash.net> Message-ID: <1180381991.6505.46.camel@henriknordstrom.net> l?r 2007-05-26 klockan 11:20 +0200 skrev Patrick McHardy: > We can add flags for new features, but not flags that are required to > be set to behave compatible since that would break iptables userspace > for old kernels. But the proposed change is completely transparent to userspace... the use of the new flags is purely kernel-only and not visible to userspace.. The drawback is that it reduces the possible new flags which might be added by two bits, or if put another way reduces the flags field from 8 to 6 bits, leaving only 3 unused flag bits for future flag type expansions. But I am a little curious.. how much difference would it yield if simply the loop was instead changed to terminate on string end instead of always iterating over the max interface name length.. for (i = 0, ret = 0; ((const unsigned long *)ipinfo->outiface_mask)[i] && i < IFNAMSIZ/sizeof(unsigned long); i++) { ... } instead of for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { ... } plus a small change to the userspace to zero the mask after the first \0 in the interface name on exact matches. The userspace only allow exact or prefix matching, so it should be ok to restrict the compare function to this I think.. Regards Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel Url : /pipermail/netfilter-devel/attachments/20070528/439675fa/attachment.pgp From max at rfc2324.org Mon May 28 22:03:54 2007 From: max at rfc2324.org (Maximilian Wilhelm) Date: Mon May 28 23:06:49 2007 Subject: problems applying ipset patch In-Reply-To: <465B036B.4080405@gmail.com> References: <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> <4657147E.7040602@gmail.com> <1180149879.304.16.camel@henriknordstrom.net> <465A9A9C.2030304@gmail.com> <20070528124811.GA22826@outback.rfc2324.org> <465B036B.4080405@gmail.com> Message-ID: <20070528200354.GA8360@outback.rfc2324.org> Am Monday, den 28 May hub Andrea folgendes in die Tasten: Hi! > In the old .config there's CONFIG_IP_NF_NAT=m, instead in the new > .config there aren't neither CONFIG_IP_NF_NAT nor CONFIG_NF_NAT. I > thought that the "make oldconfig" had imported the full old kernel > configuration. > So, I have do add this option and recompile again (argh!); and how can I > be sure that the oldconfig has not missed other entries again? 'make oldconfig' should ask you about new items. In the past there were some Kconfig items added and renamed, so you should be carefull if 'make oldconfig' asks you about things. Ciao Max -- Follow the white penguin. From philipc at snapgear.com Tue May 29 02:24:32 2007 From: philipc at snapgear.com (Philip Craig) Date: Tue May 29 03:28:43 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <1180381991.6505.46.camel@henriknordstrom.net> References: <465528CB.4020108@snapgear.com> <200705250044.l4P0i3f8007580@toshiba.co.jp> <4656342A.5040202@snapgear.com> <4657FBD4.80506@trash.net> <1180381991.6505.46.camel@henriknordstrom.net> Message-ID: <465B72C0.5000907@snapgear.com> Henrik Nordstrom wrote: > But I am a little curious.. how much difference would it yield if simply > the loop was instead changed to terminate on string end instead of > always iterating over the max interface name length.. > > for (i = 0, ret = 0; ((const unsigned long *)ipinfo->outiface_mask)[i] && i < IFNAMSIZ/sizeof(unsigned long); i++) { > ... > } > > instead of > > for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { > ... > } > > plus a small change to the userspace to zero the mask after the first \0 > in the interface name on exact matches. > > The userspace only allow exact or prefix matching, so it should be ok to > restrict the compare function to this I think.. I'll try that, but that will also prevent loop unrolling if you're using -funroll-loops. Not sure if any builds use this, but the comment in the code implies some do. From kaber at trash.net Tue May 29 11:54:07 2007 From: kaber at trash.net (Patrick McHardy) Date: Tue May 29 12:57:55 2007 Subject: [RFC][PATCH] optimise iptables interface matching In-Reply-To: <1180381991.6505.46.camel@henriknordstrom.net> References: <465528CB.4020108@snapgear.com> <200705250044.l4P0i3f8007580@toshiba.co.jp> <4656342A.5040202@snapgear.com> <4657FBD4.80506@trash.net> <1180381991.6505.46.camel@henriknordstrom.net> Message-ID: <465BF83F.2050702@trash.net> Henrik Nordstrom wrote: > l?r 2007-05-26 klockan 11:20 +0200 skrev Patrick McHardy: > > >>We can add flags for new features, but not flags that are required to >>be set to behave compatible since that would break iptables userspace >>for old kernels. > > > But the proposed change is completely transparent to userspace... the > use of the new flags is purely kernel-only and not visible to > userspace.. Yes, certainly, that statement was not specific to this patch. > The drawback is that it reduces the possible new flags which might be > added by two bits, or if put another way reduces the flags field from 8 > to 6 bits, leaving only 3 unused flag bits for future flag type > expansions. > > > But I am a little curious.. how much difference would it yield if simply > the loop was instead changed to terminate on string end instead of > always iterating over the max interface name length.. > > for (i = 0, ret = 0; ((const unsigned long *)ipinfo->outiface_mask)[i] && i < IFNAMSIZ/sizeof(unsigned long); i++) { > ... > } > > instead of > > for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) { > ... > } > > plus a small change to the userspace to zero the mask after the first \0 > in the interface name on exact matches. It already does that I think. This sounds like a good alternative, I'd be interested to see how much improvement it yields. From xiaosuo at mail.nankai.edu.cn Mon May 28 16:31:38 2007 From: xiaosuo at mail.nankai.edu.cn (=?gb2312?B?uN+y/cD7?=) Date: Tue May 29 12:59:07 2007 Subject: [PATCH] ip_conntrack_ftp: enhancement Message-ID: <380362698.00579@mail.nankai.edu.cn> [NETFILTER]: nf_conntrack_ftp: Enhance the support to ftp and security. Includes: 1. Command terminated with LF instead of CRLF. 2. More spaces exists between command and arguments. 3. Multi-commands in one packets. Explains: to 1: Though rfc959 doesn't think LF is valid terminator, there are many ftp servers and clients support it. In fact, it is a real standard. As it isn't very difficult to implement it. So I did it. to 2: It is in rfc959. "The command codes and the argument fields are separated by one or more spaces."(section 5.3) to 3: You can't prevent the transfer layer or a user to do that. Beside of these, I also make a stricter police: all the packets which don't recognized properly aren't allow to pass the firewall. I assume that the ftp command packets should be started after a new line and they are must terminated by LF or CRLF. If not, they are considered to be invalid, and will be dropped silently. I think it is better than passing them, because of a relative security hole mentioned in phrack63-0x13[http://www.phreakmail.com/phrack63-19.html]. Perhaps you will worry about the packets dropped. It is not a real problem: 1. A normal programmer won't send a command by calling send/sendto/write more than once. 2. The dropped data will be sent again by transfer layer TCP. 3. The data after the packets dropped won't pass the firewall until the packets dropped former passed at last. So SACK option of TCP isn't a problem too. ---- Signed-off-by: xiaosuo ---- ip_conntrack_ftp.c | 94 +++++++++++++++++++++++++++++------------------------ 1 file changed, 52 insertions(+), 42 deletions(-) ---- --- linux/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-05-28 21:59:22.000000000 +0800 +++ linux-new/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-05-28 22:03:40.000000000 +0800 @@ -105,9 +105,9 @@ else if (*data == sep) i++; else { - /* Unexpected character; true if it's the - terminator and we're finished. */ - if (*data == term && i == array_size - 1) + /* Unexpected character; true if it's the terminator or '\n' + * and we're finished. */ + if ((*data == term || *data == '\n') && i == array_size - 1) return len; DEBUGP("Char %u (got %u nums) `%u' unexpected\n", @@ -205,16 +205,9 @@ size_t i; DEBUGP("find_pattern `%s': dlen = %u\n", pattern, dlen); - if (dlen == 0) + if (dlen == 0 || dlen <= plen) return 0; - if (dlen <= plen) { - /* Short packet: try for partial? */ - if (strnicmp(data, pattern, dlen) == 0) - return -1; - else return 0; - } - if (strnicmp(data, pattern, plen) != 0) { #if 0 size_t i; @@ -235,8 +228,10 @@ for (i = plen; data[i] != skip; i++) if (i == dlen - 1) return -1; - /* Skip over the last character */ - i++; + /* rfc959: The command codes and the argument fields are + * separated by one or more spaces.*/ + for (; data[i] == skip; i ++) + if (i == dlen - 1) return -1; DEBUGP("Skipped up to `%c'!\n", skip); @@ -291,15 +286,15 @@ { unsigned int dataoff, datalen; struct tcphdr _tcph, *th; - char *fb_ptr; + char *fb_ptr, *ptr; int ret; u32 seq, array[6] = { 0 }; int dir = CTINFO2DIR(ctinfo); unsigned int matchlen, matchoff; struct ip_ct_ftp_master *ct_ftp_info = &ct->help.ct_ftp_info; struct ip_conntrack_expect *exp; - unsigned int i; - int found = 0, ends_in_nl; + unsigned int i, i_old; + int found = 0, found_old = 0; /* Until there's been traffic both ways, don't look in packets. */ if (ctinfo != IP_CT_ESTABLISHED @@ -326,18 +321,20 @@ (*pskb)->len - dataoff, ftp_buffer); BUG_ON(fb_ptr == NULL); - ends_in_nl = (fb_ptr[datalen - 1] == '\n'); - seq = ntohl(th->seq) + datalen; - - /* Look up to see if we're just after a \n. */ - if (!find_nl_seq(ntohl(th->seq), ct_ftp_info, dir)) { - /* Now if this ends in \n, update ftp info. */ - DEBUGP("ip_conntrack_ftp_help: wrong seq pos %s(%u) or %s(%u)\n", - ct_ftp_info->seq_aft_nl[0][dir] - old_seq_aft_nl_set ? "":"(UNSET) ", old_seq_aft_nl); - ret = NF_ACCEPT; - goto out_update_nl; + /* We don't allow such a command or reply splitted into + * multi-packages. */ + if (fb_ptr[datalen - 1] != '\n') { + ret = NF_DROP; + goto out; + } + seq = ntohl(th->seq); + if (ct_ftp_info->seq_aft_nl_num[dir] == 0) { + update_nl_seq(seq, ct_ftp_info, dir, *pskb); + } else if (!find_nl_seq(seq, ct_ftp_info, dir)) { + ret = NF_DROP; + goto out; } + seq += datalen; /* Initialize IP array to expected address (it's not mentioned in EPSV responses) */ @@ -346,10 +343,11 @@ array[2] = (ntohl(ct->tuplehash[dir].tuple.src.ip) >> 8) & 0xFF; array[3] = ntohl(ct->tuplehash[dir].tuple.src.ip) & 0xFF; +again: for (i = 0; i < ARRAY_SIZE(search); i++) { if (search[i].dir != dir) continue; - found = find_pattern(fb_ptr, (*pskb)->len - dataoff, + found = find_pattern(fb_ptr, datalen, search[i].pattern, search[i].plen, search[i].skip, @@ -360,19 +358,32 @@ if (found) break; } if (found == -1) { - /* We don't usually drop packets. After all, this is - connection tracking, not packet filtering. - However, it is necessary for accurate tracking in - this case. */ - if (net_ratelimit()) - printk("conntrack_ftp: partial %s %u+%u\n", - search[i].pattern, - ntohl(th->seq), datalen); + /* In order to prevent a kind of attrack based + * on non-tracked sub-connection[phrack63_0x13]. + * We will drop it instead of accepting it. */ ret = NF_DROP; goto out; - } else if (found == 0) { /* No match */ - ret = NF_ACCEPT; - goto out_update_nl; + } + + /* Is there another line nested? */ + ptr = memchr(fb_ptr, '\n', datalen); + if (ptr != NULL && ptr != &fb_ptr[datalen - 1]) { + datalen -= ++ptr - fb_ptr; + fb_ptr = ptr; + if (found) { + found_old = found; + i_old = i; + } + goto again; + } + + if (found == 0) { + if (found_old == 0) { /* No match */ + ret = NF_ACCEPT; + goto out_update_nl; + } + found = found_old; + i = i_old; } DEBUGP("conntrack_ftp: match `%s' (%u bytes at %u)\n", @@ -442,9 +453,8 @@ out_update_nl: /* Now if this ends in \n, update ftp info. Seq may have been * adjusted by NAT code. */ - if (ends_in_nl) - update_nl_seq(seq, ct_ftp_info,dir, *pskb); - out: + update_nl_seq(seq, ct_ftp_info, dir, *pskb); +out: spin_unlock_bh(&ip_ftp_lock); return ret; } -------------- next part -------------- A non-text attachment was scrubbed... Name: ip_conntrack_ftp-enhanced.patch Type: application/octet-stream Size: 4745 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20070528/363feb26/ip_conntrack_ftp-enhanced-0001.obj From xiaosuo at mail.nankai.edu.cn Mon May 28 16:48:45 2007 From: xiaosuo at mail.nankai.edu.cn (=?gb2312?B?uN+y/cD7?=) Date: Tue May 29 12:59:11 2007 Subject: [PATCH] ip_conntrack_ftp: improve performance of update_nl_seq Message-ID: <380363725.06966@mail.nankai.edu.cn> [NETFILTER]: nf_conntrack_ftp: Improve the performance of update_nl_seq by using temporary variables and changing the sequence of program. ---- Signed-off-by: xiaosuo ---- ip_conntrack_ftp.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) ---- --- linux/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-05-28 21:59:22.000000000 +0800 +++ linux-new/net/ipv4/netfilter/ip_conntrack_ftp.c 2007-05-28 22:36:07.000000000 +0800 @@ -264,25 +264,28 @@ static void update_nl_seq(u32 nl_seq, struct ip_ct_ftp_master *info, int dir, struct sk_buff *skb) { - unsigned int i, oldest = NUM_SEQ_TO_REMEMBER; + unsigned int i, oldest; + u_int32_t *seq_aft_nl = info->seq_aft_nl[dir]; + int seq_aft_nl_num = info->seq_aft_nl_num[dir]; - /* Look for oldest: if we find exact match, we're done. */ - for (i = 0; i < info->seq_aft_nl_num[dir]; i++) { - if (info->seq_aft_nl[dir][i] == nl_seq) - return; + if (seq_aft_nl_num < NUM_SEQ_TO_REMEMBER) { + seq_aft_nl[info->seq_aft_nl_num[dir]++] = nl_seq; + ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); + return; + } - if (oldest == info->seq_aft_nl_num[dir] - || before(info->seq_aft_nl[dir][i], oldest)) + for (oldest = 0, i = 1; i < seq_aft_nl_num; i ++) { + if (seq_aft_nl[oldest] == nl_seq) + return; + if (before(seq_aft_nl[i], seq_aft_nl[oldest])) oldest = i; } - if (info->seq_aft_nl_num[dir] < NUM_SEQ_TO_REMEMBER) { - info->seq_aft_nl[dir][info->seq_aft_nl_num[dir]++] = nl_seq; - ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); - } else if (oldest != NUM_SEQ_TO_REMEMBER) { - info->seq_aft_nl[dir][oldest] = nl_seq; - ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); - } + if (nl_seq == seq_aft_nl[oldest] || before(nl_seq, seq_aft_nl[oldest])) + return; + + seq_aft_nl[oldest] = nl_seq; + ip_conntrack_event_cache(IPCT_HELPINFO_VOLATILE, skb); } static int help(struct sk_buff **pskb, -------------- next part -------------- A non-text attachment was scrubbed... Name: ip_conntrack_ftp-tuning.patch Type: application/octet-stream Size: 1640 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20070528/bd655ef8/ip_conntrack_ftp-tuning.obj From andang76 at gmail.com Wed May 30 10:28:11 2007 From: andang76 at gmail.com (Andrea) Date: Wed May 30 12:27:35 2007 Subject: problems applying ipset patch In-Reply-To: <20070528200354.GA8360@outback.rfc2324.org> References: <4655997E.7010407@gmail.com> <4655AEB6.5060004@gmail.com> <4655B3A8.10809@gmail.com> <4657147E.7040602@gmail.com> <1180149879.304.16.camel@henriknordstrom.net> <465A9A9C.2030304@gmail.com> <20070528124811.GA22826@outback.rfc2324.org> <465B036B.4080405@gmail.com> <20070528200354.GA8360@outback.rfc2324.org> Message-ID: <465D359B.7010300@gmail.com> > 'make oldconfig' should ask you about new items. > In the past there were some Kconfig items added and renamed, so you > should be carefull if 'make oldconfig' asks you about things. This is my old .config netfilter setting section (kernel 2.6.9.42.10) # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set ---------------------- this is my new .config section: # # IP: Netfilter Configuration # CONFIG_NF_CONNTRACK_I