From horms at verge.net.au Sun Oct 1 04:42:01 2006 From: horms at verge.net.au (Horms) Date: Sun Oct 1 05:39:20 2006 Subject: [patch 3/3] Replace reverse_route() with a call to ip_route_m e_harder() In-Reply-To: <451E99EC.1050001@trash.net> References: <36282A1733C57546BE392885C0618592015CF34D@chaos.tcs.tcs-sec.com> <451E99EC.1050001@trash.net> Message-ID: <20061001024201.GB4975@verge.net.au> On Sat, Sep 30, 2006 at 06:23:08PM +0200, Patrick McHardy wrote: > Venkat Yekkirala wrote: > >>Venkat, is it correct to place a security_skb_classify_flow > >>call in ip_route_me_harder (which also handles currently > >>unlabeled protocols)? > > > > > > This isn't necessary since the xfrm_decode_session invocation > > from within ip_route_me_harder does take care of classifying > > the flow. > > Thanks, I missed the call in xfrm_decode_session because I > only looked in xfrm4_policy.c. > > Simon, I fixed up the patch slightly and applied it, thanks. Thanks, I really was a bit unsure about this patch. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ From rbscott at cadvium.net Sun Oct 1 22:09:36 2006 From: rbscott at cadvium.net (Robert Scott) Date: Sun Oct 1 22:45:57 2006 Subject: nfq_set_verdict_mark Message-ID: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> i noticed that this function doesn't automatically convert the mark into the expected network byte order. this is a minor detail, but the current behavior may confuse users. since nfq_get_nfmark automatically converts the mark into host order, i thought nfq_set_verdict_mark would also do the reverse. not really a big deal, and this will probably break most existing installations in the field, but perhaps a note in the docs to give new users a heads up. cheers, --robert From ljlane at debian.org Mon Oct 2 03:37:54 2006 From: ljlane at debian.org (Laurence J. Lane) Date: Mon Oct 2 04:14:12 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: References: Message-ID: On 9/10/06, Laurence J. Lane wrote: > details: http://bugs.debian.org/329775 > > The 329775-submitter@bugs.debian.org address reaches all > interested Debian parties. > > R?mi Denis-Courmont has submitted a patch to that adds version support > to ip6tables and updates libip6t_multiport to v1. (R?mi also posted to the > list but something appears to have gone wrong.) > > It Works for Me. I guess the list software ate the attachment. diff -Nru iptables-1.3.5.orig/extensions/libip6t_multiport.c iptables-1.3.5/extensions/libip6t_multiport.c --- iptables-1.3.5.orig/extensions/libip6t_multiport.c 2005-02-19 21:19:17.000000000 +0200 +++ iptables-1.3.5/extensions/libip6t_multiport.c 2006-08-27 13:03:36.000000000 +0300 @@ -20,6 +20,23 @@ " --dports ...\n" " match destination port(s)\n" " --ports port[,port,port]\n" +" match both source and destination port(s)\n" +" NOTE: this kernel does not support port ranges in multiport.\n", +IPTABLES_VERSION); +} + +static void +help_v1(void) +{ + printf( +"multiport v%s options:\n" +" --source-ports [!] port[,port:port,port...]\n" +" --sports ...\n" +" match source port(s)\n" +" --destination-ports [!] port[,port:port,port...]\n" +" --dports ...\n" +" match destination port(s)\n" +" --ports [!] port[,port:port,port]\n" " match both source and destination port(s)\n", IPTABLES_VERSION); } @@ -49,7 +66,7 @@ { unsigned int portnum; - if ((string_to_number(port, 0, 65535, &portnum)) != -1 || + if (string_to_number(port, 0, 65535, &portnum) != -1 || (portnum = service_to_port(port, proto)) != -1) return (u_int16_t)portnum; @@ -77,6 +94,46 @@ return i; } +static void +parse_multi_ports_v1(const char *portstring, + struct xt_multiport_v1 *multiinfo, + const char *proto) +{ + char *buffer, *cp, *next, *range; + unsigned int i; + u_int16_t m; + + buffer = strdup(portstring); + if (!buffer) exit_error(OTHER_PROBLEM, "strdup failed"); + + for (i=0; ipflags[i] = 0; + + for (cp=buffer, i=0; cp && iports[i] = parse_port(cp, proto); + if (range) { + multiinfo->pflags[i] = 1; + multiinfo->ports[++i] = parse_port(range, proto); + if (multiinfo->ports[i-1] >= multiinfo->ports[i]) + exit_error(PARAMETER_PROBLEM, + "invalid portrange specified"); + m <<= 1; + } + } + multiinfo->count = i; + if (cp) exit_error(PARAMETER_PROBLEM, "too many ports specified"); + free(buffer); +} + /* Initialize the match. */ static void init(struct ip6t_entry_match *m, unsigned int *nfcache) @@ -150,6 +207,52 @@ return 1; } +static int +parse_v1(int c, char **argv, int invert, unsigned int *flags, + const struct ip6t_entry *entry, + unsigned int *nfcache, + struct ip6t_entry_match **match) +{ + const char *proto; + struct xt_multiport_v1 *multiinfo + = (struct xt_multiport_v1 *)(*match)->data; + + switch (c) { + case '1': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_SOURCE; + break; + + case '2': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_DESTINATION; + break; + + case '3': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_EITHER; + break; + + default: + return 0; + } + + if (invert) + multiinfo->invert = 1; + + if (*flags) + exit_error(PARAMETER_PROBLEM, + "multiport can only have one option"); + *flags = 1; + return 1; +} + /* Final check; must specify something. */ static void final_check(unsigned int flags) @@ -218,6 +321,49 @@ printf(" "); } +static void +print_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match, + int numeric) +{ + const struct xt_multiport_v1 *multiinfo + = (const struct xt_multiport_v1 *)match->data; + unsigned int i; + + printf("multiport "); + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("ports "); + break; + + default: + printf("ERROR "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, numeric); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, numeric); + } + } + printf(" "); +} + /* Saves the union ip6t_matchinfo in parsable form to stdout. */ static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match) { @@ -246,6 +392,41 @@ printf(" "); } +static void save_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match) +{ + const struct xt_multiport_v1 *multiinfo + = (const struct xt_multiport_v1 *)match->data; + unsigned int i; + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("--sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("--dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("--ports "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, 1); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, 1); + } + } + printf(" "); +} + static struct ip6tables_match multiport = { .name = "multiport", .version = IPTABLES_VERSION, @@ -260,8 +441,25 @@ .extra_opts = opts, }; +static struct ip6tables_match multiport_v1 = { + .next = NULL, + .name = "multiport", + .revision = 1, + .version = IPTABLES_VERSION, + .size = IP6T_ALIGN(sizeof(struct xt_multiport_v1)), + .userspacesize = IP6T_ALIGN(sizeof(struct xt_multiport_v1)), + .help = &help_v1, + .init = &init, + .parse = &parse_v1, + .final_check = &final_check, + .print = &print_v1, + .save = &save_v1, + .extra_opts = opts +}; + void _init(void) { register_match6(&multiport); + register_match6(&multiport_v1); } diff -Nru iptables-1.3.5.orig/include/ip6tables.h iptables-1.3.5/include/ip6tables.h --- iptables-1.3.5.orig/include/ip6tables.h 2006-01-30 10:43:09.000000000 +0200 +++ iptables-1.3.5/include/ip6tables.h 2006-08-27 13:02:55.000000000 +0300 @@ -22,6 +22,9 @@ ip6t_chainlabel name; + /* Revision of match (0 by default). */ + u_int8_t revision; + const char *version; /* Size of match data. */ diff -Nru iptables-1.3.5.orig/ip6tables.c iptables-1.3.5/ip6tables.c --- iptables-1.3.5.orig/ip6tables.c 2006-01-30 10:43:12.000000000 +0200 +++ iptables-1.3.5/ip6tables.c 2006-08-27 13:13:37.000000000 +0300 @@ -193,6 +193,8 @@ const char *program_name; char *lib_dir; +int kernel_version; + /* Keeping track of external matches and targets: linked lists. */ struct ip6tables_match *ip6tables_matches = NULL; struct ip6tables_target *ip6tables_targets = NULL; @@ -1047,10 +1049,51 @@ return merge; } +static int compatible_revision(const char *name, u_int8_t revision, int opt) +{ + struct ip6t_get_revision rev; + socklen_t s = sizeof(rev); + int max_rev, sockfd; + + sockfd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); + if (sockfd < 0) { + fprintf(stderr, "Could not open socket to kernel: %s\n", + strerror(errno)); + exit(1); + } + + strcpy(rev.name, name); + rev.revision = revision; + + max_rev = getsockopt(sockfd, IPPROTO_IPV6, opt, &rev, &s); + if (max_rev < 0) { + /* Definitely don't support this? */ + if (errno == EPROTONOSUPPORT) { + close(sockfd); + return 0; + } else if (errno == ENOPROTOOPT) { + close(sockfd); + /* Assume only revision 0 support (old kernel) */ + return (revision == 0); + } else { + fprintf(stderr, "getsockopt failed strangely: %s\n", + strerror(errno)); + exit(1); + } + } + close(sockfd); + return 1; +} + +static int compatible_match_revision(const char *name, u_int8_t revision) +{ + return compatible_revision(name, revision, IP6T_SO_GET_REVISION_MATCH); +} + void register_match6(struct ip6tables_match *me) { - struct ip6tables_match **i; + struct ip6tables_match **i, *old; if (strcmp(me->version, program_version) != 0) { fprintf(stderr, "%s: match `%s' v%s (I'm v%s).\n", @@ -1058,12 +1101,36 @@ exit(1); } - if (find_match(me->name, DURING_LOAD, NULL)) { - fprintf(stderr, "%s: match `%s' already registered.\n", + /* Revision field stole a char from name. */ + if (strlen(me->name) >= IP6T_FUNCTION_MAXNAMELEN-1) { + fprintf(stderr, "%s: target `%s' has invalid name\n", program_name, me->name); exit(1); } + old = find_match(me->name, DURING_LOAD, NULL); + if (old) { + if (old->revision == me->revision) { + fprintf(stderr, + "%s: match `%s' already registered.\n", + program_name, me->name); + exit(1); + } + + /* Now we have two (or more) options, check compatibility. */ + if (compatible_match_revision(old->name, old->revision) + && old->revision > me->revision) + return; + + /* Replace if compatible. */ + if (!compatible_match_revision(me->name, me->revision)) + return; + + /* Delete old one. */ + for (i = &ip6tables_matches; *i!=old; i = &(*i)->next); + *i = old->next; + } + if (me->size != IP6T_ALIGN(me->size)) { fprintf(stderr, "%s: match `%s' has invalid size %u.\n", program_name, me->name, (unsigned int)me->size); @@ -1700,6 +1767,14 @@ *matches = NULL; } +static void set_revision(char *name, u_int8_t revision) +{ + /* Old kernel sources don't have ".revision" field, + but we stole a byte from name. */ + name[IP6T_FUNCTION_MAXNAMELEN - 2] = '\0'; + name[IP6T_FUNCTION_MAXNAMELEN - 1] = revision; +} + int do_command6(int argc, char *argv[], char **table, ip6tc_handle_t *handle) { struct ip6t_entry fw, *e = NULL; @@ -1978,6 +2053,7 @@ m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); opts = merge_options(opts, m->extra_opts, &m->option_offset); @@ -2120,6 +2196,8 @@ m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, + m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); From horms at verge.net.au Mon Oct 2 03:57:38 2006 From: horms at verge.net.au (Horms) Date: Mon Oct 2 04:40:17 2006 Subject: [patch 2/3] Honour source routing for LVS-NAT In-Reply-To: <451D21D4.10503@trash.net> References: <20060921092241.441882000@tabatha.lab.ultramonkey.org> <20060921093021.418727000@tabatha.lab.ultramonkey.org> <451D21D4.10503@trash.net> Message-ID: <20061002015737.GG2180@verge.net.au> On Fri, Sep 29, 2006 at 03:38:28PM +0200, Patrick McHardy wrote: > Horms wrote: > > For policy routing, packets originating from this machine itself may be > > routed differently to packets passing through. We want this packet to be > > routed as if it came from this machine itself. So re-compute the routing > > information using ip_route_me_harder(). > > Thanks, I've applied the first two patches. Thanks. To which tree did you apply them? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ From yasuyuki.kozakai at toshiba.co.jp Mon Oct 2 06:46:32 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Mon Oct 2 07:23:04 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: References: Message-ID: <200610020446.k924kYkj027138@toshiba.co.jp> Hello, From: "Laurence J. Lane" Date: Sun, 1 Oct 2006 21:37:54 -0400 > On 9/10/06, Laurence J. Lane wrote: > > > details: http://bugs.debian.org/329775 > > > > The 329775-submitter@bugs.debian.org address reaches all > > interested Debian parties. > > > > R?mi Denis-Courmont has submitted a patch to that adds version support > > to ip6tables and updates libip6t_multiport to v1. (R?mi also posted to the > > list but something appears to have gone wrong.) > > > > It Works for Me. > > I guess the list software ate the attachment. Great! I'll read deeply that. > +static void > +parse_multi_ports_v1(const char *portstring, > + struct xt_multiport_v1 *multiinfo, > + const char *proto) > +{ > + char *buffer, *cp, *next, *range; > + unsigned int i; > + u_int16_t m; > + > + buffer = strdup(portstring); > + if (!buffer) exit_error(OTHER_PROBLEM, "strdup failed"); > + > + for (i=0; i + multiinfo->pflags[i] = 0; > + > + for (cp=buffer, i=0; cp && i References: <1159258392.4518e118dd50f@www.domainfactory-webmail.de> Message-ID: <45210FAC.9030107@netfilter.org> Hi Maik, Sorry for the late reply, I've been overloaded with work. Maik Hentsche wrote: > Hi pablo, hello readers of the list! > I found, that nfnl_callback_register() and nfnl_callback_unregister() in > libnfnetlink do not behave as documented. Instead of returning -1 and > setting errno, they return -EINVAL without setting errno at all. Find a > patch attached, that changes this behaviour. The patch has been build > and > tested with the unofficial libnfnetlink-0.0.16-pablo-r1 only, but the > previous version 0.0.16 also has this bug and therefore, it should also > apply there. I'll add this to my tree including the appropiate credits, I'm periodically posting the patch to the list in the hope that it will be applied to mainline. -- 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 Oct 2 15:47:09 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Oct 2 16:16:44 2006 Subject: [PATCH] libnfnetlink In-Reply-To: <451D2B3B.7070604@trash.net> References: <1159531818.451d0d2a31b47@www.domainfactory-webmail.de> <451D2B3B.7070604@trash.net> Message-ID: <4521185D.8040005@netfilter.org> Patrick McHardy wrote: > Maik Hentsche wrote: >> Hello Pablo, hello readers of the list, >> I found another bug in libnfnetlink. The comment of nfnl_recv states, in >> case of success 0 is returned. In fact at success the returnvalue of >> recvfrom is returned, which is the number of received bytes >> (libnfnetlink_recv_comment.patch). The second issue is a little more >> serious. The comment states, in case of an error, errno is set when in >> fact it is not. I appended a patch for two occurences, but I since I >> don't know, in which case addrlen might be != sizeof(peer) and what >> peer.nl_pid means (and therefore why it is a problem, if it's not 0) >> two error cases without appropriate errno value still exist. > > addrlen != sizeof(peer) should never happen. I can't think of anything > better than EINVAL. nl_pid != 0 means the message originated in > userspace and some other program is trying to feed us messages. > We could handle this by just calling recvmsg again. But this is mainly > because I can't think of a proper errno code for this either :) what do you think about the following solution? > if (len < sizeof(struct nlmsgerr) > || len < sizeof(struct nlmsghdr)) errno = EBADMSG; > [...] > if (addrlen != sizeof(peer)) errno = EINVAL; > return -1; > > if (peer.nl_pid != 0) errno = ENOMSG; > return -1; > > nlh = (struct nlmsghdr *)buf; > if (nlh->nlmsg_flags & MSG_TRUNC || status > len) errno = ENOSPC; > return -1; -- 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 rdenis at simphalempin.com Mon Oct 2 16:47:42 2006 From: rdenis at simphalempin.com (=?iso-8859-1?q?R=E9mi_Denis-Courmont?=) Date: Mon Oct 2 17:24:24 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610020446.k924kYkj027138@toshiba.co.jp> References: <200610020446.k924kYkj027138@toshiba.co.jp> Message-ID: <200610021747.42658@auguste.remlab.net> Le lundi 2 octobre 2006 07:46, Yasuyuki KOZAKAI a ?crit : (...) > Please use IP6T_MULTI_PORTS so that we can compile with linux 2.4. There you go (also resynched with latest SVN), but won't it fail with xt_multiport_v1 anyway (there is no ip6t_multiport_v1 in *any* kernel version to date, AFAIK)? Index: include/ip6tables.h =================================================================== --- include/ip6tables.h (r?vision 6678) +++ include/ip6tables.h (copie de travail) @@ -33,6 +33,9 @@ ip6t_chainlabel name; + /* Revision of match (0 by default). */ + u_int8_t revision; + const char *version; /* Size of match data. */ Index: extensions/libip6t_multiport.c =================================================================== --- extensions/libip6t_multiport.c (r?vision 6678) +++ extensions/libip6t_multiport.c (copie de travail) @@ -20,6 +20,23 @@ " --dports ...\n" " match destination port(s)\n" " --ports port[,port,port]\n" +" match both source and destination port(s)\n" +" NOTE: this kernel does not support port ranges in multiport.\n", +IPTABLES_VERSION); +} + +static void +help_v1(void) +{ + printf( +"multiport v%s options:\n" +" --source-ports [!] port[,port:port,port...]\n" +" --sports ...\n" +" match source port(s)\n" +" --destination-ports [!] port[,port:port,port...]\n" +" --dports ...\n" +" match destination port(s)\n" +" --ports [!] port[,port:port,port]\n" " match both source and destination port(s)\n", IPTABLES_VERSION); } @@ -70,6 +87,46 @@ return i; } +static void +parse_multi_ports_v1(const char *portstring, + struct xt_multiport_v1 *multiinfo, + const char *proto) +{ + char *buffer, *cp, *next, *range; + unsigned int i; + u_int16_t m; + + buffer = strdup(portstring); + if (!buffer) exit_error(OTHER_PROBLEM, "strdup failed"); + + for (i=0; ipflags[i] = 0; + + for (cp=buffer, i=0; cp && iports[i] = parse_port(cp, proto); + if (range) { + multiinfo->pflags[i] = 1; + multiinfo->ports[++i] = parse_port(range, proto); + if (multiinfo->ports[i-1] >= multiinfo->ports[i]) + exit_error(PARAMETER_PROBLEM, + "invalid portrange specified"); + m <<= 1; + } + } + multiinfo->count = i; + if (cp) exit_error(PARAMETER_PROBLEM, "too many ports specified"); + free(buffer); +} + /* Initialize the match. */ static void init(struct ip6t_entry_match *m, unsigned int *nfcache) @@ -143,6 +200,52 @@ return 1; } +static int +parse_v1(int c, char **argv, int invert, unsigned int *flags, + const struct ip6t_entry *entry, + unsigned int *nfcache, + struct ip6t_entry_match **match) +{ + const char *proto; + struct xt_multiport_v1 *multiinfo + = (struct xt_multiport_v1 *)(*match)->data; + + switch (c) { + case '1': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_SOURCE; + break; + + case '2': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_DESTINATION; + break; + + case '3': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_EITHER; + break; + + default: + return 0; + } + + if (invert) + multiinfo->invert = 1; + + if (*flags) + exit_error(PARAMETER_PROBLEM, + "multiport can only have one option"); + *flags = 1; + return 1; +} + /* Final check; must specify something. */ static void final_check(unsigned int flags) @@ -210,6 +313,49 @@ printf(" "); } +static void +print_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match, + int numeric) +{ + const struct xt_multiport_v1 *multiinfo + = (const struct xt_multiport_v1 *)match->data; + unsigned int i; + + printf("multiport "); + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("ports "); + break; + + default: + printf("ERROR "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, numeric); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, numeric); + } + } + printf(" "); +} + /* Saves the union ip6t_matchinfo in parsable form to stdout. */ static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match) { @@ -238,6 +384,41 @@ printf(" "); } +static void save_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match) +{ + const struct xt_multiport_v1 *multiinfo + = (const struct xt_multiport_v1 *)match->data; + unsigned int i; + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("--sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("--dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("--ports "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, 1); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, 1); + } + } + printf(" "); +} + static struct ip6tables_match multiport = { .name = "multiport", .version = IPTABLES_VERSION, @@ -252,8 +433,25 @@ .extra_opts = opts, }; +static struct ip6tables_match multiport_v1 = { + .next = NULL, + .name = "multiport", + .revision = 1, + .version = IPTABLES_VERSION, + .size = IP6T_ALIGN(sizeof(struct xt_multiport_v1)), + .userspacesize = IP6T_ALIGN(sizeof(struct xt_multiport_v1)), + .help = &help_v1, + .init = &init, + .parse = &parse_v1, + .final_check = &final_check, + .print = &print_v1, + .save = &save_v1, + .extra_opts = opts +}; + void _init(void) { register_match6(&multiport); + register_match6(&multiport_v1); } Index: ip6tables.c =================================================================== --- ip6tables.c (r?vision 6678) +++ ip6tables.c (copie de travail) @@ -193,6 +193,8 @@ const char *program_name; char *lib_dir; +int kernel_version; + /* Keeping track of external matches and targets: linked lists. */ struct ip6tables_match *ip6tables_matches = NULL; struct ip6tables_target *ip6tables_targets = NULL; @@ -1102,10 +1104,51 @@ return merge; } +static int compatible_revision(const char *name, u_int8_t revision, int opt) +{ + struct ip6t_get_revision rev; + socklen_t s = sizeof(rev); + int max_rev, sockfd; + + sockfd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); + if (sockfd < 0) { + fprintf(stderr, "Could not open socket to kernel: %s\n", + strerror(errno)); + exit(1); + } + + strcpy(rev.name, name); + rev.revision = revision; + + max_rev = getsockopt(sockfd, IPPROTO_IPV6, opt, &rev, &s); + if (max_rev < 0) { + /* Definitely don't support this? */ + if (errno == EPROTONOSUPPORT) { + close(sockfd); + return 0; + } else if (errno == ENOPROTOOPT) { + close(sockfd); + /* Assume only revision 0 support (old kernel) */ + return (revision == 0); + } else { + fprintf(stderr, "getsockopt failed strangely: %s\n", + strerror(errno)); + exit(1); + } + } + close(sockfd); + return 1; +} + +static int compatible_match_revision(const char *name, u_int8_t revision) +{ + return compatible_revision(name, revision, IP6T_SO_GET_REVISION_MATCH); +} + void register_match6(struct ip6tables_match *me) { - struct ip6tables_match **i; + struct ip6tables_match **i, *old; if (strcmp(me->version, program_version) != 0) { fprintf(stderr, "%s: match `%s' v%s (I'm v%s).\n", @@ -1113,12 +1156,36 @@ exit(1); } - if (find_match(me->name, DURING_LOAD, NULL)) { - fprintf(stderr, "%s: match `%s' already registered.\n", + /* Revision field stole a char from name. */ + if (strlen(me->name) >= IP6T_FUNCTION_MAXNAMELEN-1) { + fprintf(stderr, "%s: target `%s' has invalid name\n", program_name, me->name); exit(1); } + old = find_match(me->name, DURING_LOAD, NULL); + if (old) { + if (old->revision == me->revision) { + fprintf(stderr, + "%s: match `%s' already registered.\n", + program_name, me->name); + exit(1); + } + + /* Now we have two (or more) options, check compatibility. */ + if (compatible_match_revision(old->name, old->revision) + && old->revision > me->revision) + return; + + /* Replace if compatible. */ + if (!compatible_match_revision(me->name, me->revision)) + return; + + /* Delete old one. */ + for (i = &ip6tables_matches; *i!=old; i = &(*i)->next); + *i = old->next; + } + if (me->size != IP6T_ALIGN(me->size)) { fprintf(stderr, "%s: match `%s' has invalid size %u.\n", program_name, me->name, (unsigned int)me->size); @@ -1761,6 +1828,14 @@ *matches = NULL; } +static void set_revision(char *name, u_int8_t revision) +{ + /* Old kernel sources don't have ".revision" field, + but we stole a byte from name. */ + name[IP6T_FUNCTION_MAXNAMELEN - 2] = '\0'; + name[IP6T_FUNCTION_MAXNAMELEN - 1] = revision; +} + int do_command6(int argc, char *argv[], char **table, ip6tc_handle_t *handle) { struct ip6t_entry fw, *e = NULL; @@ -2041,6 +2116,7 @@ m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); if (m != m->next) @@ -2185,6 +2261,8 @@ m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, + m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); -- R?mi Denis-Courmont http://www.remlab.net/ From pablo at netfilter.org Mon Oct 2 16:55:08 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Oct 2 17:24:46 2006 Subject: nfq_set_verdict_mark In-Reply-To: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> References: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> Message-ID: <4521284C.2070000@netfilter.org> Robert Scott wrote: > i noticed that this function doesn't automatically convert the mark into > the expected network byte order. this is a minor detail, but the > current behavior may confuse users. since nfq_get_nfmark automatically > converts the mark into host order, i thought nfq_set_verdict_mark would > also do the reverse. > > not really a big deal, and this will probably break most existing > installations in the field, but perhaps a note in the docs to give new > users a heads up. Yes, I agree what you, we have to document this minor issue, I think that we can introduce more API that can solve this inconsistency. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From kaber at trash.net Mon Oct 2 17:46:03 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 2 18:22:21 2006 Subject: [NETFILTER 00/05]: Small netfilter update Message-ID: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> Hi Dave, following is a small netfilter update for 2.6.19. The first three patches are fixes (Kconfig dependency fix and Horms' LVS routing fix), one patch to remove the duplicated route_me_harder code from ipt_REJECT and Bart's ebt_mark patch. I know I'm a little late, but I hope its they're still fine since they're quite small. Please apply, thanks. include/linux/netfilter_bridge/ebt_mark_t.h | 12 +++ include/linux/netfilter_ipv4.h | 2 net/bridge/netfilter/ebt_mark.c | 21 ++++-- net/ipv4/ipvs/ip_vs_core.c | 10 ++ net/ipv4/netfilter.c | 9 +- net/ipv4/netfilter/ip_nat_standalone.c | 3 net/ipv4/netfilter/ipt_REJECT.c | 97 +++++----------------------- net/ipv4/netfilter/iptable_mangle.c | 3 net/netfilter/Kconfig | 2 9 files changed, 70 insertions(+), 89 deletions(-) Bart De Schuymer: [NETFILTER]: ebt_mark: add or/and/xor action support to mark target Patrick McHardy: [NETFILTER]: Kconfig: fix xt_physdev dependencies [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function Simon Horman: [NETFILTER]: add type parameter to ip_route_me_harder [NETFILTER]: Honour source routing for LVS-NAT From kaber at trash.net Mon Oct 2 17:46:05 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 2 18:22:23 2006 Subject: [NETFILTER 01/05]: Kconfig: fix xt_physdev dependencies In-Reply-To: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> References: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> Message-ID: <20061002154717.13121.35191.sendpatchset@localhost.localdomain> [NETFILTER]: Kconfig: fix xt_physdev dependencies xt_physdev depends on bridge netfilter, which is a boolean, but can still be built modular because of special handling in the bridge makefile. Add a dependency on BRIDGE to prevent XT_MATCH_PHYSDEV=y, BRIDGE=m. Signed-off-by: Patrick McHardy --- commit 2f253e95a172eaec7de29e3f0951d3a20d3f904c tree fa38b574cf9b05743058ef38a3fa38bf28a1a399 parent 6656e3c4c8e0c80f2d2bfece574876d269f64861 author Patrick McHardy Mon, 02 Oct 2006 17:39:35 +0200 committer Patrick McHardy Mon, 02 Oct 2006 17:39:35 +0200 net/netfilter/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index 0a28d2c..ce94732 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -365,7 +365,7 @@ config NETFILTER_XT_MATCH_MULTIPORT config NETFILTER_XT_MATCH_PHYSDEV tristate '"physdev" match support' - depends on NETFILTER_XTABLES && BRIDGE_NETFILTER + depends on NETFILTER_XTABLES && BRIDGE && BRIDGE_NETFILTER help Physdev packet matching matches against the physical bridge ports the IP packet arrived on or will leave by. From kaber at trash.net Mon Oct 2 17:46:06 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 2 18:22:26 2006 Subject: [NETFILTER 02/05]: add type parameter to ip_route_me_harder In-Reply-To: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> References: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> Message-ID: <20061002154719.13121.63674.sendpatchset@localhost.localdomain> [NETFILTER]: add type parameter to ip_route_me_harder By adding a type parameter to ip_route_me_harder() the expensive call to inet_addr_type() can be avoided in some cases. A followup patch where ip_route_me_harder() is called from within ip_vs_out() is one such example. Signed-off-By: Simon Horman Signed-off-by: Patrick McHardy --- commit fa2cba7f2f3ce89d34fdb903f7d80494439e6b59 tree 06e54f9b5988869066c28fdedb438f4ce7a42702 parent 2f253e95a172eaec7de29e3f0951d3a20d3f904c author Simon Horman Mon, 02 Oct 2006 17:39:40 +0200 committer Patrick McHardy Mon, 02 Oct 2006 17:39:40 +0200 include/linux/netfilter_ipv4.h | 2 +- net/ipv4/netfilter.c | 9 ++++++--- net/ipv4/netfilter/ip_nat_standalone.c | 3 ++- net/ipv4/netfilter/iptable_mangle.c | 3 ++- 4 files changed, 11 insertions(+), 6 deletions(-) diff --git a/include/linux/netfilter_ipv4.h b/include/linux/netfilter_ipv4.h index ce02c98..5b63a23 100644 --- a/include/linux/netfilter_ipv4.h +++ b/include/linux/netfilter_ipv4.h @@ -77,7 +77,7 @@ enum nf_ip_hook_priorities { #define SO_ORIGINAL_DST 80 #ifdef __KERNEL__ -extern int ip_route_me_harder(struct sk_buff **pskb); +extern int ip_route_me_harder(struct sk_buff **pskb, unsigned addr_type); extern int ip_xfrm_me_harder(struct sk_buff **pskb); extern unsigned int nf_ip_checksum(struct sk_buff *skb, unsigned int hook, unsigned int dataoff, u_int8_t protocol); diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c index 5ac1537..e2005c6 100644 --- a/net/ipv4/netfilter.c +++ b/net/ipv4/netfilter.c @@ -8,7 +8,7 @@ #include #include /* route_me_harder function, used by iptable_nat, iptable_mangle + ip_queue */ -int ip_route_me_harder(struct sk_buff **pskb) +int ip_route_me_harder(struct sk_buff **pskb, unsigned addr_type) { struct iphdr *iph = (*pskb)->nh.iph; struct rtable *rt; @@ -16,10 +16,13 @@ int ip_route_me_harder(struct sk_buff ** struct dst_entry *odst; unsigned int hh_len; + if (addr_type == RTN_UNSPEC) + addr_type = inet_addr_type(iph->saddr); + /* some non-standard hacks like ipt_REJECT.c:send_reset() can cause * packets with foreign saddr to appear on the NF_IP_LOCAL_OUT hook. */ - if (inet_addr_type(iph->saddr) == RTN_LOCAL) { + if (addr_type == RTN_LOCAL) { fl.nl_u.ip4_u.daddr = iph->daddr; fl.nl_u.ip4_u.saddr = iph->saddr; fl.nl_u.ip4_u.tos = RT_TOS(iph->tos); @@ -156,7 +159,7 @@ static int nf_ip_reroute(struct sk_buff if (!(iph->tos == rt_info->tos && iph->daddr == rt_info->daddr && iph->saddr == rt_info->saddr)) - return ip_route_me_harder(pskb); + return ip_route_me_harder(pskb, RTN_UNSPEC); } return 0; } diff --git a/net/ipv4/netfilter/ip_nat_standalone.c b/net/ipv4/netfilter/ip_nat_standalone.c index 021395b..d85d2de 100644 --- a/net/ipv4/netfilter/ip_nat_standalone.c +++ b/net/ipv4/netfilter/ip_nat_standalone.c @@ -265,7 +265,8 @@ #ifdef CONFIG_XFRM ct->tuplehash[!dir].tuple.src.u.all #endif ) - return ip_route_me_harder(pskb) == 0 ? ret : NF_DROP; + if (ip_route_me_harder(pskb, RTN_UNSPEC)) + ret = NF_DROP; } return ret; } diff --git a/net/ipv4/netfilter/iptable_mangle.c b/net/ipv4/netfilter/iptable_mangle.c index e62ea2b..b91f358 100644 --- a/net/ipv4/netfilter/iptable_mangle.c +++ b/net/ipv4/netfilter/iptable_mangle.c @@ -157,7 +157,8 @@ #ifdef CONFIG_IP_ROUTE_FWMARK || (*pskb)->nfmark != nfmark #endif || (*pskb)->nh.iph->tos != tos)) - return ip_route_me_harder(pskb) == 0 ? ret : NF_DROP; + if (ip_route_me_harder(pskb, RTN_UNSPEC)) + ret = NF_DROP; return ret; } From kaber at trash.net Mon Oct 2 17:46:07 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 2 18:22:27 2006 Subject: [NETFILTER 03/05]: Honour source routing for LVS-NAT In-Reply-To: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> References: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> Message-ID: <20061002154720.13121.79607.sendpatchset@localhost.localdomain> [NETFILTER]: Honour source routing for LVS-NAT For policy routing, packets originating from this machine itself may be routed differently to packets passing through. We want this packet to be routed as if it came from this machine itself. So re-compute the routing information using ip_route_me_harder(). This patch is derived from work by Ken Brownfield Cc: Ken Brownfield Signed-off-by: Simon Horman Signed-off-by: Patrick McHardy --- commit 1bc8aeeaf12d73774421e408d7f6461a20cebc5e tree 273fb8d8604554aecf263bef82a43f781a019333 parent fa2cba7f2f3ce89d34fdb903f7d80494439e6b59 author Simon Horman Mon, 02 Oct 2006 17:39:45 +0200 committer Patrick McHardy Mon, 02 Oct 2006 17:39:45 +0200 net/ipv4/ipvs/ip_vs_core.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/net/ipv4/ipvs/ip_vs_core.c b/net/ipv4/ipvs/ip_vs_core.c index 6dee039..1445bb4 100644 --- a/net/ipv4/ipvs/ip_vs_core.c +++ b/net/ipv4/ipvs/ip_vs_core.c @@ -813,6 +813,16 @@ ip_vs_out(unsigned int hooknum, struct s skb->nh.iph->saddr = cp->vaddr; ip_send_check(skb->nh.iph); + /* For policy routing, packets originating from this + * machine itself may be routed differently to packets + * passing through. We want this packet to be routed as + * if it came from this machine itself. So re-compute + * the routing information. + */ + if (ip_route_me_harder(pskb, RTN_LOCAL) != 0) + goto drop; + skb = *pskb; + IP_VS_DBG_PKT(10, pp, skb, 0, "After SNAT"); ip_vs_out_stats(cp, skb); From kaber at trash.net Mon Oct 2 17:46:08 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 2 18:22:28 2006 Subject: [NETFILTER 04/05]: ipt_REJECT: remove largely duplicate route_reverse function In-Reply-To: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> References: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> Message-ID: <20061002154721.13121.67962.sendpatchset@localhost.localdomain> [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function Use ip_route_me_harder instead, which now allows to specify how we wish the packet to be routed. Based on patch by Simon Horman . Signed-off-by: Patrick McHardy --- commit 606add40816396611545a6239c1029a473448d9f tree 6a1e6e137c44132154b94a60ae10733f174f4ec2 parent 1bc8aeeaf12d73774421e408d7f6461a20cebc5e author Patrick McHardy Mon, 02 Oct 2006 17:39:49 +0200 committer Patrick McHardy Mon, 02 Oct 2006 17:39:49 +0200 net/ipv4/netfilter/ipt_REJECT.c | 97 ++++++++------------------------------- 1 files changed, 19 insertions(+), 78 deletions(-) diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c index fd0c05e..ad0312d 100644 --- a/net/ipv4/netfilter/ipt_REJECT.c +++ b/net/ipv4/netfilter/ipt_REJECT.c @@ -38,76 +38,16 @@ #else #define DEBUGP(format, args...) #endif -static inline struct rtable *route_reverse(struct sk_buff *skb, - struct tcphdr *tcph, int hook) -{ - struct iphdr *iph = skb->nh.iph; - struct dst_entry *odst; - struct flowi fl = {}; - struct rtable *rt; - - /* We don't require ip forwarding to be enabled to be able to - * send a RST reply for bridged traffic. */ - if (hook != NF_IP_FORWARD -#ifdef CONFIG_BRIDGE_NETFILTER - || (skb->nf_bridge && skb->nf_bridge->mask & BRNF_BRIDGED) -#endif - ) { - fl.nl_u.ip4_u.daddr = iph->saddr; - if (hook == NF_IP_LOCAL_IN) - fl.nl_u.ip4_u.saddr = iph->daddr; - fl.nl_u.ip4_u.tos = RT_TOS(iph->tos); - - if (ip_route_output_key(&rt, &fl) != 0) - return NULL; - } else { - /* non-local src, find valid iif to satisfy - * rp-filter when calling ip_route_input. */ - fl.nl_u.ip4_u.daddr = iph->daddr; - if (ip_route_output_key(&rt, &fl) != 0) - return NULL; - - odst = skb->dst; - if (ip_route_input(skb, iph->saddr, iph->daddr, - RT_TOS(iph->tos), rt->u.dst.dev) != 0) { - dst_release(&rt->u.dst); - return NULL; - } - dst_release(&rt->u.dst); - rt = (struct rtable *)skb->dst; - skb->dst = odst; - - fl.nl_u.ip4_u.daddr = iph->saddr; - fl.nl_u.ip4_u.saddr = iph->daddr; - fl.nl_u.ip4_u.tos = RT_TOS(iph->tos); - } - - if (rt->u.dst.error) { - dst_release(&rt->u.dst); - return NULL; - } - - fl.proto = IPPROTO_TCP; - fl.fl_ip_sport = tcph->dest; - fl.fl_ip_dport = tcph->source; - security_skb_classify_flow(skb, &fl); - - xfrm_lookup((struct dst_entry **)&rt, &fl, NULL, 0); - - return rt; -} - /* Send RST reply */ static void send_reset(struct sk_buff *oldskb, int hook) { struct sk_buff *nskb; struct iphdr *iph = oldskb->nh.iph; struct tcphdr _otcph, *oth, *tcph; - struct rtable *rt; __be16 tmp_port; __be32 tmp_addr; int needs_ack; - int hh_len; + unsigned int addr_type; /* IP header checks: fragment. */ if (oldskb->nh.iph->frag_off & htons(IP_OFFSET)) @@ -126,23 +66,13 @@ static void send_reset(struct sk_buff *o if (nf_ip_checksum(oldskb, hook, iph->ihl * 4, IPPROTO_TCP)) return; - if ((rt = route_reverse(oldskb, oth, hook)) == NULL) - return; - - hh_len = LL_RESERVED_SPACE(rt->u.dst.dev); - /* We need a linear, writeable skb. We also need to expand headroom in case hh_len of incoming interface < hh_len of outgoing interface */ - nskb = skb_copy_expand(oldskb, hh_len, skb_tailroom(oldskb), + nskb = skb_copy_expand(oldskb, LL_MAX_HEADER, skb_tailroom(oldskb), GFP_ATOMIC); - if (!nskb) { - dst_release(&rt->u.dst); + if (!nskb) return; - } - - dst_release(nskb->dst); - nskb->dst = &rt->u.dst; /* This packet will not be the same as the other: clear nf fields */ nf_reset(nskb); @@ -184,6 +114,21 @@ static void send_reset(struct sk_buff *o tcph->window = 0; tcph->urg_ptr = 0; + /* Set DF, id = 0 */ + nskb->nh.iph->frag_off = htons(IP_DF); + nskb->nh.iph->id = 0; + + addr_type = RTN_UNSPEC; + if (hook != NF_IP_FORWARD +#ifdef CONFIG_BRIDGE_NETFILTER + || (nskb->nf_bridge && nskb->nf_bridge->mask & BRNF_BRIDGED) +#endif + ) + addr_type = RTN_LOCAL; + + if (ip_route_me_harder(&nskb, addr_type)) + goto free_nskb; + /* Adjust TCP checksum */ nskb->ip_summed = CHECKSUM_NONE; tcph->check = 0; @@ -192,12 +137,8 @@ static void send_reset(struct sk_buff *o nskb->nh.iph->daddr, csum_partial((char *)tcph, sizeof(struct tcphdr), 0)); - - /* Adjust IP TTL, DF */ + /* Adjust IP TTL */ nskb->nh.iph->ttl = dst_metric(nskb->dst, RTAX_HOPLIMIT); - /* Set DF, id = 0 */ - nskb->nh.iph->frag_off = htons(IP_DF); - nskb->nh.iph->id = 0; /* Adjust IP checksum */ nskb->nh.iph->check = 0; From kaber at trash.net Mon Oct 2 17:46:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 2 18:22:30 2006 Subject: [NETFILTER 05/05]: ebt_mark: add or/and/xor action support to mark target In-Reply-To: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> References: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> Message-ID: <20061002154723.13121.55358.sendpatchset@localhost.localdomain> [NETFILTER]: ebt_mark: add or/and/xor action support to mark target The following patch adds or/and/xor functionality for the mark target, while staying backwards compatible. Signed-off-by: Bart De Schuymer Signed-off-by: Patrick McHardy --- commit 9a2c1735d4cf9c120d67d9bf82bb4455804f2041 tree 9049c23fafecd717254cbe066c1f9e310e5227a8 parent 606add40816396611545a6239c1029a473448d9f author Bart De Schuymer Mon, 02 Oct 2006 17:39:55 +0200 committer Patrick McHardy Mon, 02 Oct 2006 17:39:55 +0200 include/linux/netfilter_bridge/ebt_mark_t.h | 12 ++++++++++++ net/bridge/netfilter/ebt_mark.c | 21 +++++++++++++++++---- 2 files changed, 29 insertions(+), 4 deletions(-) diff --git a/include/linux/netfilter_bridge/ebt_mark_t.h b/include/linux/netfilter_bridge/ebt_mark_t.h index 110fec6..6270f6f 100644 --- a/include/linux/netfilter_bridge/ebt_mark_t.h +++ b/include/linux/netfilter_bridge/ebt_mark_t.h @@ -1,6 +1,18 @@ #ifndef __LINUX_BRIDGE_EBT_MARK_T_H #define __LINUX_BRIDGE_EBT_MARK_T_H +/* The target member is reused for adding new actions, the + * value of the real target is -1 to -NUM_STANDARD_TARGETS. + * For backward compatibility, the 4 lsb (2 would be enough, + * but let's play it safe) are kept to designate this target. + * The remaining bits designate the action. By making the set + * action 0xfffffff0, the result will look ok for older + * versions. [September 2006] */ +#define MARK_SET_VALUE (0xfffffff0) +#define MARK_OR_VALUE (0xffffffe0) +#define MARK_AND_VALUE (0xffffffd0) +#define MARK_XOR_VALUE (0xffffffc0) + struct ebt_mark_t_info { unsigned long mark; diff --git a/net/bridge/netfilter/ebt_mark.c b/net/bridge/netfilter/ebt_mark.c index 770c0df..b54306a 100644 --- a/net/bridge/netfilter/ebt_mark.c +++ b/net/bridge/netfilter/ebt_mark.c @@ -22,24 +22,37 @@ static int ebt_target_mark(struct sk_buf const void *data, unsigned int datalen) { struct ebt_mark_t_info *info = (struct ebt_mark_t_info *)data; + int action = info->target & -16; - if ((*pskb)->nfmark != info->mark) + if (action == MARK_SET_VALUE) (*pskb)->nfmark = info->mark; + else if (action == MARK_OR_VALUE) + (*pskb)->nfmark |= info->mark; + else if (action == MARK_AND_VALUE) + (*pskb)->nfmark &= info->mark; + else + (*pskb)->nfmark ^= info->mark; - return info->target; + return info->target | -16; } static int ebt_target_mark_check(const char *tablename, unsigned int hookmask, const struct ebt_entry *e, void *data, unsigned int datalen) { struct ebt_mark_t_info *info = (struct ebt_mark_t_info *)data; + int tmp; if (datalen != EBT_ALIGN(sizeof(struct ebt_mark_t_info))) return -EINVAL; - if (BASE_CHAIN && info->target == EBT_RETURN) + tmp = info->target | -16; + if (BASE_CHAIN && tmp == EBT_RETURN) return -EINVAL; CLEAR_BASE_CHAIN_BIT; - if (INVALID_TARGET) + if (tmp < -NUM_STANDARD_TARGETS || tmp >= 0) + return -EINVAL; + tmp = info->target & -16; + if (tmp != MARK_SET_VALUE && tmp != MARK_OR_VALUE && + tmp != MARK_AND_VALUE && tmp != MARK_XOR_VALUE) return -EINVAL; return 0; } From davem at davemloft.net Tue Oct 3 01:13:44 2006 From: davem at davemloft.net (David Miller) Date: Tue Oct 3 01:50:04 2006 Subject: [NETFILTER 00/05]: Small netfilter update In-Reply-To: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> References: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> Message-ID: <20061002.161344.92582699.davem@davemloft.net> From: Patrick McHardy Date: Mon, 2 Oct 2006 17:46:03 +0200 (MEST) > following is a small netfilter update for 2.6.19. The first three patches > are fixes (Kconfig dependency fix and Horms' LVS routing fix), one patch > to remove the duplicated route_me_harder code from ipt_REJECT and Bart's > ebt_mark patch. I know I'm a little late, but I hope its they're still > fine since they're quite small. > > Please apply, thanks. Applied. Please submit the bug fixes as you see fit to -stable, in particular I'd like to see the Kconfig dependency fix go to 2.6.18-stable. You can use this signoff line for any of those patches when submitting to -stable, thanks: Signed-off-by: David S. Miller From yasuyuki.kozakai at toshiba.co.jp Tue Oct 3 16:30:18 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Tue Oct 3 17:07:05 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610021747.42658@auguste.remlab.net> References: <200610020446.k924kYkj027138@toshiba.co.jp> <200610021747.42658@auguste.remlab.net> Message-ID: <200610031430.k93EUJUB026806@toshiba.co.jp> From: R?mi Denis-Courmont Date: Mon, 2 Oct 2006 17:47:42 +0300 > Le lundi 2 octobre 2006 07:46, Yasuyuki KOZAKAI a ?crit : > (...) > > Please use IP6T_MULTI_PORTS so that we can compile with linux 2.4. > > There you go (also resynched with latest SVN), but won't it fail with > xt_multiport_v1 anyway (there is no ip6t_multiport_v1 in *any* kernel > version to date, AFAIK)? But they have multiport v0 features. The revision was introduced to keep compatibility with such features in old kernel and make possible to add new features to new kernel. IPv4 multiport match (and policy match, too) would help you. It has the line #include ../../include/netfilter_ipv4/ipt_multiport.h and definitions for old kernel are included in the header. -- Yasuyuki Kozakai From rdenis at simphalempin.com Tue Oct 3 21:58:28 2006 From: rdenis at simphalempin.com (=?iso-8859-1?q?R=E9mi_Denis-Courmont?=) Date: Tue Oct 3 22:35:40 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610031430.k93EUJgA008197@toshiba.co.jp> References: <200610021747.42658@auguste.remlab.net> <200610031430.k93EUJgA008197@toshiba.co.jp> Message-ID: <200610032258.30338@auguste.remlab.net> Le mardi 3 octobre 2006 17:30, vous avez ?crit : > IPv4 multiport match (and policy match, too) would help you. It has > the line > > #include ../../include/netfilter_ipv4/ipt_multiport.h > > and definitions for old kernel are included in the header. Ok. This time there is no trace of (xt|XT)_ at all: diff -Nru iptables-1.3.5.orig/extensions/libip6t_multiport.c iptables-1.3.5/extensions/libip6t_multiport.c --- iptables-1.3.5.orig/extensions/libip6t_multiport.c 2005-02-19 21:19:17.000000000 +0200 +++ iptables-1.3.5/extensions/libip6t_multiport.c 2006-08-27 13:03:36.000000000 +0300 @@ -20,6 +20,23 @@ " --dports ...\n" " match destination port(s)\n" " --ports port[,port,port]\n" +" match both source and destination port(s)\n" +" NOTE: this kernel does not support port ranges in multiport.\n", +IPTABLES_VERSION); +} + +static void +help_v1(void) +{ + printf( +"multiport v%s options:\n" +" --source-ports [!] port[,port:port,port...]\n" +" --sports ...\n" +" match source port(s)\n" +" --destination-ports [!] port[,port:port,port...]\n" +" --dports ...\n" +" match destination port(s)\n" +" --ports [!] port[,port:port,port]\n" " match both source and destination port(s)\n", IPTABLES_VERSION); } @@ -49,7 +66,7 @@ { unsigned int portnum; - if ((string_to_number(port, 0, 65535, &portnum)) != -1 || + if (string_to_number(port, 0, 65535, &portnum) != -1 || (portnum = service_to_port(port, proto)) != -1) return (u_int16_t)portnum; @@ -77,6 +94,46 @@ return i; } +static void +parse_multi_ports_v1(const char *portstring, + struct xt_multiport_v1 *multiinfo, + const char *proto) +{ + char *buffer, *cp, *next, *range; + unsigned int i; + u_int16_t m; + + buffer = strdup(portstring); + if (!buffer) exit_error(OTHER_PROBLEM, "strdup failed"); + + for (i=0; ipflags[i] = 0; + + for (cp=buffer, i=0; cp && iports[i] = parse_port(cp, proto); + if (range) { + multiinfo->pflags[i] = 1; + multiinfo->ports[++i] = parse_port(range, proto); + if (multiinfo->ports[i-1] >= multiinfo->ports[i]) + exit_error(PARAMETER_PROBLEM, + "invalid portrange specified"); + m <<= 1; + } + } + multiinfo->count = i; + if (cp) exit_error(PARAMETER_PROBLEM, "too many ports specified"); + free(buffer); +} + /* Initialize the match. */ static void init(struct ip6t_entry_match *m, unsigned int *nfcache) @@ -150,6 +207,52 @@ return 1; } +static int +parse_v1(int c, char **argv, int invert, unsigned int *flags, + const struct ip6t_entry *entry, + unsigned int *nfcache, + struct ip6t_entry_match **match) +{ + const char *proto; + struct xt_multiport_v1 *multiinfo + = (struct xt_multiport_v1 *)(*match)->data; + + switch (c) { + case '1': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_SOURCE; + break; + + case '2': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_DESTINATION; + break; + + case '3': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_EITHER; + break; + + default: + return 0; + } + + if (invert) + multiinfo->invert = 1; + + if (*flags) + exit_error(PARAMETER_PROBLEM, + "multiport can only have one option"); + *flags = 1; + return 1; +} + /* Final check; must specify something. */ static void final_check(unsigned int flags) @@ -218,6 +321,49 @@ printf(" "); } +static void +print_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match, + int numeric) +{ + const struct xt_multiport_v1 *multiinfo + = (const struct xt_multiport_v1 *)match->data; + unsigned int i; + + printf("multiport "); + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("ports "); + break; + + default: + printf("ERROR "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, numeric); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, numeric); + } + } + printf(" "); +} + /* Saves the union ip6t_matchinfo in parsable form to stdout. */ static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match) { @@ -246,6 +392,41 @@ printf(" "); } +static void save_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match) +{ + const struct xt_multiport_v1 *multiinfo + = (const struct xt_multiport_v1 *)match->data; + unsigned int i; + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("--sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("--dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("--ports "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, 1); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, 1); + } + } + printf(" "); +} + static struct ip6tables_match multiport = { .name = "multiport", .version = IPTABLES_VERSION, @@ -260,8 +441,25 @@ .extra_opts = opts, }; +static struct ip6tables_match multiport_v1 = { + .next = NULL, + .name = "multiport", + .revision = 1, + .version = IPTABLES_VERSION, + .size = IP6T_ALIGN(sizeof(struct xt_multiport_v1)), + .userspacesize = IP6T_ALIGN(sizeof(struct xt_multiport_v1)), + .help = &help_v1, + .init = &init, + .parse = &parse_v1, + .final_check = &final_check, + .print = &print_v1, + .save = &save_v1, + .extra_opts = opts +}; + void _init(void) { register_match6(&multiport); + register_match6(&multiport_v1); } diff -Nru iptables-1.3.5.orig/include/ip6tables.h iptables-1.3.5/include/ip6tables.h --- iptables-1.3.5.orig/include/ip6tables.h 2006-01-30 10:43:09.000000000 +0200 +++ iptables-1.3.5/include/ip6tables.h 2006-08-27 13:02:55.000000000 +0300 @@ -22,6 +22,9 @@ ip6t_chainlabel name; + /* Revision of match (0 by default). */ + u_int8_t revision; + const char *version; /* Size of match data. */ diff -Nru iptables-1.3.5.orig/ip6tables.c iptables-1.3.5/ip6tables.c --- iptables-1.3.5.orig/ip6tables.c 2006-01-30 10:43:12.000000000 +0200 +++ iptables-1.3.5/ip6tables.c 2006-08-27 13:13:37.000000000 +0300 @@ -193,6 +193,8 @@ const char *program_name; char *lib_dir; +int kernel_version; + /* Keeping track of external matches and targets: linked lists. */ struct ip6tables_match *ip6tables_matches = NULL; struct ip6tables_target *ip6tables_targets = NULL; @@ -1047,10 +1049,51 @@ return merge; } +static int compatible_revision(const char *name, u_int8_t revision, int opt) +{ + struct ip6t_get_revision rev; + socklen_t s = sizeof(rev); + int max_rev, sockfd; + + sockfd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); + if (sockfd < 0) { + fprintf(stderr, "Could not open socket to kernel: %s\n", + strerror(errno)); + exit(1); + } + + strcpy(rev.name, name); + rev.revision = revision; + + max_rev = getsockopt(sockfd, IPPROTO_IPV6, opt, &rev, &s); + if (max_rev < 0) { + /* Definitely don't support this? */ + if (errno == EPROTONOSUPPORT) { + close(sockfd); + return 0; + } else if (errno == ENOPROTOOPT) { + close(sockfd); + /* Assume only revision 0 support (old kernel) */ + return (revision == 0); + } else { + fprintf(stderr, "getsockopt failed strangely: %s\n", + strerror(errno)); + exit(1); + } + } + close(sockfd); + return 1; +} + +static int compatible_match_revision(const char *name, u_int8_t revision) +{ + return compatible_revision(name, revision, IP6T_SO_GET_REVISION_MATCH); +} + void register_match6(struct ip6tables_match *me) { - struct ip6tables_match **i; + struct ip6tables_match **i, *old; if (strcmp(me->version, program_version) != 0) { fprintf(stderr, "%s: match `%s' v%s (I'm v%s).\n", @@ -1058,12 +1101,36 @@ exit(1); } - if (find_match(me->name, DURING_LOAD, NULL)) { - fprintf(stderr, "%s: match `%s' already registered.\n", + /* Revision field stole a char from name. */ + if (strlen(me->name) >= IP6T_FUNCTION_MAXNAMELEN-1) { + fprintf(stderr, "%s: target `%s' has invalid name\n", program_name, me->name); exit(1); } + old = find_match(me->name, DURING_LOAD, NULL); + if (old) { + if (old->revision == me->revision) { + fprintf(stderr, + "%s: match `%s' already registered.\n", + program_name, me->name); + exit(1); + } + + /* Now we have two (or more) options, check compatibility. */ + if (compatible_match_revision(old->name, old->revision) + && old->revision > me->revision) + return; + + /* Replace if compatible. */ + if (!compatible_match_revision(me->name, me->revision)) + return; + + /* Delete old one. */ + for (i = &ip6tables_matches; *i!=old; i = &(*i)->next); + *i = old->next; + } + if (me->size != IP6T_ALIGN(me->size)) { fprintf(stderr, "%s: match `%s' has invalid size %u.\n", program_name, me->name, (unsigned int)me->size); @@ -1700,6 +1767,14 @@ *matches = NULL; } +static void set_revision(char *name, u_int8_t revision) +{ + /* Old kernel sources don't have ".revision" field, + but we stole a byte from name. */ + name[IP6T_FUNCTION_MAXNAMELEN - 2] = '\0'; + name[IP6T_FUNCTION_MAXNAMELEN - 1] = revision; +} + int do_command6(int argc, char *argv[], char **table, ip6tc_handle_t *handle) { struct ip6t_entry fw, *e = NULL; @@ -1978,6 +2053,7 @@ m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); opts = merge_options(opts, m->extra_opts, &m->option_offset); @@ -2120,6 +2196,8 @@ m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, + m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); -- R?mi Denis-Courmont http://www.remlab.net/ From alan.ezust at presinet.com Wed Oct 4 00:18:09 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Wed Oct 4 00:54:46 2006 Subject: testing installation of conntrack command line tool Message-ID: <200610031518.10097.alan.ezust@presinet.com> Hi - i'm trying out the "conntrack" program for my first time. It compiles and runs, but when I try to do conntrack -L conntrack it shows me nothing. If I cat /proc/net/ip_conntrack I can see lots of log lines there. Should the conntrack -L conntrack show me pretty much the same thing? What's the best way to test that conntrack is working properly? From glen.turner at aarnet.edu.au Wed Oct 4 09:12:28 2006 From: glen.turner at aarnet.edu.au (Glen Turner) Date: Wed Oct 4 09:49:45 2006 Subject: Patch-o-matic says "unable to find ladd slot" in Makefile Message-ID: <45235EDC.4080709@aarnet.edu.au> Hi folks, I've written a patch for the Linux kernel and for iptables which adds a TCPCONG netfilter target to set the TCP congestion control algorithm. Now I can run a different algorithm for traffic using the the WLAN interface than for traffic using the wired interface. Code at I've tried my best to follow the instructions at .../patch-o-matic-ng/README.newpatches which I think asks that a file .../patch-o-matic-ng/patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Makefile.ladd be created containing obj-$(CONFIG_IP_NF_TARGET_TCPCONG) += ipt_TCPCONG.o rather than this being left in the .../patch-o-matic-ng/patchlets/TCPCONG/linux-2.6.patch file. Unfortunately when I run patch-o-matic KERNEL_DIR=~/linux-2.6.18 \ IPTABLES_DIR=~/iptables-1.3.6 \ ./runme base I get this error > Testing TCPCONG... not applied > The TCPCONG patch: > Author: Glen Turner, > Status: Beta > This target sets the TCP congestion control algorithm. > ----------------------------------------------------------------- > Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y > unable to find ladd slot in src /home/gdt/linux-2.6.18/net/ipv4/netfilter/Makefile (./patchlets/TCPCONG/linux-2.6/./net/ipv4/netfilter/Makefile.ladd) > ----------------------------------------------------------------- Should I have left the change to net/ipv4/netfilter/Makefile in the file linux-2.6.patch? Or is some other magic required? Thanks muchly, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au From mohammadfarooq at tango-networks.com Wed Oct 4 21:26:37 2006 From: mohammadfarooq at tango-networks.com (Mohammad Farooq) Date: Wed Oct 4 22:03:13 2006 Subject: iptables won't compile in a debug turned on Message-ID: <1159989997.28977.166.camel@mfarooq-1.tango-networks.com> Are you guys aware of that is in the iptables-1.3.6/Makefile if turn on debugging: CFLAGS:=$(COPT_FLAGS) -Wall -Wunused -I$(KERNEL_DIR)/include -Iinclude/ -DIPTABLES_VERSION=\"$(IPTABLES_VERSION)\" -g -DDEBUG -pg -DIPTC_DEBUG the compile will fail. MF libiptc/libip6tc.c: In function `do_check': libiptc/libip6tc.c:284: warning: implicit declaration of function `get_chain_end' libiptc/libip6tc.c:285: warning: implicit declaration of function `get_entry' libiptc/libip6tc.c:285: error: invalid type argument of `->' libiptc/libip6tc.c:289: error: invalid type argument of `->' libiptc/libip6tc.c:308: error: invalid type argument of `->' libiptc/libip6tc.c:312: error: invalid type argument of `->' libiptc/libip6tc.c:318: error: invalid type argument of `->' libiptc/libip6tc.c:343: error: invalid type argument of `->' libiptc/libip6tc.c:349: error: invalid type argument of `->' libiptc/libip6tc.c:354: error: invalid type argument of `->' libiptc/libip6tc.c:360: error: invalid type argument of `->' libiptc/libip6tc.c:373: error: invalid type argument of `->' libiptc/libip6tc.c:384: error: invalid type argument of `->' libiptc/libip6tc.c:397: warning: assignment makes pointer from integer without a cast libiptc/libip6tc.c:410: warning: passing arg 2 of `iptcb_entry2index' makes pointer from integer without a cast libiptc/libip6tc.c:411: warning: passing arg 2 of `iptcb_entry2index' makes pointer from integer without a cast libiptc/libip6tc.c:418: error: request for member `size' in something not a structure or union libiptc/libip6tc.c:418: error: structure has no member named `new_number' libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c:422: error: request for member `name' in something not a structure or union libiptc/libip6tc.c: At top level: libiptc/libip6tc.c:135: warning: 'dump_entry' defined but not used make: *** [libiptc/libip6tc.o] Error 1 rm libiptc/libip4tc.o From pablo at netfilter.org Wed Oct 4 21:48:11 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Oct 4 22:18:01 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <200610031518.10097.alan.ezust@presinet.com> References: <200610031518.10097.alan.ezust@presinet.com> Message-ID: <45240FFB.4070606@netfilter.org> Alan Ezust wrote: > Hi - i'm trying out the "conntrack" program for my first time. > It compiles and runs, but when I try to do > > conntrack -L conntrack > > it shows me nothing. > > If I cat /proc/net/ip_conntrack I can see lots of log lines there. Should the > conntrack -L conntrack show me pretty much the same thing? > > What's the best way to test that conntrack is working properly? Please check that ip_conntrack_netlink is loaded, old kernel do not load it on demand. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From pablo at netfilter.org Wed Oct 4 21:54:51 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Oct 4 22:24:36 2006 Subject: Patch-o-matic says "unable to find ladd slot" in Makefile In-Reply-To: <45235EDC.4080709@aarnet.edu.au> References: <45235EDC.4080709@aarnet.edu.au> Message-ID: <4524118B.4020903@netfilter.org> Glen Turner wrote: > > Hi folks, > > I've written a patch for the Linux kernel and for iptables > which adds a TCPCONG netfilter target to set the TCP congestion > control algorithm. Now I can run a different algorithm for > traffic using the the WLAN interface than for traffic using > the wired interface. Code at > > > I've tried my best to follow the instructions at > .../patch-o-matic-ng/README.newpatches > which I think asks that a file > > .../patch-o-matic-ng/patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Makefile.ladd > > be created containing > obj-$(CONFIG_IP_NF_TARGET_TCPCONG) += ipt_TCPCONG.o You have to add some context to let pom know where you want to place that line, for example: :~/SVN/trunk/patch-o-matic-ng/patchlets/XOR/linux-2.6/net/ipv4/netfilter$ cat Makefile.ladd obj-$(CONFIG_IP_NF_TARGET_LOG) += ipt_LOG.o obj-$(CONFIG_IP_NF_TARGET_XOR) += ipt_XOR.o This tells that the ipt_XOR must be after the ipt_LOG line. -- 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 alan.ezust at presinet.com Wed Oct 4 22:33:18 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Wed Oct 4 23:10:14 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <45240FFB.4070606@netfilter.org> References: <200610031518.10097.alan.ezust@presinet.com> <45240FFB.4070606@netfilter.org> Message-ID: <200610041333.19451.alan.ezust@presinet.com> On Wednesday 04 October 2006 12:48, Pablo Neira Ayuso wrote: > Alan Ezust wrote: > > Hi - i'm trying out the "conntrack" program for my first time. > > It compiles and runs, but when I try to do > > > > conntrack -L conntrack > > > > it shows me nothing. > > > > If I cat /proc/net/ip_conntrack I can see lots of log lines there. Should > > the conntrack -L conntrack show me pretty much the same thing? > > > > What's the best way to test that conntrack is working properly? > > Please check that ip_conntrack_netlink is loaded, old kernel do not load > it on demand. I'm using kernel 2.6.16.29. These kernel options are set: CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_IP_NF_CONNTRACK_NETLINK=y Are you saying I should also add a CONFIG_IP_CONNTRACK_NETLINK flag in the .config or something else? From pablo at netfilter.org Thu Oct 5 00:04:44 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu Oct 5 00:34:32 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <200610041333.19451.alan.ezust@presinet.com> References: <200610031518.10097.alan.ezust@presinet.com> <45240FFB.4070606@netfilter.org> <200610041333.19451.alan.ezust@presinet.com> Message-ID: <45242FFC.4010500@netfilter.org> Alan Ezust wrote: > On Wednesday 04 October 2006 12:48, Pablo Neira Ayuso wrote: >> Alan Ezust wrote: >>> Hi - i'm trying out the "conntrack" program for my first time. >>> It compiles and runs, but when I try to do >>> >>> conntrack -L conntrack >>> >>> it shows me nothing. >>> >>> If I cat /proc/net/ip_conntrack I can see lots of log lines there. Should >>> the conntrack -L conntrack show me pretty much the same thing? >>> >>> What's the best way to test that conntrack is working properly? >> Please check that ip_conntrack_netlink is loaded, old kernel do not load >> it on demand. > I'm using kernel 2.6.16.29. > > These kernel options are set: > > CONFIG_NETFILTER_NETLINK=y > CONFIG_NETFILTER_NETLINK_QUEUE=y > CONFIG_NETFILTER_NETLINK_LOG=y > CONFIG_IP_NF_CONNTRACK_NETLINK=y > > Are you saying I should also add a > CONFIG_IP_CONNTRACK_NETLINK flag in the .config or something else? No, people usually compile ip_conntrack_netlink as module, and I wanted to make sure that the module was loaded (modprobe ip_conntrack_netlink) but since you compiled it built-in. Could you tell me what version of conntrack/libnetfilter_conntrac are you using? -- 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 alan.ezust at presinet.com Thu Oct 5 00:31:16 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Thu Oct 5 01:08:10 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <45242FFC.4010500@netfilter.org> References: <200610031518.10097.alan.ezust@presinet.com> <200610041333.19451.alan.ezust@presinet.com> <45242FFC.4010500@netfilter.org> Message-ID: <200610041531.17209.alan.ezust@presinet.com> On Wednesday 04 October 2006 15:04, Pablo Neira Ayuso wrote: > Alan Ezust wrote: > > On Wednesday 04 October 2006 12:48, Pablo Neira Ayuso wrote: > >> Alan Ezust wrote: > >>> Hi - i'm trying out the "conntrack" program for my first time. > >>> It compiles and runs, but when I try to do > >>> > >>> conntrack -L conntrack > >>> > >>> it shows me nothing. > >>> > >>> If I cat /proc/net/ip_conntrack I can see lots of log lines there. > >>> Should the conntrack -L conntrack show me pretty much the same thing? > >>> > >>> What's the best way to test that conntrack is working properly? > >> > >> Please check that ip_conntrack_netlink is loaded, old kernel do not load > >> it on demand. > > > > I'm using kernel 2.6.16.29. > > > > These kernel options are set: > > > > CONFIG_NETFILTER_NETLINK=y > > CONFIG_NETFILTER_NETLINK_QUEUE=y > > CONFIG_NETFILTER_NETLINK_LOG=y > > CONFIG_IP_NF_CONNTRACK_NETLINK=y > > > > Are you saying I should also add a > > CONFIG_IP_CONNTRACK_NETLINK flag in the .config or something else? > > No, people usually compile ip_conntrack_netlink as module, and I wanted > to make sure that the module was loaded (modprobe ip_conntrack_netlink) > but since you compiled it built-in. What's the difference between IP_NF_CONNTRACK_NETLINK and IP_CONNTRACK_NETLINK? Are they different modules or is one the new name for the other? > Could you tell me what version of conntrack/libnetfilter_conntrac are > you using? conntrack 1.00beta2 libnetfilter_conntrack-0.0.31/ libnfnetlink-0.0.16/ From retesh.chadha at gmail.com Thu Oct 5 09:06:48 2006 From: retesh.chadha at gmail.com (Retesh Chadha) Date: Thu Oct 5 09:43:24 2006 Subject: Can i have a rate limit per source IP Address in IPSet? Message-ID: I have following questions regarding iptables - 1. Say I have 2 Ips in one IPset, and a rate limiting rule as follows - ipset -N KNOWN iphash ipset -A KNOWN 192.168.1.89 ipset -A KNOWN 192.168.3.114 iptables -A INPUT_CHAIN -m set --set KNOWN src -m limit --limit 100/second --limit-burst 5 -j ACCEPT I have observed that the rate limit is the cumulative limit, and not per IP. Is it possible to have a limit of say 100pps from each IP in KNOWN IPSET. 2. Is there a limit on the number of IPs in an ipset ? 3. I have observed that the limit rate in a rule can be as much as 10000packets/per/second. If say I am using an ipset with 1000 elements and the rate limit 10000 pps (which is a limitation and also cumulative), then effectively per IP limit becomes 10pps which cause the problem. Any clue how to solve this. Thanks & Regards Retesh Chadha From retesh.chadha at gmail.com Thu Oct 5 09:11:16 2006 From: retesh.chadha at gmail.com (Retesh Chadha) Date: Thu Oct 5 09:47:51 2006 Subject: Parsing ULOG message received on netlink socket In-Reply-To: <1159538859.451d28ac01159@www.domainfactory-webmail.de> References: <451D225B.6030908@trash.net> <1159538859.451d28ac01159@www.domainfactory-webmail.de> Message-ID: Hi I am able to parse the ULOG message (raw buffer) by skipping the netlink header and a few more bytes(fixed size around - 160 bytes) to get the IP header. This works for me for UDP, ICMP and TCP. Rgds Retesh On 9/29/06, Maik Hentsche wrote: > Zitat von Patrick McHardy : > > > Check out ulogd or nfnetlink_log and libnfnetlink. > > ulogd seems to be abandoned, so specter > (http://joker.linuxstuff.pl/specter/) might be the better advice. Both > specter and ulogd already have plugins for parsing the raw data. Having > written an output plugin (to log into prelude) for both I feel this is > easier for specter because of the better defined structure of the > passed values. If Retesh ever feels, his (or her? can't tell from the > name, sorry) work should become open source, the chance to get a new > plugin into specter seems to be far better then getting one into ulogd > since the author of the former does answer mails and the author of the > later does not. > > Just my 2 ?. > > so long > Maik > > From deti at fliegl.de Thu Oct 5 09:51:04 2006 From: deti at fliegl.de (Deti Fliegl) Date: Thu Oct 5 10:27:50 2006 Subject: Can i have a rate limit per source IP Address in IPSet? In-Reply-To: References: Message-ID: <4524B968.303@fliegl.de> Hi, better use match 'hashlimit' for your purpose. Example: iptables --append FORWARD --match hashlimit --hashlimit 1/s --hashlimit-mode srcip --jump ACCEPT This would limit the number of requests from an specific IP address to 1 per second. Regards, Deti From glen.turner at aarnet.edu.au Thu Oct 5 10:00:50 2006 From: glen.turner at aarnet.edu.au (Glen Turner) Date: Thu Oct 5 10:38:22 2006 Subject: [PATCH] Add TCPCONG target to patch-o-matic In-Reply-To: <4524118B.4020903@netfilter.org> References: <45235EDC.4080709@aarnet.edu.au> <4524118B.4020903@netfilter.org> Message-ID: <4524BBB2.2000109@aarnet.edu.au> Hi folks, I have created a kernel module and iptables shared library to allow netfilter to set the TCP congestion control algorithm. This has three major uses: selecting differing algorithms for wired and non-wired interfaces; selecting differing algorithms for close and far hosts; and selecting differing algorithms for comparison testing. Thanks to the hint from Pablo Neira Ayuso I have put this into the patch-o-matic format. This has been tested against iptables-1.3.6 and linux-2.6.18. A SVN diff against patch-o-matic follows, which I'm hoping Thunderbird doesn't mangle. Since I'm not familiar with SVN please let me know if this isn't the desired patch format. I would hope that this facility can become a standard part of the kernel and iptables. Please let me know what I need to do to follow that path. Thanks, Glen Index: patchlets/TCPCONG/linux-2.6.patch =================================================================== --- patchlets/TCPCONG/linux-2.6.patch (revision 0) +++ patchlets/TCPCONG/linux-2.6.patch (revision 0) @@ -0,0 +1,10 @@ +--- linux-2.6.18/net/ipv4/tcp_cong.c 2006-09-20 13:12:06.000000000 +0930 ++++ linux-2.6.18-new/net/ipv4/tcp_cong.c 2006-10-04 15:10:59.000000000 +0930 +@@ -172,6 +172,7 @@ + rcu_read_unlock(); + return err; + } ++EXPORT_SYMBOL_GPL(tcp_set_congestion_control); + + + /* Index: patchlets/TCPCONG/linux-2.6/include/linux/netfilter_ipv4/ipt_TCPCONG.h =================================================================== --- patchlets/TCPCONG/linux-2.6/include/linux/netfilter_ipv4/ipt_TCPCONG.h (revision 0) +++ patchlets/TCPCONG/linux-2.6/include/linux/netfilter_ipv4/ipt_TCPCONG.h (revision 0) @@ -0,0 +1,25 @@ +/* iptables module for setting the TCP congestion control algorithm. + * + * For information see net/ipv4/netfilter/ipt_TCPCONG.c. + * + * Copyright ? Glen David Turner of Semaphore, South Australia, 2006. + * + * + * 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. + */ + +#ifndef _IPT_TCPCONG_TARGET_H +#define _IPT_TCPCONG_TARGET_H + +/* Value from tcp.h, but this header needs to work for both kernel and user compile. */ +#define TCP_CA_NAME_MAX 16 + +/* Target attributes */ +struct ipt_TCPCONG { + char algorithm_name[TCP_CA_NAME_MAX]; +}; + +#endif /* _IPT_TCPCONG_TARGET_H */ Property changes on: patchlets/TCPCONG/linux-2.6/include/linux/netfilter_ipv4/ipt_TCPCONG.h ___________________________________________________________________ Name: svn:keywords + Id Name: svn:eol-style + native Index: patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Makefile.ladd =================================================================== --- patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Makefile.ladd (revision 0) +++ patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Makefile.ladd (revision 0) @@ -0,0 +1,2 @@ +obj-$(CONFIG_IP_NF_TARGET_LOG) += ipt_LOG.o +obj-$(CONFIG_IP_NF_TARGET_TCPCONG) += ipt_TCPCONG.o Index: patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Kconfig.ladd =================================================================== --- patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Kconfig.ladd (revision 0) +++ patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/Kconfig.ladd (revision 0) @@ -0,0 +1,13 @@ +config IP_NF_TARGET_TCPCONG + tristate "TCP congeston control algorithm target support" + depends on TCP_CONG_ADVANCED + ---help--- + This option adds a TCPCONG target. This allows the TCP + congestion control algorithm to be selected from Netfilter. + + The TCPCONG target requires the kernel compilation option + TCP_CONG_ADVANCED, which can be found at Networking | + Networking support | Networking options | TCP/IP networking | + TCP: advanced congestion control. + + To compile it as a module, choose M here. If unsure, say N. Index: patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/ipt_TCPCONG.c =================================================================== --- patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/ipt_TCPCONG.c (revision 0) +++ patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/ipt_TCPCONG.c (revision 0) @@ -0,0 +1,125 @@ +/* iptables module for setting the TCP congestion control algorithm. + * + * Copyright ? Glen David Turner of Semaphore, South Australia, 2006. + * + * + * 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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + */ + +#include +#include +#include /* For TCP_*, tcp_setsockopt(). */ +#include /* For SOL_TCP */ + +#include +#include + +MODULE_DESCRIPTION("iptables TCPCONG target sets TCP congestion control algorithm"); +MODULE_AUTHOR("Glen Turner, http://www.aarnet.edu.au/~gdt/"); +MODULE_LICENSE("GPL"); + +static unsigned int +target(struct sk_buff **pskb, + const struct net_device *in, + const struct net_device *out, + unsigned int hooknum, + const struct xt_target *target, + const void *targinfo, + void *userinfo) +{ + int error; + const struct ipt_TCPCONG *tcpcong = targinfo; + struct sock *sk = (*pskb)->sk; + + if (sk) { + /* Netfilter has already locked sk. */ + error = tcp_set_congestion_control(sk, + tcpcong->algorithm_name); + if (error) { + if (error == -2) { + printk(KERN_INFO + "TCPCONG: Cannot find TCP congestion " + "control algorithm \'%s\". (Perhaps " + "\"modprobe tcp_%s\" was forgotten.) " + "Continuing with previous algorithm." + "\n", + tcpcong->algorithm_name, + tcpcong->algorithm_name); + } else { + printk(KERN_INFO + "TCPCONG: Failed with error %d " + "setting TCP congestion control " + "algorithm \"%s\"; continuing with " + "previous algorithm.\n", + error, + tcpcong->algorithm_name); + } + } + } else { + printk(KERN_INFO + "TCPCONG: No socket yet for this packet; continuing " + "with previous TCP congestion control algorithm\n"); + } + + return IPT_CONTINUE; +} + +static int +checkentry(const char *tablename, + const void *entry_void, + const struct xt_target *target, + void *targinfo, + unsigned int targinfosize, + unsigned int hook_mask) +{ + const struct ipt_entry *entry = entry_void; + + if (entry->ip.proto != IPPROTO_TCP) { + printk(KERN_INFO + "TCPCONG: Need a match of \"--protocol tcp\" before " + "the target \"--tcpcong-algorithm\" can be used to set " + "a TCP congestion control algorithm.\n"); + return 0; + } + return 1; +} + +/* Module registration. */ +static struct ipt_target target_registration = { + .name = "TCPCONG", + .target = target, + .targetsize = sizeof(struct ipt_TCPCONG), + .table = "filter", + .checkentry = checkentry, + .me = THIS_MODULE, +}; + +static int __init ipt_tcpcong_init(void) +{ + return ipt_register_target(&target_registration); +} + +/* Unregistering a target leaves the TCP congestion control algorithm in place + * for opened connections. Not sure if this is a bug, since it might actually + * be desirable. + */ +static void __exit ipt_tcpcong_fini(void) +{ + ipt_unregister_target(&target_registration); +} + +module_init(ipt_tcpcong_init); +module_exit(ipt_tcpcong_fini); Property changes on: patchlets/TCPCONG/linux-2.6/net/ipv4/netfilter/ipt_TCPCONG.c ___________________________________________________________________ Name: svn:keywords + Id Name: svn:eol-style + native Index: patchlets/TCPCONG/iptables/extensions/libipt_TCPCONG.c =================================================================== --- patchlets/TCPCONG/iptables/extensions/libipt_TCPCONG.c (revision 0) +++ patchlets/TCPCONG/iptables/extensions/libipt_TCPCONG.c (revision 0) @@ -0,0 +1,279 @@ +/* libipt_TCPCONG.c -- set the TCP congestion control algorithm. + * + * $Id$ + * + * Differing TCP congestion control algorithms are better than others + * in particular circumstances. Westwood TCP is designed for 802.11 + * wireless LANs with their lossy transmission links; Hamilton TCP, + * BIC and CUBIC are designed for fat long pipes; Vegas uses router + * queueing delay rather than packet loss as a measure of available + * bandwidth. This target lets you choose the TCP congestion control + * algorithm that best suits the task at hand without needing to + * recompile the application to call setsockopt(). + * + * Copyright ? Glen David Turner of Semaphore, South Australia, 2006. + * + * + * 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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +/* + * Help for user. + */ +static char *help_text[] = { +"TCPCONG options:", +" --tcpcong-algorithm s", +" Set the TCP congestion control algorithm for this connection to the", +" algorithm named \"s\". The effect is the same as", +" setsockopt(connection, getprotobyname(\"tcp\")->p_proto,", +" TCP_CONGESTION, \"s\");", +" The available algorithms depend upon your kernel version and its", +" configuration. Example algorithm names are: bic, reno, cubic,", +" highspeed, htcp, hybla, scalable, vegas, westwood.", +" --tcpcong-algorithm-default", +" Set the TCP congestion control algorithm to the default algorithm.", +" The default TCP congestion control algorithm is the value of the", +" kernel sysctl parameter", +" net.ipv4.tcp_congestion_control", +" If that sysctl parameter is missing then the default algorithm", +" is established by the kernel's build configuration. This option", +" is identical to --tcpcong-algorithm \"\" but a distinct option is", +" provided to avoid the complexities of shell quoting.", + + NULL /* End of list sentinel. */ +}; + +static void +help(void) +{ + char **p; + for (p = help_text; *p != NULL; p++) { + puts(*p); + } +} + + +/* + * Options for this target. + * + * See "man getopt_long" for an explanation of this structure. + */ +static struct option extra_opts[] = +{ + { "tcpcong-algorithm", 1, 0, '1' }, + { "tcpcong-algorithm-default", 0, 0, '2' }, + { 0 } +}; + + +/* + * Initialise data for target. + * + * Inputs: + * target -- information for this target instance. + * nfcache -- ?? + */ +static void +init(struct ipt_entry_target *target, + unsigned int *nfcache) +{ +} + + +/* + * Parse a command. + * + * Inputs: + * option -- the 'val' from opts[] above, could possibly be something we + * cannot recognise in which case return(0). If we do recognise it + * then return(1). + * argv -- in case we want to take parameters from the command line, + * invert -- set if the option parameter had '!' in front of it. + * flags -- Starts of zero for a fresh target, gets fed into + * final_check(). Same as (*target)->tflags. + * entry -- ?? + * target -- the record that holds data about this target, most + * importantly, our private data is (*target)->data (this has already + * been malloced). + * Returns: + * 1 if option matches, 0 otherwise. + * Side effects: + * Fill in target->data with parsed options. + */ + +/* Treat 'flags' as a bit vector which indicates which options have been + * parsed. This macro assigns option numbers to bit locations. + */ +#define OPTION_PARSED(OPTION) (1 << ((OPTION)-'1')) + +static int +parse(int option, + char **argv, + int invert, + unsigned int *flags, + const struct ipt_entry *entry, + struct ipt_entry_target **target) +{ + struct ipt_TCPCONG *tcpcong = (struct ipt_TCPCONG *)(*target)->data; + + switch (option) { + case '1': + if (invert) { + exit_error(PARAMETER_PROBLEM, + "TCPCONG: \"! --tcpcong-algorithm\" not " + "supported"); + } + if (*flags & OPTION_PARSED('1')) { + exit_error(PARAMETER_PROBLEM, + "TCPCONG: Cannot have more than one " + "\"--tcpcong-algorithm\""); + } + *flags |= OPTION_PARSED('1'); + strncpy(tcpcong->algorithm_name, + optarg, + TCP_CA_NAME_MAX); + tcpcong->algorithm_name[TCP_CA_NAME_MAX-1] = '\0'; + break; + case '2': + if (invert) { + exit_error(PARAMETER_PROBLEM, + "TCPCONG: \"! " + "--tcpconf-algorithm-default\" not " + "supported"); + } + *flags |= OPTION_PARSED('2'); + tcpcong->algorithm_name[0] = '\0'; + break; + default: + return 0; + } + return 1; +} + + +/* + * Check for incompatible combinations of options. + * + * Inputs: + * flags -- (*target)->tflags from parse(). + * Side effects: + * exit_error(PARAMETER_PROBLEM, ...) called if incompatible combinations + * exist. + */ +static void +final_check(unsigned int flags) +{ + if (!flags) { + exit_error(PARAMETER_PROBLEM, + "TCPCONG: At least one parameter is required"); + } + if ((flags & OPTION_PARSED('1')) && (flags & OPTION_PARSED('2'))) { + exit_error(PARAMETER_PROBLEM, + "TCPCONG: Both --tcpcong-algorithm and " + "--tcpcong-algorithm-default cannot be requested."); + } +} + + +/* + * Describe the target for "iptables --list", a human-readable listing of + * rules. + * + * Inputs: + * ip -- general IP Tables information, + * target -- information for this instance of the target. + * numeric -- ?? + * Side effects: + * print target to stdout + */ +static void +print(const struct ipt_ip *ip, + const struct ipt_entry_target *target, + int numeric) +{ + const struct ipt_TCPCONG *tcpcong = + (const struct ipt_TCPCONG *)target->data; + + printf("algorithm:%s", + tcpcong->algorithm_name[0] + ? tcpcong->algorithm_name + : "default"); +} + + +/* + * Describe target for "iptables-save", a machine-readable listing of rules. + * + * Inputs: + * ip -- general IP Tables information, + * target -- information for this instance of the target. + * Side effects: + * print target to stdout + */ +static void +save(const struct ipt_ip *ip, + const struct ipt_entry_target *target ) +{ + const struct ipt_TCPCONG *tcpcong = + (const struct ipt_TCPCONG *)target->data; + + if (tcpcong->algorithm_name[0]) { + printf("TCPCONG --tcpcong-algorithm %s", + tcpcong->algorithm_name); + } else { + printf("TCPCONG --tcpcong-algorithm-default"); + } +} + + +/* + * The registration record for this target. + */ +static struct iptables_target tcpcong_target = { + .next = NULL, + .name = "TCPCONG", + .version = IPTABLES_VERSION, + .size = IPT_ALIGN(sizeof(struct ipt_TCPCONG)), + .userspacesize = IPT_ALIGN(sizeof(struct ipt_TCPCONG)), + .help = &help, + .init = &init, + .parse = &parse, + .final_check = &final_check, + .print = &print, + .save = &save, + .extra_opts = extra_opts +}; + + +/* + * This registers the target into the list of available targets so + * that the options become available. + */ +void +_init(void) +{ + register_target(&tcpcong_target); +} Property changes on: patchlets/TCPCONG/iptables/extensions/libipt_TCPCONG.c ___________________________________________________________________ Name: svn:keywords + Id Name: svn:eol-style + native Index: patchlets/TCPCONG/iptables/extensions/.TCPCONG-test =================================================================== --- patchlets/TCPCONG/iptables/extensions/.TCPCONG-test (revision 0) +++ patchlets/TCPCONG/iptables/extensions/.TCPCONG-test (revision 0) @@ -0,0 +1,2 @@ +#!/bin/sh +[ -f $KERNEL_DIR/net/ipv4/netfilter/ipt_TCPCONG.c ] && echo TCPCONG Property changes on: patchlets/TCPCONG/iptables/extensions/.TCPCONG-test ___________________________________________________________________ Name: svn:executable + * Index: patchlets/TCPCONG/iptables/extensions/libipt_TCPCONG.man =================================================================== --- patchlets/TCPCONG/iptables/extensions/libipt_TCPCONG.man (revision 0) +++ patchlets/TCPCONG/iptables/extensions/libipt_TCPCONG.man (revision 0) @@ -0,0 +1,123 @@ +.\" Manual page component for Netfilter TCPCONG target. +.\" +.\" @(#) $Id$ +.\" +.\" Copyright ? Glen David Turner of Semaphore, South Australia, 2006. +.\" +.\" +.\" 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. + +This module sets the TCP congestion control algorithm. +.TP +.BI "--tcpcong-algorithm " "algorithm" +Set the TCP congestion control algorithm to the algorithm named +.I algorithm +.TP +.BI "--tcpcong-algorithm-default" +Set the TCP congestion control algorithm to the default algorithm. The +default algorithm is determined by the value of the sysctl variable +\fInet.ipv4.tcp_congestion_control\fP. If that variable is not set +then the default value is determined by the kernel build +options. There is no means of getting this algorithm name from a +running kernel. This option is the same as --tcpcong-algorithm "" but +is provided to avoid the nightmare of quoting an empty string from the +shell. +.P +This target requires a Linux kernel 2.6.13 or later built with the +option CONFIG_TCP_CONG_ADVANCED enabled. The available algorithms +depend upon the algorithms selected when the kernel was built. There +is no way to get a list of available algorithms from a running +kernel. Algorithms available in Linux kernel 2.6.17 are: bic, reno, +cubic, highspeed, htcp, hybla, scalable, vegas, westwood. +.P +Some TCP congestion control algorithms are: +.TP +.I bic +BIC-TCP (Rhee, NCSU). Designed for long fat pipes. The default in +recent Linux kernels. +.TP +.I cubic +CUBIC-TCP (Rhee, NCSU). Designed for long fat pipes, designed to +overcome issues with BIC-TCP. +.TP +.I highspeed +HighSpeed TCP (Floyd, ICIR). The original modification for long fat +pipes. +.TP +.I htcp +Hamilton TCP (Leith, Hamilton Institute). Designed for long fat +pipes. Shares capacity with other connections well. +.TP +.I hybla +Hybla TCP. Designed for satellite links. These have bandwith under +100Mbps, round-trip times of 500ms or more, and high error rates. +.TP +.I reno +Reno BSD (Jacobson, Packet Design). The traditional TCP congestion +avoidance algorithm. Used by older TCP/IP implementations based on +BSD4.3. +.TP +.I scalable +Scalable TCP. (Kelly, Cambridge). A variant of Highspeed TCP which +works well on all bandwidths. +.TP +.I vegas +Vegas BSD (Brakmo & Peterson, Arizona). Uses queuing delay rather than +packet loss as the measure of network congestion. Used by BSD4.4. +.TP +.I westwood +Westwood TCP (Mascolo, Politecnico di Bari). Designed for wireless +networks. These have high error rates. +.TP +EXAMPLE +Select the Westwood+ TCP congestion control algorithm for +traffic using the wireless interface eth1. +.P +iptables --table filter --append OUTPUT --out-interface eth1 --protocol tcp --tcp-flags SYN,FIN,RST SYN --jump TCPCONG --tcpcong-algoriithm westwood +.P +Note that a match of "--protocol tcp" is required when +--tcpcong-algorithm is used as setting the TCP congestion control +algorithm for a non-TCP connections makes little sense. +.P +Using the OUTPUT chain is more reliable than using the INPUT chain. A +SYN flows both ways during a TCP connection establishment so either +chain can be used in theory, but in practice not all incoming packets +will have a socket assigned to them at the time when Netfilter +examines an INPUT packet. A socket records the details of the +connection, so a socket must have been allocated to the packet to +alter a detail like the TCP congestion control algorithm. Using the +FORWARD chain makes no sense at all. +.P +The TCP congestion control algorithm of the transmitter of the data +controls most of the aspects of congestion control. In the above +example the wireless LAN device would usually only notice an +improvement when uploading data. +.TP EXAMPLE +Select the Hamilton TCP congestion control algorithm for connections +to the service on port 80 on the machine at 10.1.1.1. +.P +iptables --table filter --append OUTPUT --destination 10.1.1.1 +--protocol tcp --destination-port 80 --jump TCPCONG +--tcpcong-algorithm htcp +.P +If the TCP buffer size is inadequate then altering the TCP congestion +control algorithm will generally not improve performance. For maximum +performance with long-lived connections across low loss media the TCP +buffer size must meet or exceed the bandwidth-delay product of the +connection's path through the network. Often the operating system's +default TCP buffer size is far too small. +.P +An application can use setsockopt(..., SOL_TCP, TCP_CONGESTION, +"alogorithm", strlen("algorithm")) to achieve a result identical to +this target. This target is useful when modifying the application is +not justified. +.P +To alter the congestion control algorithm for all connections modify +the sysctl variable \fInet.ipv4.tcp_congestion_control\fP rather than +use this module. +.TP +SEE ALSO +http://www.aarnet.edu.au/~gdt/patch/tcpcong/ Index: patchlets/TCPCONG/help =================================================================== --- patchlets/TCPCONG/help (revision 0) +++ patchlets/TCPCONG/help (revision 0) @@ -0,0 +1,3 @@ + +This target sets the TCP congestion control algorithm. + Index: patchlets/TCPCONG/info =================================================================== --- patchlets/TCPCONG/info (revision 0) +++ patchlets/TCPCONG/info (revision 0) @@ -0,0 +1,10 @@ +Title: Sets TCP congestion control algorithm +Author: Glen Turner, +Status: Beta +Repository: base +Requires: linux-2.6 >= 2.6.13 +Requires: linux-2.6.patch >= 2.6.13 +Recompile: kernel +Recompile: iptables + +Target to set TCP congestion control algorithm. Index: sources.list =================================================================== --- sources.list (revision 6678) +++ sources.list (working copy) @@ -9,3 +9,6 @@ # ipp2p, time, IPMARK and connlimit maintained by Krzysztof Oledzki http://people.netfilter.org/ole/pom/ + +# TCPCONG maintained by Glen Turner +http://www.aarnet.edu.au/~gdt/patch/tcpcong/ From deti at fliegl.de Thu Oct 5 11:54:20 2006 From: deti at fliegl.de (Deti Fliegl) Date: Thu Oct 5 12:30:56 2006 Subject: Can i have a rate limit per source IP Address in IPSet? In-Reply-To: References: <4524B968.303@fliegl.de> Message-ID: <4524D64C.4070203@fliegl.de> Retesh Chadha wrote: > What is hash-limit name supposed to be? > Can you send me a sample of this file. The hashlimit match is part of standard 2.6. kernel. For further documentation see http://www.netfilter.org/patch-o-matic/pom-submitted.html#pom-submitted-hashlimit Deti From deti at fliegl.de Thu Oct 5 12:13:12 2006 From: deti at fliegl.de (Deti Fliegl) Date: Thu Oct 5 12:49:51 2006 Subject: Can i have a rate limit per source IP Address in IPSet? In-Reply-To: References: <4524B968.303@fliegl.de> <4524D64C.4070203@fliegl.de> Message-ID: <4524DAB8.9000409@fliegl.de> Retesh Chadha wrote: > But this page doesnt contain what should be kept in the foo file. I > dont have a sample of the same as well.. Oh well..... for example if you set '--hashlimit-name foo' a corresponding '/proc/net/ipt_hashlimit/foo' file will be created automatically with the first hashlimit match rule in your ruleset. These files are not writable and normally there should be no need to look into these files except you are a very experienced user. Deti From pablo at netfilter.org Thu Oct 5 12:23:02 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu Oct 5 12:52:51 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <200610041531.17209.alan.ezust@presinet.com> References: <200610031518.10097.alan.ezust@presinet.com> <200610041333.19451.alan.ezust@presinet.com> <45242FFC.4010500@netfilter.org> <200610041531.17209.alan.ezust@presinet.com> Message-ID: <4524DD06.50901@netfilter.org> Alan Ezust wrote: > On Wednesday 04 October 2006 15:04, Pablo Neira Ayuso wrote: >> Alan Ezust wrote: >>> On Wednesday 04 October 2006 12:48, Pablo Neira Ayuso wrote: >>>> Alan Ezust wrote: >>>>> Hi - i'm trying out the "conntrack" program for my first time. >>>>> It compiles and runs, but when I try to do >>>>> >>>>> conntrack -L conntrack >>>>> >>>>> it shows me nothing. >>>>> >>>>> If I cat /proc/net/ip_conntrack I can see lots of log lines there. >>>>> Should the conntrack -L conntrack show me pretty much the same thing? >>>>> >>>>> What's the best way to test that conntrack is working properly? >>>> Please check that ip_conntrack_netlink is loaded, old kernel do not load >>>> it on demand. >>> I'm using kernel 2.6.16.29. >>> >>> These kernel options are set: >>> >>> CONFIG_NETFILTER_NETLINK=y >>> CONFIG_NETFILTER_NETLINK_QUEUE=y >>> CONFIG_NETFILTER_NETLINK_LOG=y >>> CONFIG_IP_NF_CONNTRACK_NETLINK=y >>> >>> Are you saying I should also add a >>> CONFIG_IP_CONNTRACK_NETLINK flag in the .config or something else? >> No, people usually compile ip_conntrack_netlink as module, and I wanted >> to make sure that the module was loaded (modprobe ip_conntrack_netlink) >> but since you compiled it built-in. > > What's the difference between IP_NF_CONNTRACK_NETLINK and > IP_CONNTRACK_NETLINK? Are they different modules or is one the new name for > the other? you're referring to the same thing. This problem that you're observing is freak. Please check that ctnetlink is correctly registered. # dmesg | grep ctnetlink ctnetlink v0.90: registering with nfnetlink. Send me also your .config file just to have more information. >> Could you tell me what version of conntrack/libnetfilter_conntrac are >> you using? > > conntrack 1.00beta2 > libnetfilter_conntrack-0.0.31/ > libnfnetlink-0.0.16/ Please, try with an updated version from netfilter's SVN -- 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 Thu Oct 5 12:36:44 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu Oct 5 13:06:33 2006 Subject: iptables won't compile in a debug turned on In-Reply-To: <1159989997.28977.166.camel@mfarooq-1.tango-networks.com> References: <1159989997.28977.166.camel@mfarooq-1.tango-networks.com> Message-ID: <4524E03C.6070003@netfilter.org> Mohammad Farooq wrote: > Are you guys aware of that is in the iptables-1.3.6/Makefile if turn on > debugging: > CFLAGS:=$(COPT_FLAGS) -Wall -Wunused -I$(KERNEL_DIR)/include -Iinclude/ > -DIPTABLES_VERSION=\"$(IPTABLES_VERSION)\" -g -DDEBUG -pg -DIPTC_DEBUG > the compile will fail. > > MF > > libiptc/libip6tc.c: In function `do_check': > libiptc/libip6tc.c:284: warning: implicit declaration of function > `get_chain_end' > libiptc/libip6tc.c:285: warning: implicit declaration of function > `get_entry' > [...] I didn't notice, it seems that nobody has been using it for quite some time. I'm not sure if it is worth fixing this. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From deti at fliegl.de Thu Oct 5 13:11:05 2006 From: deti at fliegl.de (Deti Fliegl) Date: Thu Oct 5 13:47:45 2006 Subject: Can i have a rate limit per source IP Address in IPSet? In-Reply-To: References: <4524B968.303@fliegl.de> <4524D64C.4070203@fliegl.de> <4524DAB8.9000409@fliegl.de> Message-ID: <4524E849.5020604@fliegl.de> Retesh Chadha wrote: > I get following error when i do the same - > > linux:~ # iptables -A INPUT --match hashlimit --hashlimit 1/s > --hashlimit-mode srcip --hashlimit-name foo -j LOG > iptables: No chain/target/match by that name Make sure you have a kernel (~ >2.6.12) with CONFIG_IP_NF_MATCH_HASHLIMIT enabled. Deti From mohammadfarooq at tango-networks.com Thu Oct 5 16:16:30 2006 From: mohammadfarooq at tango-networks.com (Mohammad Farooq) Date: Thu Oct 5 16:53:13 2006 Subject: iptables won't compile in a debug turned on In-Reply-To: <4524E03C.6070003@netfilter.org> References: <1159989997.28977.166.camel@mfarooq-1.tango-networks.com> <4524E03C.6070003@netfilter.org> Message-ID: <1160057790.28977.181.camel@mfarooq-1.tango-networks.com> On Thu, 2006-10-05 at 12:36 +0200, Pablo Neira Ayuso wrote: > Mohammad Farooq wrote: > > Are you guys aware of that is in the iptables-1.3.6/Makefile if turn on > > debugging: > > CFLAGS:=$(COPT_FLAGS) -Wall -Wunused -I$(KERNEL_DIR)/include -Iinclude/ > > -DIPTABLES_VERSION=\"$(IPTABLES_VERSION)\" -g -DDEBUG -pg -DIPTC_DEBUG > > the compile will fail. > > > > MF > > > > libiptc/libip6tc.c: In function `do_check': > > libiptc/libip6tc.c:284: warning: implicit declaration of function > > `get_chain_end' > > libiptc/libip6tc.c:285: warning: implicit declaration of function > > `get_entry' > > [...] > > I didn't notice, it seems that nobody has been using it for quite some > time. I'm not sure if it is worth fixing this. > When everything works okay, yes this fix may not be needed. I was trying to debug this problem with the u32 module that it was giving me "Invalid argument" error. In desperation every bit of information helps. MF From kernel at linuxace.com Thu Oct 5 22:51:44 2006 From: kernel at linuxace.com (Phil Oester) Date: Thu Oct 5 23:28:27 2006 Subject: iptables won't compile in a debug turned on In-Reply-To: <1160057790.28977.181.camel@mfarooq-1.tango-networks.com> References: <1159989997.28977.166.camel@mfarooq-1.tango-networks.com> <4524E03C.6070003@netfilter.org> <1160057790.28977.181.camel@mfarooq-1.tango-networks.com> Message-ID: <20061005205144.GA25940@linuxace.com> On Thu, Oct 05, 2006 at 09:16:30AM -0500, Mohammad Farooq wrote: > When everything works okay, yes this fix may not be needed. I was trying > to debug this problem with the u32 module that it was giving me "Invalid > argument" error. In desperation every bit of information helps. Only enable the "-g -DDEBUG -pg" debug options - not the last one. Phil From retesh.chadha at gmail.com Fri Oct 6 08:43:20 2006 From: retesh.chadha at gmail.com (Retesh Chadha) Date: Fri Oct 6 09:20:03 2006 Subject: Can i have a rate limit per source IP Address in IPSet? In-Reply-To: <4524E849.5020604@fliegl.de> References: <4524B968.303@fliegl.de> <4524D64C.4070203@fliegl.de> <4524DAB8.9000409@fliegl.de> <4524E849.5020604@fliegl.de> Message-ID: Hi Deti Big thanks for your help. I was able to set a limit per destination ip. I have another question though. I now need to set a limit per src dst pair, but I get a bad mode for hashlimit-mode srcipdstip. I give the following command - iptables -A INPUT_CHAIN --match hashlimit --hashlimit 1000/s --hashlimit-mode srcip-dstip --hashlimit-name foo -m set --set KNOWN src,dst -j ACCEPT Thanks & Regards Retesh Chadha From deti at fliegl.de Fri Oct 6 09:40:00 2006 From: deti at fliegl.de (Deti Fliegl) Date: Fri Oct 6 10:17:03 2006 Subject: Can i have a rate limit per source IP Address in IPSet? In-Reply-To: References: <4524B968.303@fliegl.de> <4524D64C.4070203@fliegl.de> <4524DAB8.9000409@fliegl.de> <4524E849.5020604@fliegl.de> Message-ID: <45260850.4000108@fliegl.de> Hi, Retesh Chadha wrote: > I have another question though. I now need to set a limit per src dst > pair, but I get a bad mode for hashlimit-mode srcipdstip. > I give the following command - > > iptables -A INPUT_CHAIN --match hashlimit --hashlimit 1000/s > --hashlimit-mode srcip-dstip --hashlimit-name foo -m set --set KNOWN > src,dst -j ACCEPT There is a minor documentation bug: '--hashlimit-mode srcip,dstip' should work for you. Deti From nishit at elitecore.com Fri Oct 6 09:57:13 2006 From: nishit at elitecore.com (Nishit Shah) Date: Fri Oct 6 10:25:58 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel Message-ID: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> Hi, During my load testing on kernel 2.6.16.13 i got following kernel oops. It occures when I enable SNAT or MASQUERADE for all outgoing traffic, with ACCEPT load testing works fine for me. Regards, Nishit Shah. Oct 06 11:33:28 1160114608 kernel: BUG: soft lockup detected on CPU#0! Oct 06 11:33:28 1160114608 kernel: Oct 06 11:33:28 1160114608 kernel: Pid: 1754, comm: in.telnetd Oct 06 11:33:28 1160114608 kernel: EIP: 0060:[pg0+944264370/1068717056] CPU: 0 Oct 06 11:33:28 1160114608 kernel: EIP is at __ip_conntrack_find+0x22/0xb0 [ip_conntrack] Oct 06 11:33:28 1160114608 kernel: EFLAGS: 00000292 Not tainted (2.6.16.13-1 #4) Oct 06 11:33:28 1160114608 kernel: EAX: 00016ac5 EBX: f5e01218 ECX: f5c00000 EDX: f5cb5628 Oct 06 11:33:28 1160114608 kernel: ESI: 000046b9 EDI: f7bf1754 EBP: f5fb6400 DS: 007b ES: 007b Oct 06 11:33:28 1160114608 kernel: CR0: 8005003b CR2: b7ee7dc4 CR3: 37a05000 CR4: 000006d0 Oct 06 11:33:28 1160114608 kernel: [pg0+944265669/1068717056] ip_conntrack_tuple_taken+0x25/0x40 [ip_conntrack] Oct 06 11:33:28 1160114608 kernel: [pg0+944312635/1068717056] ip_nat_used_tuple+0x2b/0x40 [ip_nat] Oct 06 11:33:28 1160114608 kernel: [pg0+944318447/1068717056] tcp_unique_tuple+0xaf/0x120 [ip_nat] Oct 06 11:33:28 1160114608 kernel: [pg0+944313566/1068717056] get_unique_tuple+0xae/0x100 [ip_nat] Oct 06 11:33:28 1160114608 kernel: [pg0+944313779/1068717056] ip_nat_setup_info+0x83/0x210 [ip_nat] Oct 06 11:33:28 1160114608 kernel: [pg0+944353635/1068717056] masquerade_target+0x103/0x110 [ipt_MASQUERADE] Oct 06 11:33:28 1160114608 kernel: [pg0+944353376/1068717056] masquerade_target+0x0/0x110 [ipt_MASQUERADE] Oct 06 11:33:28 1160114608 kernel: [pg0+943993598/1068717056] ipt_do_table+0x2ce/0x360 [ip_tables] Oct 06 11:33:28 1160114608 kernel: [pg0+944333715/1068717056] ip_nat_rule_find+0x43/0xc0 [iptable_nat] Oct 06 11:33:28 1160114608 kernel: [_write_unlock_bh+11/32] _write_unlock_bh+0xb/0x20 Oct 06 11:33:28 1160114608 kernel: [pg0+944334424/1068717056] ip_nat_fn+0xe8/0x200 [iptable_nat] Oct 06 11:33:28 1160114608 kernel: [_read_unlock_bh+11/32] _read_unlock_bh+0xb/0x20 Oct 06 11:33:28 1160114608 kernel: [ip_finish_output+0/528] ip_finish_output+0x0/0x210 Oct 06 11:33:28 1160114608 kernel: [pg0+944335016/1068717056] ip_nat_out+0x78/0x110 [iptable_nat] Oct 06 11:33:28 1160114608 kernel: [ip_finish_output+0/528] ip_finish_output+0x0/0x210 Oct 06 11:33:28 1160114608 kernel: [ip_finish_output+0/528] ip_finish_output+0x0/0x210 Oct 06 11:33:28 1160114608 kernel: [nf_iterate+120/144] nf_iterate+0x78/0x90 Oct 06 11:33:28 1160114608 kernel: [ip_finish_output+0/528] ip_finish_output+0x0/0x210 Oct 06 11:33:28 1160114608 kernel: [ip_finish_output+0/528] ip_finish_output+0x0/0x210 Oct 06 11:33:28 1160114608 kernel: [nf_hook_slow+110/272] nf_hook_slow+0x6e/0x110 Oct 06 11:33:28 1160114608 kernel: [ip_finish_output+0/528] ip_finish_output+0x0/0x210 Oct 06 11:33:28 1160114608 kernel: [ip_output+700/720] ip_output+0x2bc/0x2d0 Oct 06 11:33:29 1160114609 kernel: [ip_finish_output+0/528] ip_finish_output+0x0/0x210 Oct 06 11:33:29 1160114609 kernel: [ip_forward+420/720] ip_forward+0x1a4/0x2d0 Oct 06 11:33:29 1160114609 kernel: [ip_forward_finish+0/64] ip_forward_finish+0x0/0x40 Oct 06 11:33:29 1160114609 kernel: [ip_rcv+624/1264] ip_rcv+0x270/0x4f0 Oct 06 11:33:29 1160114609 kernel: [ip_rcv_finish+0/624] ip_rcv_finish+0x0/0x270 Oct 06 11:33:29 1160114609 kernel: [netif_receive_skb+492/624] netif_receive_skb+0x1ec/0x270 Oct 06 11:33:29 1160114609 kernel: [pg0+944029678/1068717056] e1000_clean_rx_irq+0x1ce/0x5f0 [e1000] Oct 06 11:33:29 1160114609 kernel: [ktime_get_ts+97/112] ktime_get_ts+0x61/0x70 Oct 06 11:33:29 1160114609 kernel: [pg0+944028203/1068717056] e1000_clean+0xbb/0x1c0 [e1000] Oct 06 11:33:29 1160114609 kernel: [net_rx_action+116/256] net_rx_action+0x74/0x100 Oct 06 11:33:29 1160114609 kernel: [__do_softirq+123/144] __do_softirq+0x7b/0x90 Oct 06 11:33:29 1160114609 kernel: [do_softirq+38/48] do_softirq+0x26/0x30 Oct 06 11:33:29 1160114609 kernel: [local_bh_enable+70/128] local_bh_enable+0x46/0x80 Oct 06 11:33:29 1160114609 kernel: [_write_unlock_bh+11/32] _write_unlock_bh+0xb/0x20 Oct 06 11:33:29 1160114609 kernel: [pg0+944276160/1068717056] tcp_packet+0x180/0x5d0 [ip_conntrack] Oct 06 11:33:29 1160114609 kernel: [local_bh_enable+70/128] local_bh_enable+0x46/0x80 Oct 06 11:33:29 1160114609 kernel: [_read_unlock_bh+11/32] _read_unlock_bh+0xb/0x20 Oct 06 11:33:29 1160114609 kernel: [pg0+944267281/1068717056] ip_conntrack_in+0xe1/0x2d0 [ip_conntrack] Oct 06 11:33:29 1160114609 kernel: [dst_output+0/32] dst_output+0x0/0x20 Oct 06 11:33:29 1160114609 kernel: [nf_iterate+120/144] nf_iterate+0x78/0x90 Oct 06 11:33:29 1160114609 kernel: [dst_output+0/32] dst_output+0x0/0x20 Oct 06 11:33:29 1160114609 kernel: [dst_output+0/32] dst_output+0x0/0x20 Oct 06 11:33:29 1160114609 kernel: [nf_hook_slow+110/272] nf_hook_slow+0x6e/0x110 Oct 06 11:33:29 1160114609 kernel: [dst_output+0/32] dst_output+0x0/0x20 Oct 06 11:33:29 1160114609 kernel: [ip_queue_xmit+1022/1360] ip_queue_xmit+0x3fe/0x550 Oct 06 11:33:29 1160114609 kernel: [dst_output+0/32] dst_output+0x0/0x20 Oct 06 11:33:29 1160114609 kernel: [ip_rcv+624/1264] ip_rcv+0x270/0x4f0 Oct 06 11:33:29 1160114609 kernel: [ip_rcv_finish+0/624] ip_rcv_finish+0x0/0x270 Oct 06 11:33:29 1160114609 kernel: [netif_receive_skb+492/624] netif_receive_skb+0x1ec/0x270 Oct 06 11:33:29 1160114609 kernel: [pg0+944029868/1068717056] e1000_clean_rx_irq+0x28c/0x5f0 [e1000] Oct 06 11:33:29 1160114609 kernel: [ktime_get_ts+97/112] ktime_get_ts+0x61/0x70 Oct 06 11:33:29 1160114609 kernel: [tcp_cwnd_restart+41/240] tcp_cwnd_restart+0x29/0xf0 Oct 06 11:33:29 1160114609 kernel: [tcp_event_data_sent+117/128] tcp_event_data_sent+0x75/0x80 Oct 06 11:33:29 1160114609 kernel: [tcp_transmit_skb+799/1184] tcp_transmit_skb+0x31f/0x4a0 Oct 06 11:33:29 1160114609 kernel: [pg0+944028203/1068717056] e1000_clean+0xbb/0x1c0 [e1000] Oct 06 11:33:29 1160114609 kernel: [tcp_write_xmit+374/656] tcp_write_xmit+0x176/0x290 Oct 06 11:33:29 1160114609 kernel: [__tcp_push_pending_frames+53/176] __tcp_push_pending_frames+0x35/0xb0 Oct 06 11:33:29 1160114609 kernel: [tcp_sendmsg+873/3120] tcp_sendmsg+0x369/0xc30 Oct 06 11:33:29 1160114609 kernel: [buffered_rmqueue+246/544] buffered_rmqueue+0xf6/0x220 Oct 06 11:33:29 1160114609 kernel: [inet_sendmsg+74/96] inet_sendmsg+0x4a/0x60 Oct 06 11:33:29 1160114609 kernel: [do_sock_write+161/192] do_sock_write+0xa1/0xc0 Oct 06 11:33:29 1160114609 kernel: [sock_aio_write+148/160] sock_aio_write+0x94/0xa0 Oct 06 11:33:29 1160114609 kernel: [do_sync_write+209/288] do_sync_write+0xd1/0x120 Oct 06 11:33:29 1160114609 kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60 Oct 06 11:33:29 1160114609 kernel: [vfs_write+364/384] vfs_write+0x16c/0x180 Oct 06 11:33:29 1160114609 kernel: [sys_write+81/128] sys_write+0x51/0x80 Oct 06 11:33:29 1160114609 kernel: [syscall_call+7/11] syscall_call+0x7/0xb From deti at fliegl.de Fri Oct 6 10:10:02 2006 From: deti at fliegl.de (Deti Fliegl) Date: Fri Oct 6 10:46:46 2006 Subject: kernel oops in 2.6.17.7 (smp) Message-ID: <45260F5A.60700@fliegl.de> Hi there, a kernel oops happens since ages with this setup with all recent kernels (since 2.6.12) - and most probably even with the latest versions. Here it takes about 60 days to reproduce: ---------------------------------------------------------------- Unable to handle kernel paging request at ffffc2000031d103 RIP: {:ip_tables:ipt_do_table+194} PGD 11fc42067 PUD 11fc43067 PMD 11f72b067 PTE 0 Oops: 0000 [1] SMP CPU 2 Modules linked in: ipt_ipp2p ipt_REDIRECT af_packet i8xx_tco xt_CLASSIFY sch_htb xt_mark xt_CONNMARK ipt_SAME xt_state xt_pkttype xt_NOTRACK iptable_raw edd ipt_LOG xt_limit ipt_hashlimit xt_tcpudp ip_conntrack_netlink ip_nat_ftp ip_conntrack_ftp thermal processor fan button iptable_nat battery ip_nat ac xt_MARK ip_conntrack nfnetlink iptable_filter iptable_mangle ip_tables x_tables ipmi_si ipmi_devintf ipmi_msghandler ext3 jbd ide_cd cdrom e1000 piix sg megaraid_mbox megaraid_mm sd_mod scsi_mod ide_disk ide_core Pid: 4709, comm: syslog-ng Not tainted 2.6.17.7-smp #1 RIP: 0010:[] {:ip_tables:ipt_do_table+194} RSP: 0018:ffff81011cff9a88 EFLAGS: 00010206 RAX: ffffc2000031d0b0 RBX: 0000000000000000 RCX: ffff81011eff2000 RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffffffff8810dc58 RBP: ffffc2000031d0b0 R08: ffffffff8810dc58 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffffc2000031b000 R14: ffff81003f366010 R15: 0000000000000000 FS: 00002b41a73416e0(0000) GS:ffff81011fc6ed40(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffc2000031d103 CR3: 000000011cfd9000 CR4: 00000000000006e0 Process syslog-ng (pid: 4709, threadinfo ffff81011cff8000, task ffff81011c4f5760) Stack: 0000000000000000 ffff81011eff2000 0000000000000000 0000000388136493 ffff81011cff9be0 ffffffff8810dc58 0000000000000000 ffffffff88108688 ffff81011eff2000 ffffc2000031d0b0 Call Trace: {nf_iterate+63} {dst_output+0} {nf_hook_slow+90} {dst_output+0} {ip_generic_getfrag+40} {ip_push_pending_frames+877} {udp_push_pending_frames+559} {udp_sendmsg+1172} {dput+32} {__link_path_walk+3399} {do_sock_write+193} {sock_aio_write+81} {do_sync_write+199} {_atomic_dec_and_lock+52} {autoremove_wake_function+0} {vfs_write+225} {sys_write+69} {system_call+126} Code: 40 8a 7d 53 40 0f b6 f7 8b 45 08 41 23 46 0c 3b 45 00 0f 95 RIP {:ip_tables:ipt_do_table+194} RSP CR2: ffffc2000031d103 <0>Kernel panic - not syncing: Aiee, killing interrupt handler! ---------------------------------------------------------------- For me it looks like a race condition or memory corruption within iptables even though it happend in the process context of syslog-ng. Any clues? Deti From alan.ezust at presinet.com Fri Oct 6 22:14:15 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Fri Oct 6 22:51:38 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <4524DD06.50901@netfilter.org> References: <200610031518.10097.alan.ezust@presinet.com> <200610041531.17209.alan.ezust@presinet.com> <4524DD06.50901@netfilter.org> Message-ID: <200610061314.16177.alan.ezust@presinet.com> On Thursday 05 October 2006 03:23, Pablo Neira Ayuso wrote: > Alan Ezust wrote: > > On Wednesday 04 October 2006 15:04, Pablo Neira Ayuso wrote: > >> Alan Ezust wrote: > >>> On Wednesday 04 October 2006 12:48, Pablo Neira Ayuso wrote: > >>>> Alan Ezust wrote: > >>>>> Hi - i'm trying out the "conntrack" program for my first time. > >>>>> It compiles and runs, but when I try to do > >>>>> > >>>>> conntrack -L conntrack > >>>>> > >>>>> it shows me nothing. > >>>>> > >>>>> If I cat /proc/net/ip_conntrack I can see lots of log lines there. > >>>>> Should the conntrack -L conntrack show me pretty much the same thing? > >>>>> > >>>>> What's the best way to test that conntrack is working properly? > >>>> > >>>> Please check that ip_conntrack_netlink is loaded, old kernel do not > >>>> load it on demand. > >>> > >>> I'm using kernel 2.6.16.29. > >>> > >>> These kernel options are set: > >>> > >>> CONFIG_NETFILTER_NETLINK=y > >>> CONFIG_NETFILTER_NETLINK_QUEUE=y > >>> CONFIG_NETFILTER_NETLINK_LOG=y > >>> CONFIG_IP_NF_CONNTRACK_NETLINK=y > >>> > >>> Are you saying I should also add a > >>> CONFIG_IP_CONNTRACK_NETLINK flag in the .config or something else? > >> > >> No, people usually compile ip_conntrack_netlink as module, and I wanted > >> to make sure that the module was loaded (modprobe ip_conntrack_netlink) > >> but since you compiled it built-in. > > > > What's the difference between IP_NF_CONNTRACK_NETLINK and > > IP_CONNTRACK_NETLINK? Are they different modules or is one the new name > > for the other? > > you're referring to the same thing. This problem that you're observing > is freak. Please check that ctnetlink is correctly registered. On my machine, when I do lsmod, here is the list of modules I have loaded: ip_conntrack_netlink 22016 0 ip_nat 14164 1 ip_conntrack_netlink ipt_recent 9836 2 ipt_LOG 5856 4 ipt_bin 20772 7 iptable_promisc 1376 1 ipt_multiport 2112 10 iptable_filter 2112 1 ip_tables 10816 2 iptable_promisc,iptable_filter xt_conntrack 1856 0 xt_CONNMARK 1824 2 xt_connmark 1440 2 xt_pkttype 1440 1 xt_MARK 2080 0 xt_state 1536 4 ipt_psd 43588 1 ipt_regex 7240 1 ipt_DATA 3712 5 ip_conntrack 45996 7 ip_conntrack_netlink,ip_nat,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state,ipt_DATA tulip 45152 0 eepro100 25776 0 8139too 20352 0 3c59x 38952 0 8390 8320 0 > > # dmesg | grep ctnetlink > ctnetlink v0.90: registering with nfnetlink. Got that - here is my dmesg tail: ip_conntrack version 2.4 (2048 buckets, 16384 max) - 252 bytes per conntrack ipt_regex v0.0.0 netfilter PSD loaded - (c) astaro AG ip_conntrack_netlink: Unknown symbol ip_nat_setup_info ip_conntrack_netlink: Unknown symbol ip_nat_proto_put ip_conntrack_netlink: Unknown symbol ip_nat_proto_find_get eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 eth1: link down ip_tables: (C) 2000-2006 Netfilter Core Team ipt_bin v1.2.2 ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ martian source 10.10.1.32 from 209.53.156.2, on dev eth0 ll header: ff:ff:ff:ff:ff:ff:00:07:66:02:d3:ff:08:06 ctnetlink v0.90: registering with nfnetlink. martian source 10.10.1.13 from 10.10.100.100, on dev eth0 ll header: ff:ff:ff:ff:ff:ff:aa:00:00:6f:50:1f:08:06 martian source 10.10.1.25 from 10.10.100.100, on dev eth0 ll header: ff:ff:ff:ff:ff:ff:aa:00:00:6f:50:1f:08:06 > > Send me also your .config file just to have more information. attached. > >> Could you tell me what version of conntrack/libnetfilter_conntrac are > >> you using? > > > > conntrack 1.00beta2 > > libnetfilter_conntrack-0.0.31/ > > libnfnetlink-0.0.16/ > > Please, try with an updated version from netfilter's SVN I found an incompatibility in libnfnetlink. Before, I was building on a system that had 2.6.18 on it, and trying to deploy it on a machine that had kernel 2.6.16.29. The executable I built didn't do anything. Now I am compiling on a system that has the same version (2.6.16.29) of the kernel as the destination, I am unable to compile the latest (svn as well as released) versions of libnfnetlink. What is the recommended kernel version I should be using, if I want to get conntrack up and running for my first time? Should I go to 2.6.18 and forget about 2.6.16.29? gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libnfnetlink\" -DVERSION=\"0.0.16\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I../include -I/home/ezust/presinet/projects/conntrack/usr/include -fPIC -Wall -I/home/ezust/presinet/projects/conntrack/usr/include -L/home/ezust/presinet/projects/conntrack/usr/lib -MT libnfnetlink.lo -MD -MP -MF .deps/libnfnetlink.Tpo -c libnfnetlink.c -fPIC -DPIC -o .libs/libnfnetlink.o libnfnetlink.c: In function 'nfnl_listen': libnfnetlink.c:445: error: 'EINTR' undeclared (first use in this function) libnfnetlink.c:445: error: (Each undeclared identifier is reported only once libnfnetlink.c:445: error: for each function it appears in.) libnfnetlink.c:448: error: 'EBADF' undeclared (first use in this function) libnfnetlink.c:450: error: 'EAGAIN' undeclared (first use in this function) libnfnetlink.c: In function 'nfnl_talk': libnfnetlink.c:554: error: 'EINTR' undeclared (first use in this function) libnfnetlink.c: In function 'nfnl_callback_register': libnfnetlink.c:878: error: 'EINVAL' undeclared (first use in this function) libnfnetlink.c: In function 'nfnl_callback_unregister': libnfnetlink.c:888: error: 'EINVAL' undeclared (first use in this function) libnfnetlink.c: In function 'nfnl_check_attributes': libnfnetlink.c:906: error: 'EINVAL' undeclared (first use in this function) make[1]: *** [libnfnetlink.lo] Error 1 make[1]: Leaving directory `/home/ezust/presinet/projects/conntrack-1.00beta2/libnfnetlink-0.0.16/src' thanks again for your help --alan -------------- next part -------------- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.16.29 # Thu Oct 5 16:56:48 2006 # CONFIG_X86_32=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE="/home/ezust/presinet/projects/firmware/branches/sensor/binary/boot.cpio.uclibc" CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_UID16=y CONFIG_VM86=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # # CONFIG_LBD is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_ALIGNMENT_16=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_REGPARM is not set # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_KEXEC=y CONFIG_PHYSICAL_START=0x100000 CONFIG_DOUBLEFAULT=y # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Networking # CONFIG_NET=y # # Networking options # # CONFIG_NETDEBUG is not set CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_MULTIPATH=y # CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set CONFIG_INET_TUNNEL=m CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y CONFIG_TCP_CONG_ADVANCED=y # # TCP congestion control # CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=m CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m # CONFIG_TCP_CONG_HSTCP is not set # CONFIG_TCP_CONG_HYBLA is not set # CONFIG_TCP_CONG_VEGAS is not set # CONFIG_TCP_CONG_SCALABLE is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NETFILTER_XTABLES=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CONNTRACK_EVENTS=y CONFIG_IP_NF_CONNTRACK_NETLINK=m # CONFIG_IP_NF_CT_PROTO_SCTP is not set CONFIG_IP_NF_FTP=m # CONFIG_IP_NF_IRC is not set # CONFIG_IP_NF_NETBIOS_NS is not set # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set # CONFIG_IP_NF_PPTP is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_IPRANGE=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_TTL=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_MATCH_POLICY=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m # CONFIG_IP_NF_TARGET_ULOG is not set 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_SNMP_BASIC=m CONFIG_IP_NF_NAT_FTP=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_TTL=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP_NF_TARGET_IPV4OPTSSTRIP=m CONFIG_IP_NF_MATCH_IPV4OPTIONS=m CONFIG_IP_NF_MATCH_PSD=m CONFIG_IP_NF_SET=m CONFIG_IP_NF_SET_MAX=256 CONFIG_IP_NF_SET_HASHSIZE=1024 CONFIG_IP_NF_SET_IPMAP=m CONFIG_IP_NF_SET_MACIPMAP=m CONFIG_IP_NF_SET_PORTMAP=m CONFIG_IP_NF_SET_IPHASH=m CONFIG_IP_NF_SET_NETHASH=m CONFIG_IP_NF_SET_IPPORTHASH=m CONFIG_IP_NF_SET_IPTREE=m CONFIG_IP_NF_MATCH_SET=m CONFIG_IP_NF_TARGET_SET=m CONFIG_IP_NF_MATCH_U32=m CONFIG_IP_NF_MATCH_BIN=m CONFIG_IP_NF_MATCH_REGEX=m CONFIG_IP_NF_TARGET_DATA=m CONFIG_IP_NF_PROMISC=m # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=y CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m # CONFIG_BRIDGE_EBT_ULOG is not set # # DCCP Configuration (EXPERIMENTAL) # # CONFIG_IP_DCCP is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # # TIPC Configuration (EXPERIMENTAL) # # CONFIG_TIPC is not set # CONFIG_ATM is not set CONFIG_BRIDGE=y CONFIG_VLAN_8021Q=y # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m # # QoS and/or fair queueing # CONFIG_NET_SCHED=y # CONFIG_NET_SCH_CLK_JIFFIES is not set CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y # CONFIG_NET_SCH_CLK_CPU is not set # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m # CONFIG_NET_SCH_RED is not set CONFIG_NET_SCH_SFQ=m # CONFIG_NET_SCH_TEQL is not set CONFIG_NET_SCH_TBF=m # CONFIG_NET_SCH_GRED is not set CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m # CONFIG_NET_SCH_INGRESS is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m # CONFIG_NET_CLS_ACT is not set # CONFIG_NET_CLS_POLICE is not set CONFIG_NET_CLS_IND=y CONFIG_NET_ESTIMATOR=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_IEEE80211 is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # # Connector - unified userspace <-> kernelspace linker # # CONFIG_CONNECTOR is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set # CONFIG_MTD_PARTITIONS is not set # # User Modules And Translation Layers # # CONFIG_MTD_CHAR is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set CONFIG_NFTL=y CONFIG_NFTL_RW=y # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_TS5500 is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # # NAND Flash Device Drivers # CONFIG_MTD_NAND=y # CONFIG_MTD_NAND_VERIFY_WRITE is not set CONFIG_MTD_NAND_IDS=y CONFIG_MTD_NAND_DISKONCHIP=y # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 # CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set # # OneNAND Flash Device Drivers # # CONFIG_MTD_ONENAND is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play support # # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y # CONFIG_BLK_DEV_IDEDMA_PCI is not set # CONFIG_IDE_ARM is not set # CONFIG_BLK_DEV_IDEDMA is not set # CONFIG_IDEDMA_AUTO is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set # CONFIG_SCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m # # ARCnet devices # # CONFIG_ARCNET is not set # # PHY device support # # CONFIG_PHYLIB is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_TYPHOON=m # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set # CONFIG_TULIP_NAPI is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set CONFIG_HP100=m CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m # CONFIG_AMD8111E_NAPI is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set CONFIG_EEPRO100=m CONFIG_E100=m # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m # CONFIG_E1000_NAPI is not set # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # # Ethernet (10000 Mbit) # # CONFIG_CHELSIO_T1 is not set # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # CONFIG_SHAPER is not set CONFIG_NETCONSOLE=y CONFIG_NETPOLL=y # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HANGCHECK_TIMER is not set # # TPM devices # # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set # # I2C support # # CONFIG_I2C is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Hardware Monitoring support # # CONFIG_HWMON is not set # CONFIG_HWMON_VID is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia Capabilities Port drivers # # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set # CONFIG_VIDEO_SELECT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # # CONFIG_USB_EHCI_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # # CONFIG_USB_STORAGE is not set # CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_ACECAD is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_ITMTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_MON is not set # # USB port drivers # # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_LD is not set # CONFIG_USB_TEST is not set # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # InfiniBand support # # CONFIG_INFINIBAND is not set # # EDAC - error detection and reporting (RAS) (EXPERIMENTAL) # # CONFIG_EDAC is not set # # File systems # # CONFIG_EXT2_FS is not set # CONFIG_EXT3_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_XFS_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_INOTIFY is not set # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y # CONFIG_VFAT_FS is not set CONFIG_FAT_DEFAULT_CODEPAGE=437 # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set CONFIG_CONFIGFS_FS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Instrumentation Support # # CONFIG_PROFILING is not set # CONFIG_KPROBES is not set # # Kernel hacking # # CONFIG_PRINTK_TIME is not set # CONFIG_MAGIC_SYSRQ is not set # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_DEBUG_BUGVERBOSE=y CONFIG_EARLY_PRINTK=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_DES is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_AES_586 is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=m # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # CONFIG_CRYPTO_DEV_PADLOCK is not set # # Library routines # CONFIG_CRC_CCITT=m # CONFIG_CRC16 is not set CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_REED_SOLOMON=y CONFIG_REED_SOLOMON_DEC16=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y From pablo at netfilter.org Sat Oct 7 13:32:09 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sat Oct 7 14:02:11 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <200610061314.16177.alan.ezust@presinet.com> References: <200610031518.10097.alan.ezust@presinet.com> <200610041531.17209.alan.ezust@presinet.com> <4524DD06.50901@netfilter.org> <200610061314.16177.alan.ezust@presinet.com> Message-ID: <45279039.8090309@netfilter.org> Alan Ezust wrote: > On Thursday 05 October 2006 03:23, Pablo Neira Ayuso wrote: >> Alan Ezust wrote: >>> On Wednesday 04 October 2006 15:04, Pablo Neira Ayuso wrote: >>>> Alan Ezust wrote: >>>>> On Wednesday 04 October 2006 12:48, Pablo Neira Ayuso wrote: >>>>>> Alan Ezust wrote: >>>>>>> Hi - i'm trying out the "conntrack" program for my first time. >>>>>>> It compiles and runs, but when I try to do >>>>>>> >>>>>>> conntrack -L conntrack >>>>>>> >>>>>>> it shows me nothing. >>>>>>> >>>>>>> If I cat /proc/net/ip_conntrack I can see lots of log lines there. >>>>>>> Should the conntrack -L conntrack show me pretty much the same thing? >>>>>>> >>>>>>> What's the best way to test that conntrack is working properly? >>>>>> Please check that ip_conntrack_netlink is loaded, old kernel do not >>>>>> load it on demand. >>>>> I'm using kernel 2.6.16.29. >>>>> >>>>> These kernel options are set: >>>>> >>>>> CONFIG_NETFILTER_NETLINK=y >>>>> CONFIG_NETFILTER_NETLINK_QUEUE=y >>>>> CONFIG_NETFILTER_NETLINK_LOG=y >>>>> CONFIG_IP_NF_CONNTRACK_NETLINK=y >>>>> >>>>> Are you saying I should also add a >>>>> CONFIG_IP_CONNTRACK_NETLINK flag in the .config or something else? >>>> No, people usually compile ip_conntrack_netlink as module, and I wanted >>>> to make sure that the module was loaded (modprobe ip_conntrack_netlink) >>>> but since you compiled it built-in. >>> What's the difference between IP_NF_CONNTRACK_NETLINK and >>> IP_CONNTRACK_NETLINK? Are they different modules or is one the new name >>> for the other? >> you're referring to the same thing. This problem that you're observing >> is freak. Please check that ctnetlink is correctly registered. > > On my machine, when I do lsmod, here is the list of modules I have loaded: > > ip_conntrack_netlink 22016 0 > ip_nat 14164 1 ip_conntrack_netlink > ipt_recent 9836 2 > ipt_LOG 5856 4 > ipt_bin 20772 7 > iptable_promisc 1376 1 > ipt_multiport 2112 10 > iptable_filter 2112 1 > ip_tables 10816 2 iptable_promisc,iptable_filter > xt_conntrack 1856 0 > xt_CONNMARK 1824 2 > xt_connmark 1440 2 > xt_pkttype 1440 1 > xt_MARK 2080 0 > xt_state 1536 4 > ipt_psd 43588 1 > ipt_regex 7240 1 > ipt_DATA 3712 5 > ip_conntrack 45996 7 > ip_conntrack_netlink,ip_nat,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state,ipt_DATA > tulip 45152 0 > eepro100 25776 0 > 8139too 20352 0 > 3c59x 38952 0 > 8390 8320 0 > >> # dmesg | grep ctnetlink >> ctnetlink v0.90: registering with nfnetlink. > > Got that - here is my dmesg tail: > > ip_conntrack version 2.4 (2048 buckets, 16384 max) - 252 bytes per conntrack > ipt_regex v0.0.0 > netfilter PSD loaded - (c) astaro AG > ip_conntrack_netlink: Unknown symbol ip_nat_setup_info > ip_conntrack_netlink: Unknown symbol ip_nat_proto_put > ip_conntrack_netlink: Unknown symbol ip_nat_proto_find_get It seems that some symbols are unresolved so ip_conntrack_netlink won't work. See below. >> Send me also your .config file just to have more information. > > attached. > >>>> Could you tell me what version of conntrack/libnetfilter_conntrac are >>>> you using? >>> conntrack 1.00beta2 >>> libnetfilter_conntrack-0.0.31/ >>> libnfnetlink-0.0.16/ >> Please, try with an updated version from netfilter's SVN > > I found an incompatibility in libnfnetlink. Before, I was building on a system > that had 2.6.18 on it, and trying to deploy it on a machine that had kernel > 2.6.16.29. The executable I built didn't do anything. > > Now I am compiling on a system that has the same version (2.6.16.29) of the > kernel as the destination, I am unable to compile the latest (svn as well as > released) versions of libnfnetlink. > > What is the recommended kernel version I should be using, if I want to get > conntrack up and running for my first time? Should I go to 2.6.18 and forget > about 2.6.16.29? lastest includes tons of changes, better upgrade to 2.6.18. > gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libnfnetlink\" -DVERSION=\"0.0.16\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I../include -I/home/ezust/presinet/projects/conntrack/usr/include -fPIC -Wall -I/home/ezust/presinet/projects/conntrack/usr/include -L/home/ezust/presinet/projects/conntrack/usr/lib -MT > libnfnetlink.lo -MD -MP -MF .deps/libnfnetlink.Tpo -c > libnfnetlink.c -fPIC -DPIC -o .libs/libnfnetlink.o > libnfnetlink.c: In function 'nfnl_listen': > libnfnetlink.c:445: error: 'EINTR' undeclared (first use in this function) > libnfnetlink.c:445: error: (Each undeclared identifier is reported only once > libnfnetlink.c:445: error: for each function it appears in.) > libnfnetlink.c:448: error: 'EBADF' undeclared (first use in this function) > libnfnetlink.c:450: error: 'EAGAIN' undeclared (first use in this function) > libnfnetlink.c: In function 'nfnl_talk': > libnfnetlink.c:554: error: 'EINTR' undeclared (first use in this function) > libnfnetlink.c: In function 'nfnl_callback_register': > libnfnetlink.c:878: error: 'EINVAL' undeclared (first use in this function) > libnfnetlink.c: In function 'nfnl_callback_unregister': > libnfnetlink.c:888: error: 'EINVAL' undeclared (first use in this function) > libnfnetlink.c: In function 'nfnl_check_attributes': > libnfnetlink.c:906: error: 'EINVAL' undeclared (first use in this function) > make[1]: *** [libnfnetlink.lo] Error 1 > make[1]: Leaving directory > `/home/ezust/presinet/projects/conntrack-1.00beta2/libnfnetlink-0.0.16/src' Is /usr/include/linux/errno.h available in your system? > thanks again for your help --alan > > > # > # IP: Netfilter Configuration > # > CONFIG_IP_NF_CONNTRACK=m > CONFIG_IP_NF_CT_ACCT=y > CONFIG_IP_NF_CONNTRACK_MARK=y > CONFIG_IP_NF_CONNTRACK_EVENTS=y > CONFIG_IP_NF_CONNTRACK_NETLINK=m ^^^ You told me that you compiled ip_conntrack_netlink built-in? This doesn't match with your previous email... here it appears as module. > # CONFIG_IP_NF_CT_PROTO_SCTP is not set > CONFIG_IP_NF_FTP=m > # CONFIG_IP_NF_IRC is not set > # CONFIG_IP_NF_NETBIOS_NS is not set > # CONFIG_IP_NF_TFTP is not set > # CONFIG_IP_NF_AMANDA is not set > # CONFIG_IP_NF_PPTP is not set > # CONFIG_IP_NF_QUEUE is not set > CONFIG_IP_NF_IPTABLES=m > CONFIG_IP_NF_MATCH_IPRANGE=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_TTL=m > CONFIG_IP_NF_MATCH_OWNER=m > CONFIG_IP_NF_MATCH_ADDRTYPE=m > CONFIG_IP_NF_MATCH_HASHLIMIT=m > CONFIG_IP_NF_MATCH_POLICY=m > CONFIG_IP_NF_FILTER=m > CONFIG_IP_NF_TARGET_REJECT=m > CONFIG_IP_NF_TARGET_LOG=m > # CONFIG_IP_NF_TARGET_ULOG is not set > CONFIG_IP_NF_TARGET_TCPMSS=m > CONFIG_IP_NF_NAT=m ^^^ You forgot to compile built-in NAT support that is required by ip_conntrack_netlink. I think that the best solution is to rebuild your kernel and include all the netfilter netlink subsystems as modules, that will fix your problem. -- 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 davem at davemloft.net Sun Oct 8 06:44:15 2006 From: davem at davemloft.net (David Miller) Date: Sun Oct 8 07:21:01 2006 Subject: [NETFILTER 2.4]: Fix deadlock on NAT helper unload In-Reply-To: <20061007095011.GA2557@1wt.eu> References: <4509C252.6010504@trash.net> <20061007095011.GA2557@1wt.eu> Message-ID: <20061007.214415.74747306.davem@davemloft.net> From: Willy Tarreau Date: Sat, 7 Oct 2006 11:50:11 +0200 > I missed this patch, and it seems David did not notice it either. > David, do you have any objection against it ? Otherwise I will > merge it. No objection, it's been rotting in my mailbox too, sorry: Signed-off-by: David S. Miller From pablo at netfilter.org Mon Oct 9 00:21:43 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Oct 9 00:51:57 2006 Subject: Compiling 1.3.6 In-Reply-To: <00be01c6e977$1ba6bcd0$0101a8c0@pcjorge> References: <00be01c6e977$1ba6bcd0$0101a8c0@pcjorge> Message-ID: <452979F7.9090205@netfilter.org> Hi Patrick, Jorge Bastos wrote: > I was compiling the 1.3.6 version of iptables, agains my 2.6.19-rc1 > kernel version and i get this (it also happens with the final 2.6.18). > Is there some livrary that needs an upgrade or am i missing something? > I already tryed the svn last version and the same happens. min_ip and max_ip type has been changed from u_int32_t to __be32 that is not defined in userspace, this breaks iptables compilation. Attached a patch that recovers the use of u_int32_t. I'm not sure if this is the best fix so let me know what you think. -- 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 -------------- [PATCH] Fix iptables compilation with support for iprange iptables requires ipt_iprange.h that defines max_ip and min_ip as __be32 that is not defined in userspace. Reported by Jorge Bastos. Signed-off-by: Pablo Neira Ayuso Index: net-2.6/include/linux/netfilter_ipv4/ipt_iprange.h =================================================================== --- net-2.6.orig/include/linux/netfilter_ipv4/ipt_iprange.h 2006-10-09 00:15:42.000000000 +0200 +++ net-2.6/include/linux/netfilter_ipv4/ipt_iprange.h 2006-10-09 00:15:55.000000000 +0200 @@ -8,7 +8,7 @@ struct ipt_iprange { /* Inclusive: network order. */ - __be32 min_ip, max_ip; + u_int32_t min_ip, max_ip; }; struct ipt_iprange_info From tomas.mandys at 2p.cz Mon Oct 9 01:13:55 2006 From: tomas.mandys at 2p.cz (Tomas Mandys) Date: Mon Oct 9 01:50:59 2006 Subject: RTP proxy module Message-ID: <200610090113.55438.tomas.mandys@2p.cz> Hi, I'm engaged in SIP router development and now I need improve our current application concerning RTP proxy. SIP call need at least 2 UDP streams (RTP&RTCP) for each session. But problem is when one client is hidden behind the NAT. In this case a RPT proxy is essential. All RTP traffic goes through RTP proxy, in our case it was userspace application but because it need only redirect incomming packets to specified address or learn remote ip/port it's unnecessary copying rtp data between kernel and userspace. So I developed iptables module callled ipt_RTPPROXY+libipt_RTPPROXY that can do it in iptables, i.e. more efficiently. It's different case than connection tracking and NAT. It's not trivial, there is learning and expiration logic. I also developed userspace utils that can alloc, update, delete, list RTP sessions in iptables (using libipt_RTPPROXY). This is actually example how to encapsulate functionality in SIP router. The module is written as patch-o-matic-ng. Is it possible publish in netfilter.org CVS as (currently) experimental module? What procedure must new modules pass to be accepted? Note: I'm asking slightly in advance, not finished yet, I'm going to test. Next to do is HA support. Tomas From glen.turner at aarnet.edu.au Mon Oct 9 05:47:18 2006 From: glen.turner at aarnet.edu.au (Glen Turner) Date: Mon Oct 9 06:25:19 2006 Subject: RTP proxy module In-Reply-To: <200610090113.55438.tomas.mandys@2p.cz> References: <200610090113.55438.tomas.mandys@2p.cz> Message-ID: <4529C646.6050509@aarnet.edu.au> Tomas Mandys wrote: > What procedure must new modules pass to be accepted? Some guidance on this would be appreciated. I've seen no response to my posting of a module on 5 October and I'm not sure if that is a good or a bad thing. Thanks, Glen From kaber at trash.net Mon Oct 9 17:04:28 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 9 17:41:36 2006 Subject: kernel oops in 2.6.17.7 (smp) In-Reply-To: <45260F5A.60700@fliegl.de> References: <45260F5A.60700@fliegl.de> Message-ID: <452A64FC.5060001@trash.net> Deti Fliegl wrote: > Hi there, > > a kernel oops happens since ages with this setup with all recent kernels > (since 2.6.12) - and most probably even with the latest versions. Here > it takes about 60 days to reproduce: > > ---------------------------------------------------------------- > Unable to handle kernel paging request at ffffc2000031d103 RIP: > {:ip_tables:ipt_do_table+194} > PGD 11fc42067 PUD 11fc43067 PMD 11f72b067 PTE 0 > Oops: 0000 [1] SMP > CPU 2 > Modules linked in: ipt_ipp2p ipt_REDIRECT af_packet i8xx_tco xt_CLASSIFY > sch_htb xt_mark xt_CONNMARK ipt_SAME xt_state xt_pkttype xt_NOTRACK > iptable_raw edd ipt_LOG xt_limit ipt_hashlimit xt_tcpudp > ip_conntrack_netlink ip_nat_ftp ip_conntrack_ftp thermal processor fan > button iptable_nat battery ip_nat ac xt_MARK ip_conntrack nfnetlink > iptable_filter iptable_mangle ip_tables x_tables ipmi_si ipmi_devintf > ipmi_msghandler ext3 jbd ide_cd cdrom e1000 piix sg megaraid_mbox > megaraid_mm sd_mod scsi_mod ide_disk ide_core > Pid: 4709, comm: syslog-ng Not tainted 2.6.17.7-smp #1 > RIP: 0010:[] > {:ip_tables:ipt_do_table+194} This should be fixed in the latest 2.6.17-stable kernel. Please try and report in case it still crashes. From netfilter at mm-double.de Mon Oct 9 17:07:50 2006 From: netfilter at mm-double.de (Maik Hentsche) Date: Mon Oct 9 17:45:03 2006 Subject: [PATCH] libnfnetlink Message-ID: <1160406470.452a65c62a14c@www.domainfactory-webmail.de> Hallo pablo, hello readers of the list, attached is a patch, that corrects another error in the comments of libnfnetlink. nfnl_send uses send_to and thus returns the number of send bytes instead of 0 in case of success. Pardon me for bothering you with such trivial patches, but I think, as long as the sgml-documentation isn't finished (I'm working on it), developers using the lib might need those comments. so long Maik -------------- next part -------------- A non-text attachment was scrubbed... Name: libnfnetlink_send_comment.patch Type: text/x-patch Size: 672 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061009/ed08ae23/libnfnetlink_send_comment.bin From kaber at trash.net Mon Oct 9 17:12:10 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 9 17:49:17 2006 Subject: [PATCH] Add TCPCONG target to patch-o-matic In-Reply-To: <4524BBB2.2000109@aarnet.edu.au> References: <45235EDC.4080709@aarnet.edu.au> <4524118B.4020903@netfilter.org> <4524BBB2.2000109@aarnet.edu.au> Message-ID: <452A66CA.70603@trash.net> Glen Turner wrote: > > Hi folks, > > I have created a kernel module and iptables shared library > to allow netfilter to set the TCP congestion control > algorithm. > > This has three major uses: selecting differing algorithms > for wired and non-wired interfaces; selecting differing > algorithms for close and far hosts; and selecting differing > algorithms for comparison testing. > > Thanks to the hint from Pablo Neira Ayuso I have put this > into the patch-o-matic format. This has been tested against > iptables-1.3.6 and linux-2.6.18. > > A SVN diff against patch-o-matic follows, which I'm hoping > Thunderbird doesn't mangle. Since I'm not familiar with SVN > please let me know if this isn't the desired patch format. > > I would hope that this facility can become a standard part of > the kernel and iptables. Please let me know what I need to > do to follow that path. I don't think iptables is the right place to do this. It should be controllable through routing IMO (which can already control some aspects of congestion control). From pablo at netfilter.org Mon Oct 9 17:14:51 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Oct 9 17:50:27 2006 Subject: [PATCH] libnfnetlink In-Reply-To: <1160406470.452a65c62a14c@www.domainfactory-webmail.de> References: <1160406470.452a65c62a14c@www.domainfactory-webmail.de> Message-ID: <452A676B.80808@netfilter.org> Maik, Maik Hentsche wrote: > Hallo pablo, hello readers of the list, > attached is a patch, that corrects another error in the comments of > libnfnetlink. nfnl_send uses send_to and thus returns the number of > send bytes instead of 0 in case of success. Pardon me for bothering you > with such trivial patches, but I think, as long as the > sgml-documentation isn't finished (I'm working on it), developers using > the lib might need those comments. Thanks it is worth the fix, I'll add it to my patchlet for libnfnetlink. -- The dawn of the fourth age of Linux firewalling is coming; a time of great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris From kaber at trash.net Mon Oct 9 17:23:01 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 9 18:00:09 2006 Subject: Compiling 1.3.6 In-Reply-To: <452979F7.9090205@netfilter.org> References: <00be01c6e977$1ba6bcd0$0101a8c0@pcjorge> <452979F7.9090205@netfilter.org> Message-ID: <452A6955.6020100@trash.net> Pablo Neira Ayuso wrote: > min_ip and max_ip type has been changed from u_int32_t to __be32 that is > not defined in userspace, this breaks iptables compilation. Attached a > patch that recovers the use of u_int32_t. I'm not sure if this is the > best fix so let me know what you think. I think we should just define the endian-annotation types in userspace. Does this patch fix compilation? -------------- next part -------------- Index: include/iptables_common.h =================================================================== --- include/iptables_common.h (Revision 6660) +++ include/iptables_common.h (Arbeitskopie) @@ -42,4 +42,9 @@ extern void init_extensions(void); #endif +#define __be32 u_int32_t +#define __le32 u_int32_t +#define __be16 u_int16_t +#define __le16 u_int16_t + #endif /*_IPTABLES_COMMON_H*/ From kaber at trash.net Mon Oct 9 17:24:35 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 9 18:01:44 2006 Subject: iptables won't compile in a debug turned on In-Reply-To: <4524E03C.6070003@netfilter.org> References: <1159989997.28977.166.camel@mfarooq-1.tango-networks.com> <4524E03C.6070003@netfilter.org> Message-ID: <452A69B3.80802@trash.net> Pablo Neira Ayuso wrote: > Mohammad Farooq wrote: > >>Are you guys aware of that is in the iptables-1.3.6/Makefile if turn on >>debugging: >>CFLAGS:=$(COPT_FLAGS) -Wall -Wunused -I$(KERNEL_DIR)/include -Iinclude/ >>-DIPTABLES_VERSION=\"$(IPTABLES_VERSION)\" -g -DDEBUG -pg -DIPTC_DEBUG >>the compile will fail. >> >>MF >> >>libiptc/libip6tc.c: In function `do_check': >>libiptc/libip6tc.c:284: warning: implicit declaration of function >>`get_chain_end' >>libiptc/libip6tc.c:285: warning: implicit declaration of function >>`get_entry' >>[...] > > > I didn't notice, it seems that nobody has been using it for quite some > time. I'm not sure if it is worth fixing this. I would certainly accept a patch to fix this, but I don't think its very important. From pablo at netfilter.org Mon Oct 9 17:36:54 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Oct 9 18:12:29 2006 Subject: Compiling 1.3.6 In-Reply-To: <452A6955.6020100@trash.net> References: <00be01c6e977$1ba6bcd0$0101a8c0@pcjorge> <452979F7.9090205@netfilter.org> <452A6955.6020100@trash.net> Message-ID: <452A6C96.2070102@netfilter.org> Patrick McHardy wrote: > Pablo Neira Ayuso wrote: > >>min_ip and max_ip type has been changed from u_int32_t to __be32 that is >>not defined in userspace, this breaks iptables compilation. Attached a >>patch that recovers the use of u_int32_t. I'm not sure if this is the >>best fix so let me know what you think. > > > I think we should just define the endian-annotation types in userspace. > Does this patch fix compilation? But this breaks previous iptables version with new kernels :(. An alternative can be exporting ipt_iprange.h to iptables/include although this is also a hack. -- 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 Oct 9 17:44:53 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon Oct 9 18:20:28 2006 Subject: Compiling 1.3.6 In-Reply-To: <452A6C96.2070102@netfilter.org> References: <00be01c6e977$1ba6bcd0$0101a8c0@pcjorge> <452979F7.9090205@netfilter.org> <452A6955.6020100@trash.net> <452A6C96.2070102@netfilter.org> Message-ID: <452A6E75.2030700@netfilter.org> Pablo Neira Ayuso wrote: > Patrick McHardy wrote: > >> Pablo Neira Ayuso wrote: >> >>> min_ip and max_ip type has been changed from u_int32_t to __be32 that is >>> not defined in userspace, this breaks iptables compilation. Attached a >>> patch that recovers the use of u_int32_t. I'm not sure if this is the >>> best fix so let me know what you think. >> >> >> >> I think we should just define the endian-annotation types in userspace. >> Does this patch fix compilation? > > > But this breaks previous iptables version with new kernels :(. An > alternative can be exporting ipt_iprange.h to iptables/include although > this is also a hack. Forget the alternative, it won't work either -- 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 pupilla at hotmail.com Mon Oct 9 17:58:34 2006 From: pupilla at hotmail.com (Marco Berizzi) Date: Mon Oct 9 18:35:48 2006 Subject: Compiling 1.3.6 In-Reply-To: <452A6E75.2030700@netfilter.org> Message-ID: Pablo Neira Ayuso wrote: >Pablo Neira Ayuso wrote: >>Patrick McHardy wrote: >> >>>Pablo Neira Ayuso wrote: >>> >>>>min_ip and max_ip type has been changed from u_int32_t to __be32 that is >>>>not defined in userspace, this breaks iptables compilation. I'm able to compile iptables 1.3.6 with 2.6.18 kernel headers without any errors. However iptables 1.3.6 + linux 2.6.19-rc1 kernel headers give me this error: cc -O2 -Wall -Wunused -I/usr/src/linux/include -Iinclude/ -DIPTABLES_VERSION=\"1.3.6\" -fPIC -o extensions/libipt_iprange_sh.o -c exte nsions/libipt_iprange.c In file included from extensions/libipt_iprange.c:9: /usr/src/linux/include/linux/netfilter_ipv4/ipt_iprange.h:11: error: syntax error before "__be32" /usr/src/linux/include/linux/netfilter_ipv4/ipt_iprange.h:11: warning: no semicolon at end of struct or union /usr/src/linux/include/linux/netfilter_ipv4/ipt_iprange.h:16: error: field `src' has incomplete type /usr/src/linux/include/linux/netfilter_ipv4/ipt_iprange.h:17: error: field `dst' has incomplete type extensions/libipt_iprange.c: In function `parse_iprange': extensions/libipt_iprange.c:43: error: dereferencing pointer to incomplete type extensions/libipt_iprange.c:50: error: dereferencing pointer to incomplete type extensions/libipt_iprange.c:52: error: dereferencing pointer to incomplete type extensions/libipt_iprange.c:52: error: dereferencing pointer to incomplete type extensions/libipt_iprange.c: In function `print_iprange': extensions/libipt_iprange.c:116: error: dereferencing pointer to incomplete type extensions/libipt_iprange.c:117: error: dereferencing pointer to incomplete type make: *** [extensions/libipt_iprange_sh.o] Error 1 My env: Slackware Linux 11.0 Linux Calimero 2.6.19-rc1 #1 PREEMPT Thu Oct 5 15:26:06 CEST 2006 i686 pentium3 i386 GNU/Linux Gnu C 3.4.6 Gnu make 3.81 binutils 2.15.92.0.2 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.38 Linux C Library 2.3.6 Dynamic linker (ldd) 2.3.6 Linux C++ Library 6.0.3 Procps 3.2.7 Net-tools 1.60 Kbd 1.12 Sh-utils 5.97 From kaber at trash.net Mon Oct 9 18:02:14 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 9 18:39:24 2006 Subject: Compiling 1.3.6 In-Reply-To: <452A6C96.2070102@netfilter.org> References: <00be01c6e977$1ba6bcd0$0101a8c0@pcjorge> <452979F7.9090205@netfilter.org> <452A6955.6020100@trash.net> <452A6C96.2070102@netfilter.org> Message-ID: <452A7286.3080403@trash.net> Pablo Neira Ayuso wrote: > Patrick McHardy wrote: > >> Pablo Neira Ayuso wrote: >> >>> min_ip and max_ip type has been changed from u_int32_t to __be32 that is >>> not defined in userspace, this breaks iptables compilation. Attached a >>> patch that recovers the use of u_int32_t. I'm not sure if this is the >>> best fix so let me know what you think. >> >> >> >> I think we should just define the endian-annotation types in userspace. >> Does this patch fix compilation? > > > But this breaks previous iptables version with new kernels :(. An > alternative can be exporting ipt_iprange.h to iptables/include although > this is also a hack. We should consider moving away from using the kernel headers directly. Breaking compilation of old iptables versions is not too bad IMO, old binaries will still work and someone compiling old iptables with a new kernel can just as well just compile a new version. Unfortunately 1.3.6 won't compile with 2.6.19, so we might have to put out a new version soon. From kaber at trash.net Mon Oct 9 18:02:49 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 9 18:39:56 2006 Subject: Compiling 1.3.6 In-Reply-To: References: Message-ID: <452A72A9.4060800@trash.net> Marco Berizzi wrote: > Pablo Neira Ayuso wrote: > >> Pablo Neira Ayuso wrote: >> >>> Patrick McHardy wrote: >>> >>>> Pablo Neira Ayuso wrote: >>>> >>>>> min_ip and max_ip type has been changed from u_int32_t to __be32 >>>>> that is >>>>> not defined in userspace, this breaks iptables compilation. > > > I'm able to compile iptables 1.3.6 with 2.6.18 kernel > headers without any errors. > However iptables 1.3.6 + linux 2.6.19-rc1 kernel > headers give me this error: Does the patch I just sent fix it? From pupilla at hotmail.com Mon Oct 9 18:10:56 2006 From: pupilla at hotmail.com (Marco Berizzi) Date: Mon Oct 9 18:48:04 2006 Subject: Compiling 1.3.6 In-Reply-To: <452A72A9.4060800@trash.net> Message-ID: Patrick McHardy wrote: >Marco Berizzi wrote: > > Pablo Neira Ayuso wrote: > > > >> Pablo Neira Ayuso wrote: > >> > >>> Patrick McHardy wrote: > >>> > >>>> Pablo Neira Ayuso wrote: > >>>> > >>>>> min_ip and max_ip type has been changed from u_int32_t to __be32 > >>>>> that is > >>>>> not defined in userspace, this breaks iptables compilation. > > > > > > I'm able to compile iptables 1.3.6 with 2.6.18 kernel > > headers without any errors. > > However iptables 1.3.6 + linux 2.6.19-rc1 kernel > > headers give me this error: > >Does the patch I just sent fix it? Yes, now I'm able to compile iptables 1.3.6 with 2.6.19-rc1 kernel headers with your patch: Index: include/iptables_common.h =================================================================== --- include/iptables_common.h (Revision 6660) +++ include/iptables_common.h (Arbeitskopie) @@ -42,4 +42,9 @@ extern void init_extensions(void); #endif +#define __be32 u_int32_t +#define __le32 u_int32_t +#define __be16 u_int16_t +#define __le16 u_int16_t + #endif /*_IPTABLES_COMMON_H*/ From kaber at trash.net Mon Oct 9 19:23:31 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 9 20:24:04 2006 Subject: Compiling 1.3.6 In-Reply-To: References: Message-ID: <452A8593.6030003@trash.net> Marco Berizzi wrote: > Patrick McHardy wrote: > >> Does the patch I just sent fix it? > > > Yes, now I'm able to compile iptables 1.3.6 with 2.6.19-rc1 > kernel headers with your patch: Thanks, I've committed it to SVN. From eric at inl.fr Mon Oct 9 22:03:59 2006 From: eric at inl.fr (Eric Leblond) Date: Mon Oct 9 22:41:05 2006 Subject: [Announce] pynetfilter_conntrack, a Python binding of libnetfilter_conntrack Message-ID: <1721.83.156.14.82.1160424239.squirrel@mail.inl.fr> Hi, INL development team is proud to announce the availability of pynetfilter_conntrack. pynetfilter_conntrack is a Python binding of libnetfilter_conntrack. The binding is the file pynetfilter_conntrack.py and you have also a clone of conntrack program: conntrack.py. It provides a high level API for libnetfilter_conntrack. For example, you can display all TCP connections with destination port 22 by doing something like : nf = NetfilterConntrack(CONNTRACK) table = nf.create_table(IPV4) table = table.filter(6,dport=22) table.display() The current release of pynetfilter_conntrack supports listing, modification and deletion of conntrack entries. pynetfilter_conntrack has been developped by Victor Stinner aka Haypo. It is released under GPL by INL. pynetfilter_conntrack : http://software.inl.fr/trac/trac.cgi/wiki/pynetfilter_conntrack INL : http://www.inl.fr/ BR, -- Eric Leblond INL : http://www.inl.fr NuFW, Now User Filtering Works (http://www.nufw.org) From pablo at netfilter.org Tue Oct 10 03:10:22 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Oct 10 03:40:36 2006 Subject: [CTNETLINK] Fix compilation with debugging enabled Message-ID: <452AF2FE.1050606@netfilter.org> Two debugging messages inside dump_table refer to variable `id' that is not declared anymore. Signed-off-by: Pablo Neira Ayuso -- 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 -------------- [CTNETLINK] Fix compilation with debugging enabled two debugging messages inside dump_table refer to variable `id' that is not declared anymore. Signed-off-by: Pablo Neira Ayuso Index: net-2.6/net/ipv4/netfilter/ip_conntrack_netlink.c =================================================================== --- net-2.6.orig/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-10-10 03:00:00.000000000 +0200 +++ net-2.6/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-10-10 03:01:36.000000000 +0200 @@ -411,8 +411,7 @@ ctnetlink_dump_table(struct sk_buff *skb struct ip_conntrack_tuple_hash *h; struct list_head *i; - DEBUGP("entered %s, last bucket=%lu id=%u\n", __FUNCTION__, - cb->args[0], *id); + DEBUGP("entered %s, last bucket=%lu\n", __FUNCTION__, cb->args[0]); read_lock_bh(&ip_conntrack_lock); last = (struct ip_conntrack *)cb->args[1]; @@ -452,7 +451,7 @@ out: if (last) ip_conntrack_put(last); - DEBUGP("leaving, last bucket=%lu id=%u\n", cb->args[0], *id); + DEBUGP("leaving, last bucket=%lu\n", cb->args[0]); return skb->len; } Index: net-2.6/net/netfilter/nf_conntrack_netlink.c =================================================================== --- net-2.6.orig/net/netfilter/nf_conntrack_netlink.c 2006-10-10 03:02:35.000000000 +0200 +++ net-2.6/net/netfilter/nf_conntrack_netlink.c 2006-10-10 03:03:29.000000000 +0200 @@ -425,8 +425,7 @@ ctnetlink_dump_table(struct sk_buff *skb struct nfgenmsg *nfmsg = NLMSG_DATA(cb->nlh); u_int8_t l3proto = nfmsg->nfgen_family; - DEBUGP("entered %s, last bucket=%lu id=%u\n", __FUNCTION__, - cb->args[0], *id); + DEBUGP("entered %s, last bucket=%lu\n", __FUNCTION__, cb->args[0]); read_lock_bh(&nf_conntrack_lock); last = (struct nf_conn *)cb->args[1]; @@ -471,7 +470,7 @@ out: if (last) nf_ct_put(last); - DEBUGP("leaving, last bucket=%lu id=%u\n", cb->args[0], *id); + DEBUGP("leaving, last bucket=%lu\n", cb->args[0]); return skb->len; } From kaber at trash.net Tue Oct 10 06:46:51 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 10 07:24:05 2006 Subject: [CTNETLINK] Fix compilation with debugging enabled In-Reply-To: <452AF2FE.1050606@netfilter.org> References: <452AF2FE.1050606@netfilter.org> Message-ID: <452B25BB.6020909@trash.net> Pablo Neira Ayuso wrote: > Two debugging messages inside dump_table refer to variable `id' > that is not declared anymore. Are you actually using the debugging stuff? Most of the ctnetlink debugging looks like a leftover from early development, so unless you think its still useful, I would prefer to remove it entirely since it makes the code less readable IMO. From kaber at trash.net Tue Oct 10 06:59:19 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 10 07:36:28 2006 Subject: RTP proxy module In-Reply-To: <200610090113.55438.tomas.mandys@2p.cz> References: <200610090113.55438.tomas.mandys@2p.cz> Message-ID: <452B28A7.1090307@trash.net> Tomas Mandys wrote: > I'm engaged in SIP router development and now I need improve our current > application concerning RTP proxy. SIP call need at least 2 UDP streams > (RTP&RTCP) for each session. But problem is when one client is hidden behind > the NAT. In this case a RPT proxy is essential. All RTP traffic goes through > RTP proxy, in our case it was userspace application but because it need only > redirect incomming packets to specified address or learn remote ip/port it's > unnecessary copying rtp data between kernel and userspace. So I developed > iptables module callled ipt_RTPPROXY+libipt_RTPPROXY that can do it in > iptables, i.e. more efficiently. It's different case than connection tracking > and NAT. It's not trivial, there is learning and expiration logic. > > I also developed userspace utils that can alloc, update, delete, list RTP > sessions in iptables (using libipt_RTPPROXY). This is actually example how to > encapsulate functionality in SIP router. How is this different from the SIP conntrack/NAT helper, which can deal (well, not entirely yet) with clients behind NAT as well? > The module is written as patch-o-matic-ng. > Is it possible publish in netfilter.org CVS as (currently) experimental > module? What procedure must new modules pass to be accepted? We currently only accept patches for patch-o-matic that we have an interest in maintaining ourselves (in case the author disappears, which happens regulary). The two other possibilities are external patch-o-matic repositories and/or an account on people.netfilter.org if you just need some webspace to publish it. From kaber at trash.net Tue Oct 10 07:04:50 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 10 07:42:00 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel In-Reply-To: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> References: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> Message-ID: <452B29F2.70105@trash.net> Nishit Shah wrote: > Hi, > During my load testing on kernel 2.6.16.13 i got following kernel > oops. It occures when I enable SNAT or MASQUERADE for all outgoing traffic, > with ACCEPT load testing works fine for me. How exactly did you perform this testing? Did you loaded and unloaded modules, or just loaded them? How many entries does the connection tracking table have at the time? From kaber at trash.net Tue Oct 10 06:38:45 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 10 07:47:25 2006 Subject: [NETFILTER 00/05]: Small netfilter update In-Reply-To: <20061002.161344.92582699.davem@davemloft.net> References: <20061002154716.13121.53265.sendpatchset@localhost.localdomain> <20061002.161344.92582699.davem@davemloft.net> Message-ID: <452B23D5.3020704@trash.net> David Miller wrote: > Please submit the bug fixes as you see fit to -stable, in particular > I'd like to see the Kconfig dependency fix go to 2.6.18-stable. You > can use this signoff line for any of those patches when submitting > to -stable, thanks: > > Signed-off-by: David S. Miller Thanks, I'll push the first three patches today or tomorrow along with a few backports from my last patchset. From kaber at trash.net Tue Oct 10 07:20:26 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 10 07:57:35 2006 Subject: nfq_set_verdict_mark In-Reply-To: <4521284C.2070000@netfilter.org> References: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> <4521284C.2070000@netfilter.org> Message-ID: <452B2D9A.7080702@trash.net> Pablo Neira Ayuso wrote: > Robert Scott wrote: > >>i noticed that this function doesn't automatically convert the mark into >>the expected network byte order. this is a minor detail, but the >>current behavior may confuse users. since nfq_get_nfmark automatically >>converts the mark into host order, i thought nfq_set_verdict_mark would >>also do the reverse. >> >>not really a big deal, and this will probably break most existing >>installations in the field, but perhaps a note in the docs to give new >>users a heads up. > > > Yes, I agree what you, we have to document this minor issue, I think > that we can introduce more API that can solve this inconsistency. Do we actually have documentation where we can document it? :) I'm beginning to wonder how much more kludges we will have in these libraries by continuing to treat them as stable without having had even a single beta version. From nishit at elitecore.com Tue Oct 10 07:50:14 2006 From: nishit at elitecore.com (Nishit Shah) Date: Tue Oct 10 08:19:39 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel References: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> <452B29F2.70105@trash.net> Message-ID: <02a901c6ec2f$f5d1e730$4c01a8c0@elitecore26> I have performed load testing through Spirent avalanche.(Test Specification is Connections/Second). At one side of testing machine, there are 10/11 virtual clients created by Spirent and 4/5 virtual servers at other side. Testing is through HTTP 1.0 with heep alive and 1024 bytes of object size. I haven't loaded or unloaded any modules.. I have loaded conntrack module with following parameters. modprobe conntrack hashsize=262144 echo 1048576 > /proc/sys/net/ipv4/ip_conntrack_max (Testing machines contain >= 1 GB of RAM and those were plain firewall only machines.) Connection rate is around 4000 Connections/Second at the time of oops and around 3,00,000 connection entries at time of oops. Also, some of my observations, I don't think problem is with connection rate, problem is with number of connection entries. I have tried with different machines but every time i got kernel oops at 3,00,000 entries in conntrack table.(tried with Pentium 4,Xeon,Xeon duel etc..) Also, this oops is in 2.6.16.13 vanila as well as 2.6.16.13smp vanila both. May be this information will help you...... Regards, Nishit Shah. ----- Original Message ----- From: "Patrick McHardy" To: "Nishit Shah" Cc: Sent: Tuesday, October 10, 2006 10:34 AM Subject: Re: kernel oops with NAT in 2.6.16.13 kernel > Nishit Shah wrote: > > Hi, > > During my load testing on kernel 2.6.16.13 i got following kernel > > oops. It occures when I enable SNAT or MASQUERADE for all outgoing traffic, > > with ACCEPT load testing works fine for me. > > How exactly did you perform this testing? Did you loaded and unloaded > modules, or just loaded them? How many entries does the connection > tracking table have at the time? > > > From kaber at trash.net Tue Oct 10 08:01:18 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 10 08:38:30 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel In-Reply-To: <02a901c6ec2f$f5d1e730$4c01a8c0@elitecore26> References: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> <452B29F2.70105@trash.net> <02a901c6ec2f$f5d1e730$4c01a8c0@elitecore26> Message-ID: <452B372E.3020206@trash.net> Nishit Shah wrote: > I have performed load testing through Spirent avalanche.(Test Specification > is Connections/Second). > At one side of testing machine, there are 10/11 virtual clients created by > Spirent and 4/5 virtual servers at other side. > Testing is through HTTP 1.0 with heep alive and 1024 bytes of object size. > I haven't loaded or unloaded any modules.. > I have loaded conntrack module with following parameters. > modprobe conntrack hashsize=262144 > echo 1048576 > /proc/sys/net/ipv4/ip_conntrack_max > (Testing machines contain >= 1 GB of RAM and those were plain firewall only > machines.) > Connection rate is around 4000 Connections/Second at the time of oops and > around 3,00,000 connection entries at time of oops. > > Also, some of my observations, > I don't think problem is with connection rate, problem is with number of > connection entries. > I have tried with different machines but every time i got kernel oops at > 3,00,000 entries in conntrack table.(tried with Pentium 4,Xeon,Xeon duel > etc..) With many conntrack entries NAT may take considerable time to find a free tuple (up to ~64000 quite expensive hash lookups). For optimal performance, the hash should be twice as large as the maximum number of entries. I assume the machine doesn't freeze completely but just reports a softlockup? Are you running anything touching conntrack /proc-files during this test? From nishit at elitecore.com Tue Oct 10 08:28:00 2006 From: nishit at elitecore.com (Nishit Shah) Date: Tue Oct 10 08:57:04 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel References: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> <452B29F2.70105@trash.net> <02a901c6ec2f$f5d1e730$4c01a8c0@elitecore26> <452B372E.3020206@trash.net> Message-ID: <02d001c6ec35$3bf7b870$4c01a8c0@elitecore26> Yes, machine was not completely freezed up, soft lockup is there. I havent' touch any /proc files during the test. I am using, cat /proc/slabinfo | grep conntrack for number of conntrack entries, vmstat 2 for CPU usage (one through telnet and one through serial console..) Also, from vmstat one more observation is at time of 4000 Connections/Sec, system is taking 30 to 35% CPU and suddenly it boosts to 100% and machine got hang up and same time if i stop the test, machine will start responding.. Also, have done tests for following parameters but i got oops for all of them !!!! hashsize=1048576 ip_conntrack_max=1048576 (ip_conntrack_max = hashsize * 1) hashsize=262144 ip_conntrack_max=1048576 (ip_conntrack_max = hashsize * 4) hashsize=262144 ip_conntrack_max=2097152 (ip_conntrack_max = hashsize * 8) Only missed your hashsize * 2 test case !!!! Few more results that will help you, Test Connections/Sec Vanila Kernel 24000 Only conntrack loaded 22000 Conntrack + NAT module loaded(but no MASQ or SNAT rule in iptables) 20000-21000 Conntrack + NAT module loaded(MASQ or SNAT rule in iptables) 4000 (oops) Regards, Nishit Shah. ----- Original Message ----- From: "Patrick McHardy" To: "Nishit Shah" Cc: Sent: Tuesday, October 10, 2006 11:31 AM Subject: Re: kernel oops with NAT in 2.6.16.13 kernel > Nishit Shah wrote: > > I have performed load testing through Spirent avalanche.(Test Specification > > is Connections/Second). > > At one side of testing machine, there are 10/11 virtual clients created by > > Spirent and 4/5 virtual servers at other side. > > Testing is through HTTP 1.0 with heep alive and 1024 bytes of object size. > > I haven't loaded or unloaded any modules.. > > I have loaded conntrack module with following parameters. > > modprobe conntrack hashsize=262144 > > echo 1048576 > /proc/sys/net/ipv4/ip_conntrack_max > > (Testing machines contain >= 1 GB of RAM and those were plain firewall only > > machines.) > > Connection rate is around 4000 Connections/Second at the time of oops and > > around 3,00,000 connection entries at time of oops. > > > > Also, some of my observations, > > I don't think problem is with connection rate, problem is with number of > > connection entries. > > I have tried with different machines but every time i got kernel oops at > > 3,00,000 entries in conntrack table.(tried with Pentium 4,Xeon,Xeon duel > > etc..) > > With many conntrack entries NAT may take considerable time to find a > free tuple (up to ~64000 quite expensive hash lookups). For optimal > performance, the hash should be twice as large as the maximum number > of entries. I assume the machine doesn't freeze completely but > just reports a softlockup? Are you running anything touching conntrack > /proc-files during this test? > > > > > From glen.turner at aarnet.edu.au Tue Oct 10 09:00:34 2006 From: glen.turner at aarnet.edu.au (Glen Turner) Date: Tue Oct 10 09:38:45 2006 Subject: [PATCH] Add TCPCONG target to patch-o-matic In-Reply-To: <452A66CA.70603@trash.net> References: <45235EDC.4080709@aarnet.edu.au> <4524118B.4020903@netfilter.org> <4524BBB2.2000109@aarnet.edu.au> <452A66CA.70603@trash.net> Message-ID: <452B4512.4070705@aarnet.edu.au> Patrick McHardy wrote: > I don't think iptables is the right place to do this. It should > be controllable through routing IMO (which can already control > some aspects of congestion control). I too think the choice should usually be done through routing, with the route holding the preferred congestion control algorithm for traffic with that prefix. Whereas now the preferred algorithm is read from a global parameter. But the algorithm for a particular connection should still be able to be changed through iptables. Firstly, not every application can be easily altered to use setsockopt() to select a differing algorithm from the default. This is the argument used for the TCPMSS and similar targets. As the range of congestion control algorithms grows sysadmins will want to choose differing algorithms for differing applications. For example, most algorithm's Ack strategies interact poorly with transactional and remote procedure call traffic, so choosing an algorithm which handles this well could make, say, NFS over TCP traffic run a lot faster. Secondly, I want to make it easy for kernel and protocol developers to run differing algorithms on differing port numbers to test inter-algorithm fairness. Some TCP algorithms are quite unfair -- unable even to share a link 50:50 between two identical flows started a few seconds apart. A TCPCONG target makes it much easier to do this testing. Now that the kernel developers are getting good performance on long fat pipes the fairness and other attributes of that performance will be their next concern. Hope this helps, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au From tomas.mandys at 2p.cz Tue Oct 10 09:51:01 2006 From: tomas.mandys at 2p.cz (Tomas Mandys) Date: Tue Oct 10 10:28:47 2006 Subject: RTP proxy module In-Reply-To: <452B28A7.1090307@trash.net> Message-ID: <016601c6ec40$d693a460$1401a8c0@nyala> > How is this different from the SIP conntrack/NAT helper, > which can deal > (well, not entirely yet) with clients behind NAT as well? There is dedicated port range for RTP proxy, let's say 2000 ports, so 500 simultaneous calls may "processed" at one moment. One port for RTP, second RTCP and both for each clients. Note data comming from opposite direction are engaged in different conntrack (6666->3000, 9000->3002) and 2 related streams are related each other (RTP, RTCP) Implementation via mangler, iptRTPPROXY changes in IP_PRE_ROUTING callback destination (e.g.9000) address to route correctly, IP_POST_CALLBACK rewrites source address (e.g.3002). There are more features, like timeouts, statistics etc. RTP session allocation is driven by SIP router via libipt_RTPPROXY. Because RTP stream are specified apart from SIP RTP proxy does not know anything about Call-id,fromtag,totag but only session-id. SIP router is responsible from connecting them. SIP is mentioned here as example (I need it for SIP). Here is simplified scenario (no STUN) +-------------+ +---------------+ +------------+ SIP(UDP/TCP) +-------------+ | SIP phone | | NAT box | --->| SIP router |<---------- | SIP phone | | UE#1 | | translates: | / | 2.3.4.5 | \ | UE#2 | | 192.168.1.1 |<---->| >1.2.3.4:6050 |<----- +------------+ ----->| 8.9.10.11 | | signalling | | | ^ | signalling | | port:5060 | | | |via libipt | port:5060 | | | | | v | | | | | | +------------------+ | | | | | | | lib_RTPPROXY | | | | | | | | RTP proxy in ipt | | | | | | | | 2.3.4.5 | | | | streaming | | | UDP | | | streaming | | RTP: 6000 |<---->| >1.2.3.4:6666 |<--------->| 3000<-- | | | | RTCP:6001 |<---->| >1.2.3.4:8888 |<--------->| 3001<- \ | UDP | | | | | | | \ ->3002 |<---------->| RTP: 9000 | | | | | | -->3003 |<---------->| RTCP:9001 | +-------------+ +---------------+ | 3004 | +-------------+ | 3005 | | 3006 | | 3007 | | 3008 | | | | .... | | | | .... | | | | 4000 | | | | | +------------------+ 1) UE#1 initiates call INVITE sip:ue2 Via: 192.168.1.1 Call-id: zxcvb From: ;tag=123456 To: Contact: Content-type: application/sdp c=IN IP4 192.168.1.1 m=audio 6000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 2) sip router recognezes that UE behind NAT because Via!=dest address (1.2.3.4:6050). SIP need rewrite SIP message (it can do SIP signalling NAT stuff by itself) and need also rewrite SDP (note here when only one UE behind NAT it's RTP proxy not absolutely necessary). 2a) sip router demands one RTP session allocation at RTP proxy. RTP proxy allocates one quad and returns port number. 2b) SIP router rewrites SIP message (Contact and SDP) and sends to UE2 INVITE sip:ue2 Via: 2.3.4.5;received=1.2.3.5;rport=6050 UDP Via: 192.168.1.1 UDP Call-id: zxcvb From: ;tag=123456 To: Contact: Content-type: application/sdp c=IN IP4 2.3.4.5 m=audio 3002 RTP/AVP 0 a=rtpmap:0 PCMU/8000 3) UE2 pick up phone SIP 200 OK Via: 2.3.4.5;received=1.2.3.5;rport=6050 UDP Via: 192.168.1.1 UDP Call-id: zxcvb From: ;tag=123456 To: ;tag=456788 Contact: Content-type: application/sdp c=IN IP4 8.9.10.11 m=audio 9000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 4) sip router rewrites reply (SDP) and tell RTP proxy remote address of UE#2 (RTP proxy may now traverse UDP streams) - note that autolerning of remote ip/port is supported, e.g. to learn 2.3.4.5:6666/8888 SIP 200 OK Via: 192.168.1.1 UDP Call-id: zxcvb From: ;tag=123456 To: ;tag=456788 Contact: Content-type: application/sdp c=IN IP4 2.3.4.5 m=audio 3000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 5) finally, UE#1 can send RTP data do 2.3.4.5:3000/3001 and UE2 to 2.3.4.5:3002/3003 6) when BYE arrives then RTP session is deallocated > We currently only accept patches for patch-o-matic that we have an > interest in maintaining ourselves (in case the author disappears, > which happens regulary). The two other possibilities are external > patch-o-matic repositories and/or an account on people.netfilter.org > if you just need some webspace to publish it. Maybe a link from netfilter.org to a separate sourceforge/berlios is OK when you are not interested. Tomas From netfilter at mm-double.de Tue Oct 10 14:55:58 2006 From: netfilter at mm-double.de (Maik Hentsche) Date: Tue Oct 10 15:33:22 2006 Subject: libnfnetlink Docu Message-ID: <1160484958.452b985e8598c@www.domainfactory-webmail.de> Hi Pablo, hello readers of the list, as already promised, I wrote a small documentation on libnfnetlink (based on version 0.0.16-pablo-r1). It has now reached a state, where I dare showing it (see attached). There are some points still missing: * nfnl_sendmsg, nfnl_sendiov - may come in the next revision * get message_first and _next - I'm working out the difference to the iterator API at the moment, it will therefore definitely be in one of the next revisions. * attributes - will definitely be in one of the next revisions * _step, _is_error, _handle_[msg|packet] - are they intended for public use or internal functions of the lib (that should not occur in the docu)? There are two different ways of joining multicast groups. nfnl_join, that uses setsockopt and recalc_rebind_subscriptions (used by nfnl_subsys_open), that uses bind. I think, this difference should be mentioned in the docu, but I don't see, why it is needed. As far, as I see it atm, only nfnl_join (because of its more understandable name, with whatever interface is better) should be used and shoud set nfnlh->subscriptions, what it does not do atm. The last point, I want to mention is the use of nfnl_handle *h in nfnl_iterator_create and nfnl_iterator_next. They both don't use the handle, so wouldn't it be better to remove it from their argument list? I wonder how many existing implementations using libnfnetlink would break. I assume, it would only be the subsystem libraries, which can be changed relatively easy. I ask you to please provide comments on my paper. It was made with the goal of making the official documentation of the lib one day in mind ;o) so long Maik -------------- next part -------------- A non-text attachment was scrubbed... Name: libnfnetlink.sgml Type: text/sgml Size: 26941 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061010/5514f742/libnfnetlink-0001.bin From pablo at netfilter.org Tue Oct 10 20:07:53 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Oct 10 20:43:26 2006 Subject: [CTNETLINK] Fix compilation with debugging enabled In-Reply-To: <452B25BB.6020909@trash.net> References: <452AF2FE.1050606@netfilter.org> <452B25BB.6020909@trash.net> Message-ID: <452BE179.6090702@netfilter.org> Patrick McHardy wrote: > Pablo Neira Ayuso wrote: >> Two debugging messages inside dump_table refer to variable `id' >> that is not declared anymore. > > Are you actually using the debugging stuff? Most of the ctnetlink > debugging looks like a leftover from early development, so unless > you think its still useful, I would prefer to remove it entirely > since it makes the code less readable IMO. Agreed, I'll cook a patch to remove 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 alan.ezust at presinet.com Tue Oct 10 21:15:41 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Tue Oct 10 21:53:22 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <45279039.8090309@netfilter.org> References: <200610031518.10097.alan.ezust@presinet.com> <200610061314.16177.alan.ezust@presinet.com> <45279039.8090309@netfilter.org> Message-ID: <200610101215.42121.alan.ezust@presinet.com> On Saturday 07 October 2006 04:32, Pablo Neira Ayuso wrote: > Alan Ezust wrote: > > On Thursday 05 October 2006 03:23, Pablo Neira Ayuso wrote: > >> Alan Ezust wrote: > >>> On Wednesday 04 October 2006 15:04, Pablo Neira Ayuso wrote: > >>>> Alan Ezust wrote: > >>>>> On Wednesday 04 October 2006 12:48, Pablo Neira Ayuso wrote: > >>>>>> Alan Ezust wrote: > >>>>>>> Hi - i'm trying out the "conntrack" program for my first time. > >>>>>>> It compiles and runs, but when I try to do > >>>>>>> > >>>>>>> conntrack -L conntrack > >>>>>>> > >>>>>>> it shows me nothing. > >>>>>>> > >>>>>>> If I cat /proc/net/ip_conntrack I can see lots of log lines there. > >>>>>>> Should the conntrack -L conntrack show me pretty much the same > >>>>>>> thing? > >>>>>>> > >>>>>>> What's the best way to test that conntrack is working properly? > >>>>>> > >>>>>> Please check that ip_conntrack_netlink is loaded, old kernel do not > >>>>>> load it on demand. > >>>>> > >>>>> I'm using kernel 2.6.16.29. > >>>>> > >>>>> These kernel options are set: > >>>>> > >>>>> CONFIG_NETFILTER_NETLINK=y > >>>>> CONFIG_NETFILTER_NETLINK_QUEUE=y > >>>>> CONFIG_NETFILTER_NETLINK_LOG=y > >>>>> CONFIG_IP_NF_CONNTRACK_NETLINK=y > >>>>> > >>>>> Are you saying I should also add a > >>>>> CONFIG_IP_CONNTRACK_NETLINK flag in the .config or something else? > >>>> > >>>> No, people usually compile ip_conntrack_netlink as module, and I > >>>> wanted to make sure that the module was loaded (modprobe > >>>> ip_conntrack_netlink) but since you compiled it built-in. > >>> > >>> What's the difference between IP_NF_CONNTRACK_NETLINK and > >>> IP_CONNTRACK_NETLINK? Are they different modules or is one the new name > >>> for the other? > >> > >> you're referring to the same thing. This problem that you're observing > >> is freak. Please check that ctnetlink is correctly registered. > > > > On my machine, when I do lsmod, here is the list of modules I have > > loaded: > > > > ip_conntrack_netlink 22016 0 > > ip_nat 14164 1 ip_conntrack_netlink > > ipt_recent 9836 2 > > ipt_LOG 5856 4 > > ipt_bin 20772 7 > > iptable_promisc 1376 1 > > ipt_multiport 2112 10 > > iptable_filter 2112 1 > > ip_tables 10816 2 iptable_promisc,iptable_filter > > xt_conntrack 1856 0 > > xt_CONNMARK 1824 2 > > xt_connmark 1440 2 > > xt_pkttype 1440 1 > > xt_MARK 2080 0 > > xt_state 1536 4 > > ipt_psd 43588 1 > > ipt_regex 7240 1 > > ipt_DATA 3712 5 > > ip_conntrack 45996 7 > > ip_conntrack_netlink,ip_nat,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state > >,ipt_DATA tulip 45152 0 > > eepro100 25776 0 > > 8139too 20352 0 > > 3c59x 38952 0 > > 8390 8320 0 > > > >> # dmesg | grep ctnetlink > >> ctnetlink v0.90: registering with nfnetlink. > > > > Got that - here is my dmesg tail: > > > > ip_conntrack version 2.4 (2048 buckets, 16384 max) - 252 bytes per > > conntrack ipt_regex v0.0.0 > > netfilter PSD loaded - (c) astaro AG > > ip_conntrack_netlink: Unknown symbol ip_nat_setup_info > > ip_conntrack_netlink: Unknown symbol ip_nat_proto_put > > ip_conntrack_netlink: Unknown symbol ip_nat_proto_find_get > > It seems that some symbols are unresolved so ip_conntrack_netlink won't > work. See below. > > >> Send me also your .config file just to have more information. > > > > attached. > > > >>>> Could you tell me what version of conntrack/libnetfilter_conntrac are > >>>> you using? > >>> > >>> conntrack 1.00beta2 > >>> libnetfilter_conntrack-0.0.31/ > >>> libnfnetlink-0.0.16/ > >> > >> Please, try with an updated version from netfilter's SVN > > > > I found an incompatibility in libnfnetlink. Before, I was building on a > > system that had 2.6.18 on it, and trying to deploy it on a machine that > > had kernel 2.6.16.29. The executable I built didn't do anything. > > > > Now I am compiling on a system that has the same version (2.6.16.29) of > > the kernel as the destination, I am unable to compile the latest (svn as > > well as released) versions of libnfnetlink. > > > > What is the recommended kernel version I should be using, if I want to > > get conntrack up and running for my first time? Should I go to 2.6.18 and > > forget about 2.6.16.29? > > lastest includes tons of changes, better upgrade to 2.6.18. > > > gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" > > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libnfnetlink\" > > -DVERSION=\"0.0.16\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I../include > > -I/home/ezust/presinet/projects/conntrack/usr/include -fPIC -Wall > > -I/home/ezust/presinet/projects/conntrack/usr/include > > -L/home/ezust/presinet/projects/conntrack/usr/lib -MT libnfnetlink.lo -MD > > -MP -MF .deps/libnfnetlink.Tpo -c > > libnfnetlink.c -fPIC -DPIC -o .libs/libnfnetlink.o > > libnfnetlink.c: In function 'nfnl_listen': > > libnfnetlink.c:445: error: 'EINTR' undeclared (first use in this > > function) libnfnetlink.c:445: error: (Each undeclared identifier is > > reported only once libnfnetlink.c:445: error: for each function it > > appears in.) > > libnfnetlink.c:448: error: 'EBADF' undeclared (first use in this > > function) libnfnetlink.c:450: error: 'EAGAIN' undeclared (first use in > > this function) libnfnetlink.c: In function 'nfnl_talk': > > libnfnetlink.c:554: error: 'EINTR' undeclared (first use in this > > function) libnfnetlink.c: In function 'nfnl_callback_register': > > libnfnetlink.c:878: error: 'EINVAL' undeclared (first use in this > > function) libnfnetlink.c: In function 'nfnl_callback_unregister': > > libnfnetlink.c:888: error: 'EINVAL' undeclared (first use in this > > function) libnfnetlink.c: In function 'nfnl_check_attributes': > > libnfnetlink.c:906: error: 'EINVAL' undeclared (first use in this > > function) make[1]: *** [libnfnetlink.lo] Error 1 > > make[1]: Leaving directory > > `/home/ezust/presinet/projects/conntrack-1.00beta2/libnfnetlink-0.0.16/sr > >c' > > Is /usr/include/linux/errno.h available in your system? Yes, but it does not define those symbols. I found them defined in a file called "errno-base.h" in include/asm-generic/errno-base.h, but for some reason, when I built and installed the kernel, it did not place these files into my /usr/include/asm* directories. #define EPERM 1 /* Operation not permitted */ #define ENOENT 2 /* No such file or directory */ #define EINTR 4 /* Interrupted system call */ #define EAGAIN 11 /* Try again */ #define ENOMEM 12 /* Out of memory */ #define EINVAL 22 /* Invalid argument */ #define EBADF 9 /* Bad file number */ #define ENODEV 19 /* No such device */ #define EEXIST 17 /* File exists */ Is there a configure switch or a variable to set that lets me specify which kernel source tree to use when building libnfnetlink, libnfconntrack and conntrack? > > thanks again for your help --alan > > > > > > # > > # IP: Netfilter Configuration > > # > > CONFIG_IP_NF_CONNTRACK=m > > CONFIG_IP_NF_CT_ACCT=y > > CONFIG_IP_NF_CONNTRACK_MARK=y > > CONFIG_IP_NF_CONNTRACK_EVENTS=y > > CONFIG_IP_NF_CONNTRACK_NETLINK=m > > ^^^ > You told me that you compiled ip_conntrack_netlink built-in? This > doesn't match with your previous email... here it appears as module. You are absolutely correct: when I wrote you the first e-mail, it was compiled built-in, and I was running into problems getting it working, so since then I rebuilt the kernel and compiled everything possible as a module, since that's what IPTABLES seemed to want. So NOW it is a module. > You forgot to compile built-in NAT support that is required by > ip_conntrack_netlink. > I think that the best solution is to rebuild your kernel and include all > the netfilter netlink subsystems as modules, that will fix your problem. From shemminger at osdl.org Tue Oct 10 21:42:16 2006 From: shemminger at osdl.org (Stephen Hemminger) Date: Tue Oct 10 22:19:34 2006 Subject: Fw: [Bug 7297] New: modprobe -v -r causes crash in xt_unregister_match Message-ID: <20061010124216.74489253@freekitty> Looks like an xt_tables bug. On Tue, 10 Oct 2006 05:10:47 -0700 bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=7297 > > Summary: modprobe -v -r causes crash in xt_unregister_match > Kernel Version: 2.6.16 / 2.6.19-rc1-git6 > Status: NEW > Severity: normal > Owner: laforge@gnumonks.org > Submitter: olh@suse.de > > > Most recent kernel where this bug did not occur: untested > Distribution: SuSE Linux > Hardware Environment: IBM JS20 ppc64 > Software Environment: > Problem Description: > > NET: Unregistered protocol family 5 > ieee80211_crypt: unregistered algorithm 'CCMP' > ieee80211_crypt: unregistered algorithm 'WEP' > ieee80211_crypt: unregistered algorithm 'NULL' > Unable to handle kernel paging request for data at address 0xd000000000d57c08 > Faulting instruction address: 0xd0000000000e667c > Oops: Kernel access of bad area, sig: 11 [#1] > SMP NR_CPUS=128 NUMA > Modules linked in: ip_gre sco rfcomm hidp bnep l2cap bluetooth rpcsec_gss_spkm3 > rpcsec_gss_krb5 auth_rpcgss sunrpc ebt_802_3 ebt_redirect ebt_snat ebt_mark > ebtable_na > t ebt_pkttype ebt_dnat ebt_among ebt_limit ebtable_filter ebt_ip ebt_arpreply > ebt_stp ebt_log ebt_mark_m ebt_arp ebt_vlan ebtable_broute ebtables xt_NFQUEUE > xt_CONNSE > CMARK xt_statistic xt_policy xt_multiport xt_length bridge sctp ts_kmp dccp_ipv6 > dccp_ipv4 dccp xt_pkttype ipt_LOG xt_limit autofs4 ip6t_REJECT xt_tcpudp > ipt_REJECT x > t_state iptable_filter ip_conntrack nfnetlink ip_tables ip6table_filter > ip6_tables x_tables ipv6 loop dm_mod tg3 generic qla2xxx scsi_transport_fc > firmware_class sd_m > od scsi_mod > NIP: D0000000000E667C LR: D0000000000E665C CTR: C000000000391EDC > REGS: c0000000510db900 TRAP: 0300 Not tainted (2.6.19-rc1-git6-ppc64-netfilter) > MSR: 8000000000009032 CR: 24228282 XER: 200FFFFF > DAR: D000000000D57C08, DSISR: 0000000042000000 > TASK = c000000051b300c0[6162] 'modprobe' THREAD: c0000000510d8000 CPU: 0 > GPR00: 0000000000100100 C0000000510DBB80 D0000000000F9518 C00000000F2FB0C0 > GPR04: 0000000000000002 0000000000001EDB 0000000024228282 000000000170AB80 > GPR08: 0000000000000000 0000000000200200 D000000000D72E70 D000000000D57C00 > GPR12: D0000000000E7FF0 C00000000048D400 0000000000000000 0000000010020000 > GPR16: 0000000000000001 0000000000000000 0000000000000000 0000000010028248 > GPR20: 0000000000000000 00000000100283C8 0000000000000003 0000000010001B80 > GPR24: 0000000000000001 0000000000000000 0000000010028B24 D0000000000F1528 > GPR28: 00000000000000C0 D000000000D6C8B0 D0000000000F9080 0000000000000000 > NIP [D0000000000E667C] .xt_unregister_match+0x5c/0xa0 [x_tables] > LR [D0000000000E665C] .xt_unregister_match+0x3c/0xa0 [x_tables] > Call Trace: > [C0000000510DBB80] [D0000000000E665C] .xt_unregister_match+0x3c/0xa0 [x_tables] > (unreliable) > [C0000000510DBC20] [D0000000000E66EC] .xt_unregister_matches+0x2c/0x60 [x_tables] > [C0000000510DBCB0] [D000000000D6C0A0] .xt_length_fini+0x20/0x38 [xt_length] > [C0000000510DBD30] [C00000000008A6AC] .sys_delete_module+0x1f0/0x248 > [C0000000510DBE30] [C00000000000871C] syscall_exit+0x0/0x40 > Instruction dump: > e87b0000 1f9c0060 7c7c1a14 48001999 e8410028 e95d0008 e97d0000 3c000010 > 3d200020 60000100 61290200 f96a0000 f81d0000 f93d0008 60000000 > > Steps to reproduce: > > find /lib/modules/`uname -r`/kernel/net/ -name "*.ko" | xargs -n1 basename | sed > 's@\.ko$@@' | xargs -n1 modprobe -v > > find /lib/modules/`uname -r`/kernel/net/ -name "*.ko" | xargs -n1 basename | sed > 's@\.ko$@@' | xargs -n1 modprobe -v -r > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Stephen Hemminger From eric at inl.fr Tue Oct 10 23:54:20 2006 From: eric at inl.fr (Eric Leblond) Date: Wed Oct 11 00:31:34 2006 Subject: [PATCH 0/3] ulogd2 update Message-ID: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> Hi, This set of patches updates ulogd2 ULOG plugin to current API and fix a crash. BR, -- Eric Leblond INL : http://www.inl.fr NuFW, Now User Filtering Works (http://www.nufw.org) From eric at inl.fr Tue Oct 10 23:57:08 2006 From: eric at inl.fr (Eric Leblond) Date: Wed Oct 11 00:34:20 2006 Subject: [PATCH 1/3] ulogd2 update In-Reply-To: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> References: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> Message-ID: <4281.83.156.0.70.1160517428.squirrel@mail.inl.fr> Hi, This patch synchronizes ULOG input plugin with current ulogd2 API. BR -- Eric Leblond INL : http://www.inl.fr NuFW, Now User Filtering Works (http://www.nufw.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: ulogd2-sync-api.patch Type: text/x-patch Size: 413 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061011/f4e22341/ulogd2-sync-api.bin From eric at inl.fr Tue Oct 10 23:59:21 2006 From: eric at inl.fr (Eric Leblond) Date: Wed Oct 11 00:36:34 2006 Subject: [PATCH 2/3] ulogd2 update In-Reply-To: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> References: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> Message-ID: <4287.83.156.0.70.1160517561.squirrel@mail.inl.fr> Hi, This patch fixes a crash in ULOG input plugin due to a free on invalid value. BR, -- Eric Leblond INL : http://www.inl.fr NuFW, Now User Filtering Works (http://www.nufw.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: ulogd2-free-crash.patch Type: text/x-patch Size: 557 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061011/2e5ac5ca/ulogd2-free-crash.bin From eric at inl.fr Wed Oct 11 00:01:15 2006 From: eric at inl.fr (Eric Leblond) Date: Wed Oct 11 00:38:29 2006 Subject: [PATCH 3/3] ulogd2 update In-Reply-To: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> References: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> Message-ID: <4295.83.156.0.70.1160517675.squirrel@mail.inl.fr> Hi, This patch fixes a trivial typo in ULOG plugin code. BR, -- Eric Leblond INL : http://www.inl.fr NuFW, Now User Filtering Works (http://www.nufw.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: ulogd2-typo.patch Type: text/x-patch Size: 621 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061011/8cf0d6a5/ulogd2-typo.bin From pablo at netfilter.org Wed Oct 11 00:58:41 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Oct 11 01:29:07 2006 Subject: [CTNETLINK] Remove debugging messages Message-ID: <452C25A1.1060302@netfilter.org> Remove debugging messages introduced at early development stage Signed-off-by: Pablo Neira Ayuso -- 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 -------------- [CTNETLINK] Remove debugging messages Remove debugging messages introduces at early development stage Signed-off-by: Pablo Neira Ayuso Index: net-2.6/net/ipv4/netfilter/ip_conntrack_netlink.c =================================================================== --- net-2.6.orig/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-10-10 03:00:00.000000000 +0200 +++ net-2.6/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-10-11 00:32:15.000000000 +0200 @@ -44,13 +44,6 @@ MODULE_LICENSE("GPL"); static char __initdata version[] = "0.90"; -#if 0 -#define DEBUGP printk -#else -#define DEBUGP(format, args...) -#endif - - static inline int ctnetlink_dump_tuples_proto(struct sk_buff *skb, const struct ip_conntrack_tuple *tuple, @@ -398,7 +391,6 @@ nfattr_failure: static int ctnetlink_done(struct netlink_callback *cb) { - DEBUGP("entered %s\n", __FUNCTION__); if (cb->args[1]) ip_conntrack_put((struct ip_conntrack *)cb->args[1]); return 0; @@ -411,9 +403,6 @@ ctnetlink_dump_table(struct sk_buff *skb struct ip_conntrack_tuple_hash *h; struct list_head *i; - DEBUGP("entered %s, last bucket=%lu id=%u\n", __FUNCTION__, - cb->args[0], *id); - read_lock_bh(&ip_conntrack_lock); last = (struct ip_conntrack *)cb->args[1]; for (; cb->args[0] < ip_conntrack_htable_size; cb->args[0]++) { @@ -452,7 +441,6 @@ out: if (last) ip_conntrack_put(last); - DEBUGP("leaving, last bucket=%lu id=%u\n", cb->args[0], *id); return skb->len; } @@ -466,8 +454,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * { struct nfattr *tb[CTA_IP_MAX]; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_IP_MAX, attr); if (nfattr_bad_size(tb, CTA_IP_MAX, cta_min_ip)) @@ -481,8 +467,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * return -EINVAL; tuple->dst.ip = *(__be32 *)NFA_DATA(tb[CTA_IP_V4_DST-1]); - DEBUGP("leaving\n"); - return 0; } @@ -503,8 +487,6 @@ ctnetlink_parse_tuple_proto(struct nfatt struct ip_conntrack_protocol *proto; int ret = 0; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTO_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTO_MAX, cta_min_proto)) @@ -531,8 +513,6 @@ ctnetlink_parse_tuple(struct nfattr *cda struct nfattr *tb[CTA_TUPLE_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(tuple, 0, sizeof(*tuple)); nfattr_parse_nested(tb, CTA_TUPLE_MAX, cda[type-1]); @@ -557,10 +537,6 @@ ctnetlink_parse_tuple(struct nfattr *cda else tuple->dst.dir = IP_CT_DIR_ORIGINAL; - DUMP_TUPLE(tuple); - - DEBUGP("leaving\n"); - return 0; } @@ -577,8 +553,6 @@ static int ctnetlink_parse_nat_proto(str struct nfattr *tb[CTA_PROTONAT_MAX]; struct ip_nat_protocol *npt; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTONAT_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTONAT_MAX, cta_min_protonat)) @@ -597,7 +571,6 @@ static int ctnetlink_parse_nat_proto(str ip_nat_proto_put(npt); - DEBUGP("leaving\n"); return 0; } @@ -613,8 +586,6 @@ ctnetlink_parse_nat(struct nfattr *nat, struct nfattr *tb[CTA_NAT_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(range, 0, sizeof(*range)); nfattr_parse_nested(tb, CTA_NAT_MAX, nat); @@ -640,7 +611,6 @@ ctnetlink_parse_nat(struct nfattr *nat, if (err < 0) return err; - DEBUGP("leaving\n"); return 0; } #endif @@ -650,8 +620,6 @@ ctnetlink_parse_help(struct nfattr *attr { struct nfattr *tb[CTA_HELP_MAX]; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_HELP_MAX, attr); if (!tb[CTA_HELP_NAME-1]) @@ -679,8 +647,6 @@ ctnetlink_del_conntrack(struct sock *ctn struct ip_conntrack *ct; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -698,10 +664,8 @@ ctnetlink_del_conntrack(struct sock *ctn return err; h = ip_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash\n"); + if (!h) return -ENOENT; - } ct = tuplehash_to_ctrack(h); @@ -716,7 +680,6 @@ ctnetlink_del_conntrack(struct sock *ctn ct->timeout.function((unsigned long)ct); ip_conntrack_put(ct); - DEBUGP("leaving\n"); return 0; } @@ -731,8 +694,6 @@ ctnetlink_get_conntrack(struct sock *ctn struct sk_buff *skb2 = NULL; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nlh->nlmsg_flags & NLM_F_DUMP) { struct nfgenmsg *msg = NLMSG_DATA(nlh); u32 rlen; @@ -770,11 +731,9 @@ ctnetlink_get_conntrack(struct sock *ctn return err; h = ip_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash"); + if (!h) return -ENOENT; - } - DEBUGP("tuple found\n"); + ct = tuplehash_to_ctrack(h); err = -ENOMEM; @@ -795,7 +754,6 @@ ctnetlink_get_conntrack(struct sock *ctn if (err < 0) goto out; - DEBUGP("leaving\n"); return 0; free: @@ -866,8 +824,6 @@ ctnetlink_change_helper(struct ip_conntr char *helpname; int err; - DEBUGP("entered %s\n", __FUNCTION__); - /* don't change helper of sibling connections */ if (ct->master) return -EINVAL; @@ -938,8 +894,6 @@ ctnetlink_change_conntrack(struct ip_con { int err; - DEBUGP("entered %s\n", __FUNCTION__); - if (cda[CTA_HELP-1]) { err = ctnetlink_change_helper(ct, cda); if (err < 0) @@ -969,7 +923,6 @@ ctnetlink_change_conntrack(struct ip_con ct->mark = ntohl(*(__be32 *)NFA_DATA(cda[CTA_MARK-1])); #endif - DEBUGP("all done\n"); return 0; } @@ -981,8 +934,6 @@ ctnetlink_create_conntrack(struct nfattr struct ip_conntrack *ct; int err = -EINVAL; - DEBUGP("entered %s\n", __FUNCTION__); - ct = ip_conntrack_alloc(otuple, rtuple); if (ct == NULL || IS_ERR(ct)) return -ENOMEM; @@ -1017,7 +968,6 @@ ctnetlink_create_conntrack(struct nfattr if (ct->helper) ip_conntrack_helper_put(ct->helper); - DEBUGP("conntrack with id %u inserted\n", ct->id); return 0; err: @@ -1033,8 +983,6 @@ ctnetlink_new_conntrack(struct sock *ctn struct ip_conntrack_tuple_hash *h = NULL; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -1058,7 +1006,6 @@ ctnetlink_new_conntrack(struct sock *ctn if (h == NULL) { write_unlock_bh(&ip_conntrack_lock); - DEBUGP("no such conntrack, create new\n"); err = -ENOENT; if (nlh->nlmsg_flags & NLM_F_CREATE) err = ctnetlink_create_conntrack(cda, &otuple, &rtuple); @@ -1074,7 +1021,6 @@ ctnetlink_new_conntrack(struct sock *ctn /* We manipulate the conntrack inside the global conntrack table lock, * so there's no need to increase the refcount */ - DEBUGP("conntrack found\n"); err = -EEXIST; if (!(nlh->nlmsg_flags & NLM_F_EXCL)) err = ctnetlink_change_conntrack(tuplehash_to_ctrack(h), cda); @@ -1249,8 +1195,6 @@ ctnetlink_exp_dump_table(struct sk_buff struct list_head *i; u_int32_t *id = (u_int32_t *) &cb->args[0]; - DEBUGP("entered %s, last id=%llu\n", __FUNCTION__, *id); - read_lock_bh(&ip_conntrack_lock); list_for_each_prev(i, &ip_conntrack_expect_list) { exp = (struct ip_conntrack_expect *) i; @@ -1266,8 +1210,6 @@ ctnetlink_exp_dump_table(struct sk_buff out: read_unlock_bh(&ip_conntrack_lock); - DEBUGP("leaving, last id=%llu\n", *id); - return skb->len; } @@ -1285,8 +1227,6 @@ ctnetlink_get_expect(struct sock *ctnl, struct sk_buff *skb2; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1437,8 +1377,6 @@ ctnetlink_create_expect(struct nfattr *c struct ip_conntrack *ct; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - /* caller guarantees that those three CTA_EXPECT_* exist */ err = ctnetlink_parse_tuple(cda, &tuple, CTA_EXPECT_TUPLE); if (err < 0) @@ -1490,8 +1428,6 @@ ctnetlink_new_expect(struct sock *ctnl, struct ip_conntrack_expect *exp; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1520,8 +1456,6 @@ ctnetlink_new_expect(struct sock *ctnl, err = ctnetlink_change_expect(exp, cda); write_unlock_bh(&ip_conntrack_lock); - DEBUGP("leaving\n"); - return err; } Index: net-2.6/net/netfilter/nf_conntrack_netlink.c =================================================================== --- net-2.6.orig/net/netfilter/nf_conntrack_netlink.c 2006-10-10 03:02:35.000000000 +0200 +++ net-2.6/net/netfilter/nf_conntrack_netlink.c 2006-10-11 00:12:53.000000000 +0200 @@ -47,13 +47,6 @@ MODULE_LICENSE("GPL"); static char __initdata version[] = "0.93"; -#if 0 -#define DEBUGP printk -#else -#define DEBUGP(format, args...) -#endif - - static inline int ctnetlink_dump_tuples_proto(struct sk_buff *skb, const struct nf_conntrack_tuple *tuple, @@ -410,7 +403,6 @@ static int ctnetlink_done(struct netlink { if (cb->args[1]) nf_ct_put((struct nf_conn *)cb->args[1]); - DEBUGP("entered %s\n", __FUNCTION__); return 0; } @@ -425,9 +417,6 @@ ctnetlink_dump_table(struct sk_buff *skb struct nfgenmsg *nfmsg = NLMSG_DATA(cb->nlh); u_int8_t l3proto = nfmsg->nfgen_family; - DEBUGP("entered %s, last bucket=%lu id=%u\n", __FUNCTION__, - cb->args[0], *id); - read_lock_bh(&nf_conntrack_lock); last = (struct nf_conn *)cb->args[1]; for (; cb->args[0] < nf_conntrack_htable_size; cb->args[0]++) { @@ -471,7 +460,6 @@ out: if (last) nf_ct_put(last); - DEBUGP("leaving, last bucket=%lu id=%u\n", cb->args[0], *id); return skb->len; } @@ -482,8 +470,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * struct nf_conntrack_l3proto *l3proto; int ret = 0; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_IP_MAX, attr); l3proto = nf_ct_l3proto_find_get(tuple->src.l3num); @@ -493,8 +479,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * nf_ct_l3proto_put(l3proto); - DEBUGP("leaving\n"); - return ret; } @@ -510,8 +494,6 @@ ctnetlink_parse_tuple_proto(struct nfatt struct nf_conntrack_protocol *proto; int ret = 0; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTO_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTO_MAX, cta_min_proto)) @@ -538,8 +520,6 @@ ctnetlink_parse_tuple(struct nfattr *cda struct nfattr *tb[CTA_TUPLE_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(tuple, 0, sizeof(*tuple)); nfattr_parse_nested(tb, CTA_TUPLE_MAX, cda[type-1]); @@ -566,10 +546,6 @@ ctnetlink_parse_tuple(struct nfattr *cda else tuple->dst.dir = IP_CT_DIR_ORIGINAL; - NF_CT_DUMP_TUPLE(tuple); - - DEBUGP("leaving\n"); - return 0; } @@ -586,8 +562,6 @@ static int ctnetlink_parse_nat_proto(str struct nfattr *tb[CTA_PROTONAT_MAX]; struct ip_nat_protocol *npt; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTONAT_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTONAT_MAX, cta_min_protonat)) @@ -606,7 +580,6 @@ static int ctnetlink_parse_nat_proto(str ip_nat_proto_put(npt); - DEBUGP("leaving\n"); return 0; } @@ -622,8 +595,6 @@ ctnetlink_parse_nat(struct nfattr *nat, struct nfattr *tb[CTA_NAT_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(range, 0, sizeof(*range)); nfattr_parse_nested(tb, CTA_NAT_MAX, nat); @@ -649,7 +620,6 @@ ctnetlink_parse_nat(struct nfattr *nat, if (err < 0) return err; - DEBUGP("leaving\n"); return 0; } #endif @@ -659,8 +629,6 @@ ctnetlink_parse_help(struct nfattr *attr { struct nfattr *tb[CTA_HELP_MAX]; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_HELP_MAX, attr); if (!tb[CTA_HELP_NAME-1]) @@ -690,8 +658,6 @@ ctnetlink_del_conntrack(struct sock *ctn u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -709,10 +675,8 @@ ctnetlink_del_conntrack(struct sock *ctn return err; h = nf_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash\n"); + if (!h) return -ENOENT; - } ct = nf_ct_tuplehash_to_ctrack(h); @@ -727,7 +691,6 @@ ctnetlink_del_conntrack(struct sock *ctn ct->timeout.function((unsigned long)ct); nf_ct_put(ct); - DEBUGP("leaving\n"); return 0; } @@ -744,8 +707,6 @@ ctnetlink_get_conntrack(struct sock *ctn u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nlh->nlmsg_flags & NLM_F_DUMP) { u32 rlen; @@ -779,11 +740,9 @@ ctnetlink_get_conntrack(struct sock *ctn return err; h = nf_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash"); + if (!h) return -ENOENT; - } - DEBUGP("tuple found\n"); + ct = nf_ct_tuplehash_to_ctrack(h); err = -ENOMEM; @@ -804,7 +763,6 @@ ctnetlink_get_conntrack(struct sock *ctn if (err < 0) goto out; - DEBUGP("leaving\n"); return 0; free: @@ -876,8 +834,6 @@ ctnetlink_change_helper(struct nf_conn * char *helpname; int err; - DEBUGP("entered %s\n", __FUNCTION__); - if (!help) { /* FIXME: we need to reallocate and rehash */ return -EBUSY; @@ -954,8 +910,6 @@ ctnetlink_change_conntrack(struct nf_con { int err; - DEBUGP("entered %s\n", __FUNCTION__); - if (cda[CTA_HELP-1]) { err = ctnetlink_change_helper(ct, cda); if (err < 0) @@ -985,7 +939,6 @@ ctnetlink_change_conntrack(struct nf_con ct->mark = ntohl(*(u_int32_t *)NFA_DATA(cda[CTA_MARK-1])); #endif - DEBUGP("all done\n"); return 0; } @@ -997,8 +950,6 @@ ctnetlink_create_conntrack(struct nfattr struct nf_conn *ct; int err = -EINVAL; - DEBUGP("entered %s\n", __FUNCTION__); - ct = nf_conntrack_alloc(otuple, rtuple); if (ct == NULL || IS_ERR(ct)) return -ENOMEM; @@ -1028,7 +979,6 @@ ctnetlink_create_conntrack(struct nfattr add_timer(&ct->timeout); nf_conntrack_hash_insert(ct); - DEBUGP("conntrack with id %u inserted\n", ct->id); return 0; err: @@ -1046,8 +996,6 @@ ctnetlink_new_conntrack(struct sock *ctn u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -1071,7 +1019,6 @@ ctnetlink_new_conntrack(struct sock *ctn if (h == NULL) { write_unlock_bh(&nf_conntrack_lock); - DEBUGP("no such conntrack, create new\n"); err = -ENOENT; if (nlh->nlmsg_flags & NLM_F_CREATE) err = ctnetlink_create_conntrack(cda, &otuple, &rtuple); @@ -1087,7 +1034,6 @@ ctnetlink_new_conntrack(struct sock *ctn /* We manipulate the conntrack inside the global conntrack table lock, * so there's no need to increase the refcount */ - DEBUGP("conntrack found\n"); err = -EEXIST; if (!(nlh->nlmsg_flags & NLM_F_EXCL)) err = ctnetlink_change_conntrack(nf_ct_tuplehash_to_ctrack(h), cda); @@ -1268,8 +1214,6 @@ ctnetlink_exp_dump_table(struct sk_buff struct nfgenmsg *nfmsg = NLMSG_DATA(cb->nlh); u_int8_t l3proto = nfmsg->nfgen_family; - DEBUGP("entered %s, last id=%llu\n", __FUNCTION__, *id); - read_lock_bh(&nf_conntrack_lock); list_for_each_prev(i, &nf_conntrack_expect_list) { exp = (struct nf_conntrack_expect *) i; @@ -1287,8 +1231,6 @@ ctnetlink_exp_dump_table(struct sk_buff out: read_unlock_bh(&nf_conntrack_lock); - DEBUGP("leaving, last id=%llu\n", *id); - return skb->len; } @@ -1308,8 +1250,6 @@ ctnetlink_get_expect(struct sock *ctnl, u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1460,8 +1400,6 @@ ctnetlink_create_expect(struct nfattr *c struct nf_conn_help *help; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - /* caller guarantees that those three CTA_EXPECT_* exist */ err = ctnetlink_parse_tuple(cda, &tuple, CTA_EXPECT_TUPLE, u3); if (err < 0) @@ -1516,8 +1454,6 @@ ctnetlink_new_expect(struct sock *ctnl, u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1546,8 +1482,6 @@ ctnetlink_new_expect(struct sock *ctnl, err = ctnetlink_change_expect(exp, cda); write_unlock_bh(&nf_conntrack_lock); - DEBUGP("leaving\n"); - return err; } From pablo at netfilter.org Wed Oct 11 01:59:58 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Oct 11 02:30:17 2006 Subject: nfq_set_verdict_mark In-Reply-To: <452B2D9A.7080702@trash.net> References: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> <4521284C.2070000@netfilter.org> <452B2D9A.7080702@trash.net> Message-ID: <452C33FE.6060902@netfilter.org> Hi Patrick, Patrick McHardy wrote: > Pablo Neira Ayuso wrote: >> Robert Scott wrote: >> >>> i noticed that this function doesn't automatically convert the mark into >>> the expected network byte order. this is a minor detail, but the >>> current behavior may confuse users. since nfq_get_nfmark automatically >>> converts the mark into host order, i thought nfq_set_verdict_mark would >>> also do the reverse. >>> >>> not really a big deal, and this will probably break most existing >>> installations in the field, but perhaps a note in the docs to give new >>> users a heads up. >> >> Yes, I agree what you, we have to document this minor issue, I think >> that we can introduce more API that can solve this inconsistency. > > Do we actually have documentation where we can document it? :) > > I'm beginning to wonder how much more kludges we will have in these > libraries by continuing to treat them as stable without having had > even a single beta version. OK, I start thinking that I'm getting obsessed with breaking current deployed apps :(. I also think that we can solve this minor annoying issues by fixing the problem and then releasing a new version asap. The current release process is too slow, I have the impression that nobody is using the lastest official releases. For conntrackd, I'm currently doing unnofficial releases of libnetfilter_conntrack because the official release is broken with NAT handlings, well apart from the fact that I also introduce some patches with new features that I need. Just tell you that I don't mind about spending some time on administration tasks like releases and any other stuff related with the website if that can help to speed up the release process. I worked on some scripts to automate the release process time ago after the workshop that I can recover. -- 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 rbscott at cadvium.net Wed Oct 11 04:20:01 2006 From: rbscott at cadvium.net (robert) Date: Wed Oct 11 04:57:24 2006 Subject: ipq and nf_queue compatibility Message-ID: Hello, I am porting a program that uses IPQ to NF_QUEUE, and the port went very smoothly, but I noticed that if I run the nfqueue version once, the ipq version stops working. The NF_QUEUE version always works, but the other one simple stops functioning. Is there a known incompatibility between the two? Or perhaps is there some global state that I need to cleanup inside of the NFQUEUE version before I execute the IPQ version. The kernel has both IPQ and NFQUEUE support. This happens regardless of whether or not I call the function nfq_unbind_pf on exit. Not really sure what that function does, but it was inside of nfqnl_test.c, so I tried it out. any ideas? --robert From federikkom at yahoo.com.ar Wed Oct 11 05:40:21 2006 From: federikkom at yahoo.com.ar (federikkom) Date: Wed Oct 11 06:17:40 2006 Subject: new match extension to implement port knocking in one rule Message-ID: <20061011034021.26783.qmail@web39501.mail.mud.yahoo.com> Hi everybody, we have been working in a netfilter extension to implement port knocking in a easy way. The idea is to set everything in just one iptables rule: for instance, if you want port knocking to allow SSH connections: (1) the quick and easy way: $ iptables -A INPUT -m state --state NEW -m pknock --name SSH --knockports 2002,2001,2004 -p tcp --dport 22 -j ACCEPT after "knocking" ports 2002, 2001 and 2004 in sequence, you are allowed to connect to port 22. We are also working in a more secure way to "knock" using hmacs: (2) the more secure way: you knock with a UDP packet, payload containing an hmac (see the README.txt for more details) $ iptables -A INPUT -m state --state NEW -m pknock --name SSH --knockports 2000 --opensecret --closesecret -p udp -j DROP $ iptables -A INPUT -m state --state NEW -m pknock --name SSH --checkip -p tcp --dport 22 -j ACCEPT The project is hosted at berlios: http://developer.berlios.de/projects/portknocko/ and you can check the source code out here: svn checkout svn://svn.berlios.de/portknocko/trunk hope you like the idea! any feedback is welcome! regards, Luis Aquiles Floreani and J. Federico Hernandez __________________________________________________ Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). ?Probalo ya! http://www.yahoo.com.ar/respuestas From degraaf at cpsc.ucalgary.ca Wed Oct 11 07:33:15 2006 From: degraaf at cpsc.ucalgary.ca (Rennie deGraaf) Date: Wed Oct 11 08:10:46 2006 Subject: new match extension to implement port knocking in one rule In-Reply-To: <20061011034021.26783.qmail@web39501.mail.mud.yahoo.com> References: <20061011034021.26783.qmail@web39501.mail.mud.yahoo.com> Message-ID: <452C821B.1000002@cpsc.ucalgary.ca> federikkom wrote: > Hi everybody, we have been working in a netfilter extension to implement port knocking in a easy way. The idea is to set everything in just one iptables rule: > If you're interested in port knocking, you might want to read this paper: http://www.acsac.org/2005/abstracts/156.html It covers security issues relating to port knocking in detail, and presents an architecture for solving most of them. Full disclosure: I wrote that paper. Feel free to contact me if you have questions. 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/20061011/1dc9dde6/signature.pgp From kaber at trash.net Wed Oct 11 07:52:20 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 08:29:38 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel In-Reply-To: <02d001c6ec35$3bf7b870$4c01a8c0@elitecore26> References: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> <452B29F2.70105@trash.net> <02a901c6ec2f$f5d1e730$4c01a8c0@elitecore26> <452B372E.3020206@trash.net> <02d001c6ec35$3bf7b870$4c01a8c0@elitecore26> Message-ID: <452C8694.302@trash.net> Nishit Shah wrote: > Few more results that will help you, > > Test > Connections/Sec > Vanila Kernel > 24000 > Only conntrack loaded > 22000 > Conntrack + NAT module loaded(but no MASQ or SNAT rule in iptables) > 20000-21000 > Conntrack + NAT module loaded(MASQ or SNAT rule in iptables) > 4000 (oops) I'm pretty sure its finding an unused tuple thats taking all the time. Does the c/s rate degrade linear with NAT? From kaber at trash.net Wed Oct 11 07:32:18 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 08:30:52 2006 Subject: [PATCH] Add TCPCONG target to patch-o-matic In-Reply-To: <452B4512.4070705@aarnet.edu.au> References: <45235EDC.4080709@aarnet.edu.au> <4524118B.4020903@netfilter.org> <4524BBB2.2000109@aarnet.edu.au> <452A66CA.70603@trash.net> <452B4512.4070705@aarnet.edu.au> Message-ID: <452C81E2.1040206@trash.net> Glen Turner wrote: > Patrick McHardy wrote: > >> I don't think iptables is the right place to do this. It should >> be controllable through routing IMO (which can already control >> some aspects of congestion control). > > > I too think the choice should usually be done through routing, > with the route holding the preferred congestion control algorithm > for traffic with that prefix. Whereas now the preferred algorithm > is read from a global parameter. > > But the algorithm for a particular connection should still be > able to be changed through iptables. > > Firstly, not every application can be easily altered to use > setsockopt() to select a differing algorithm from the default. > This is the argument used for the TCPMSS and similar targets. The difference is that TCPMSS changes packet data (also for forwarded packets) and doesn't fiddle around with sockets. > As the range of congestion control algorithms grows sysadmins > will want to choose differing algorithms for differing > applications. For example, most algorithm's Ack strategies > interact poorly with transactional and remote procedure call > traffic, so choosing an algorithm which handles this well > could make, say, NFS over TCP traffic run a lot faster. > > Secondly, I want to make it easy for kernel and protocol > developers to run differing algorithms on differing port > numbers to test inter-algorithm fairness. Some TCP algorithms > are quite unfair -- unable even to share a link 50:50 between > two identical flows started a few seconds apart. A TCPCONG > target makes it much easier to do this testing. Now that the > kernel developers are getting good performance on long fat > pipes the fairness and other attributes of that performance > will be their next concern. It still strikes me as a bit of a hack. Lets see what Stephen thinks. From kaber at trash.net Wed Oct 11 07:59:04 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 08:36:20 2006 Subject: ipq and nf_queue compatibility In-Reply-To: References: Message-ID: <452C8828.6000005@trash.net> robert wrote: > Hello, > > I am porting a program that uses IPQ to NF_QUEUE, and the port went > very smoothly, but I noticed that if I run the nfqueue version once, > the ipq version stops working. The NF_QUEUE version always works, but > the other one simple stops functioning. Is there a known > incompatibility between the two? Or perhaps is there some global state > that I need to cleanup inside of the NFQUEUE version before I execute > the IPQ version. The kernel has both IPQ and NFQUEUE support. > > This happens regardless of whether or not I call the function > nfq_unbind_pf on exit. Not really sure what that function does, but it > was inside of nfqnl_test.c, so I tried it out. ip_queue only registeres itself when the module is loaded, nfnetlink_queue registeres when NFQNL_CFG_CMD_PF_BIND is received. So once ip_queue has been unregistered it never registeres again and doesn't receive any packets anymore. From kaber at trash.net Wed Oct 11 08:02:09 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 08:39:24 2006 Subject: [PATCH 3/3] ulogd2 update In-Reply-To: <4295.83.156.0.70.1160517675.squirrel@mail.inl.fr> References: <2289.83.156.0.70.1160517260.squirrel@mail.inl.fr> <4295.83.156.0.70.1160517675.squirrel@mail.inl.fr> Message-ID: <452C88E1.9080005@trash.net> Eric Leblond wrote: > This patch fixes a trivial typo in ULOG plugin code. All three patches applied, thanks Eric. From nishit at elitecore.com Wed Oct 11 08:44:51 2006 From: nishit at elitecore.com (Nishit Shah) Date: Wed Oct 11 09:14:26 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel References: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> <452B29F2.70105@trash.net> <02a901c6ec2f$f5d1e730$4c01a8c0@elitecore26> <452B372E.3020206@trash.net> <02d001c6ec35$3bf7b870$4c01a8c0@elitecore26> <452C8694.302@trash.net> Message-ID: <002f01c6ed00$c21c5f20$4c01a8c0@elitecore26> Are you talking about MASQ/SNAT case ?? well in both NAT cases upto 4000 c/s, everything is pretty same, but at 3,00,000 connections, system is freezed in MASQ/SNAT case, so don't have idea about c/s rate degradation. Regards, Nishit Shah. ----- Original Message ----- From: "Patrick McHardy" To: "Nishit Shah" Cc: Sent: Wednesday, October 11, 2006 11:22 AM Subject: Re: kernel oops with NAT in 2.6.16.13 kernel > Nishit Shah wrote: > > Few more results that will help you, > > > > Test > > Connections/Sec > > Vanila Kernel > > 24000 > > Only conntrack loaded > > 22000 > > Conntrack + NAT module loaded(but no MASQ or SNAT rule in iptables) > > 20000-21000 > > Conntrack + NAT module loaded(MASQ or SNAT rule in iptables) > > 4000 (oops) > > I'm pretty sure its finding an unused tuple thats taking all the time. > Does the c/s rate degrade linear with NAT? > > > From kaber at trash.net Wed Oct 11 09:04:06 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 09:39:54 2006 Subject: kernel oops with NAT in 2.6.16.13 kernel In-Reply-To: <002f01c6ed00$c21c5f20$4c01a8c0@elitecore26> References: <00fb01c6e91d$08bf3570$4c01a8c0@elitecore26> <452B29F2.70105@trash.net> <02a901c6ec2f$f5d1e730$4c01a8c0@elitecore26> <452B372E.3020206@trash.net> <02d001c6ec35$3bf7b870$4c01a8c0@elitecore26> <452C8694.302@trash.net> <002f01c6ed00$c21c5f20$4c01a8c0@elitecore26> Message-ID: <452C9766.4020304@trash.net> Nishit Shah wrote: > Are you talking about MASQ/SNAT case ?? Yes. > well in both NAT cases upto 4000 c/s, everything is pretty same, but at > 3,00,000 connections, system is freezed in MASQ/SNAT case, so don't have > idea about c/s rate degradation. Try SNATing to multiple IPs using multiple rules and some match to distribute the traffic (like matching on even/uneven IPs or something like that). That should show if finding a unique tuple really is the problem. From kaber at trash.net Wed Oct 11 09:28:23 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 10:04:17 2006 Subject: Fw: [Bug 7297] New: modprobe -v -r causes crash in xt_unregister_match In-Reply-To: <20061010124216.74489253@freekitty> References: <20061010124216.74489253@freekitty> Message-ID: <452C9D17.20800@trash.net> Stephen Hemminger wrote: > Looks like an xt_tables bug. Yes, an old one and a new one. I've queued these two patches. -------------- next part -------------- [NETFILTER]: fix cut-and-paste error in exit functions Signed-off-by: Patrick McHardy --- commit c7b1507f3c040c02efa1b955f7180a33a232c4d9 tree fd21258deca0e5d8859271bb2c745302ce5a1e2a parent 26da6cf44bc574d528d715a17e48f54da061c151 author Patrick McHardy Wed, 11 Oct 2006 08:35:50 +0200 committer Patrick McHardy Wed, 11 Oct 2006 08:35:50 +0200 net/netfilter/xt_NFQUEUE.c | 2 +- net/netfilter/xt_connmark.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/xt_NFQUEUE.c b/net/netfilter/xt_NFQUEUE.c index db9b896..39e1175 100644 --- a/net/netfilter/xt_NFQUEUE.c +++ b/net/netfilter/xt_NFQUEUE.c @@ -68,7 +68,7 @@ static int __init xt_nfqueue_init(void) static void __exit xt_nfqueue_fini(void) { - xt_register_targets(xt_nfqueue_target, ARRAY_SIZE(xt_nfqueue_target)); + xt_unregister_targets(xt_nfqueue_target, ARRAY_SIZE(xt_nfqueue_target)); } module_init(xt_nfqueue_init); diff --git a/net/netfilter/xt_connmark.c b/net/netfilter/xt_connmark.c index 92a5726..a8f0305 100644 --- a/net/netfilter/xt_connmark.c +++ b/net/netfilter/xt_connmark.c @@ -147,7 +147,7 @@ static int __init xt_connmark_init(void) static void __exit xt_connmark_fini(void) { - xt_register_matches(xt_connmark_match, ARRAY_SIZE(xt_connmark_match)); + xt_unregister_matches(xt_connmark_match, ARRAY_SIZE(xt_connmark_match)); } module_init(xt_connmark_init); -------------- next part -------------- [NETFILTER]: arp_tables: missing unregistration on module unload Signed-off-by: Patrick McHardy --- commit 7f7a882296c917251a7936b41ee001e545a09e6c tree 9cf7af01ce1b1d8e97caa59d6efceeefab9a3b5b parent c7b1507f3c040c02efa1b955f7180a33a232c4d9 author Patrick McHardy Wed, 11 Oct 2006 09:24:54 +0200 committer Patrick McHardy Wed, 11 Oct 2006 09:24:54 +0200 net/ipv4/netfilter/arp_tables.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c index 17e1a68..0849f1c 100644 --- a/net/ipv4/netfilter/arp_tables.c +++ b/net/ipv4/netfilter/arp_tables.c @@ -1196,6 +1196,8 @@ err1: static void __exit arp_tables_fini(void) { nf_unregister_sockopt(&arpt_sockopts); + xt_unregister_target(&arpt_error_target); + xt_unregister_target(&arpt_standard_target); xt_proto_fini(NF_ARP); } From kaber at trash.net Wed Oct 11 10:41:35 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 11:17:21 2006 Subject: [netfilter-core] linux-2.6.19-rc1 (commit ebf7a227) build failed In-Reply-To: <200610110939.28328.toralf.foerster@gmx.de> References: <200610110939.28328.toralf.foerster@gmx.de> Message-ID: <452CAE3F.7040608@trash.net> Toralf F?rster wrote: > net/built-in.o: In function `xt_connsecmark_init': > xt_CONNSECMARK.c:(.init.text+0xed4): undefined reference to `need_conntrack' > make: *** [.tmp_vmlinux1] Error 1 Thanks, fixed by this patch. BTW, please report non-critical bugs to netfilter-devel only. I know MAINTAINERS says to send them to coreteam@, I'm going to fix that. -------------- next part -------------- [NETFILTER]: xt_CONNSECMARK: fix Kconfig dependencies CONNSECMARK needs conntrack, add missing dependency to fix linking error with CONNSECMARK=y and CONNTRACK=m. Reported by Toralf F?rster . Signed-off-by: Patrick McHardy --- commit 0ab5046ab83e4f0e88c40922701b2bc365f6aa09 tree 4add4ff88904c63e7ff20872f2faff015bbcbc28 parent 889d786a9211434b29e402a501d01a590b072d31 author Patrick McHardy Wed, 11 Oct 2006 10:39:47 +0200 committer Patrick McHardy Wed, 11 Oct 2006 10:39:47 +0200 net/netfilter/Kconfig | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index ce94732..f619c65 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -209,7 +209,9 @@ config NETFILTER_XT_TARGET_SECMARK config NETFILTER_XT_TARGET_CONNSECMARK tristate '"CONNSECMARK" target support' - depends on NETFILTER_XTABLES && (NF_CONNTRACK_SECMARK || IP_NF_CONNTRACK_SECMARK) + depends on NETFILTER_XTABLES && \ + ((NF_CONNTRACK && NF_CONNTRACK_SECMARK) || \ + (IP_NF_CONNTRACK && IP_NF_CONNTRACK_SECMARK)) help The CONNSECMARK target copies security markings from packets to connections, and restores security markings from connections From kaber at trash.net Wed Oct 11 10:51:12 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 11:26:59 2006 Subject: [CTNETLINK] Remove debugging messages In-Reply-To: <452C25A1.1060302@netfilter.org> References: <452C25A1.1060302@netfilter.org> Message-ID: <452CB080.6020004@trash.net> Pablo Neira Ayuso wrote: > Remove debugging messages introduced at early development stage Applied, thanks Pablo. From kaber at trash.net Wed Oct 11 11:02:53 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 12:07:33 2006 Subject: nfq_set_verdict_mark In-Reply-To: <452C33FE.6060902@netfilter.org> References: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> <4521284C.2070000@netfilter.org> <452B2D9A.7080702@trash.net> <452C33FE.6060902@netfilter.org> Message-ID: <452CB33D.8060908@trash.net> Pablo Neira Ayuso wrote: > Patrick McHardy wrote: > >>I'm beginning to wonder how much more kludges we will have in these >>libraries by continuing to treat them as stable without having had >>even a single beta version. > > > OK, I start thinking that I'm getting obsessed with breaking current > deployed apps :(. I also think that we can solve this minor annoying > issues by fixing the problem and then releasing a new version asap. I checked google code-search and the two users I could find already do the conversion manually, so they will break. Thats definitely not good, but I wonder if we should trust that this will be the last of these bugs or if we should clearly mark this as beta/unstable API and appologize for not beeing clear from the beginning. Its just not a good idea to release a library with an interface that is more or less cast in stone without any real testing. > The current release process is too slow, I have the impression that > nobody is using the lastest official releases. For conntrackd, I'm > currently doing unnofficial releases of libnetfilter_conntrack because > the official release is broken with NAT handlings, well apart from the > fact that I also introduce some patches with new features that I need. You're probably right (about people not using official releases) and definitely right about releasing too seldom. > Just tell you that I don't mind about spending some time on > administration tasks like releases and any other stuff related with the > website if that can help to speed up the release process. I worked on > some scripts to automate the release process time ago after the workshop > that I can recover. That would be great. Let me know if you need anything (I think I recall your keys expired?). From kaber at trash.net Wed Oct 11 12:07:20 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 12:43:08 2006 Subject: RTP proxy module In-Reply-To: <016601c6ec40$d693a460$1401a8c0@nyala> References: <016601c6ec40$d693a460$1401a8c0@nyala> Message-ID: <452CC258.6010105@trash.net> Tomas Mandys wrote: >>How is this different from the SIP conntrack/NAT helper, >>which can deal >>(well, not entirely yet) with clients behind NAT as well? > > > There is dedicated port range for RTP proxy, let's say 2000 ports, so > 500 simultaneous calls may "processed" at one moment. One port for RTP, > second RTCP and both for each clients. Note data comming from opposite > direction are engaged in different conntrack (6666->3000, 9000->3002) > and 2 related streams are related each other (RTP, RTCP) > > Implementation via mangler, iptRTPPROXY changes in IP_PRE_ROUTING > callback destination (e.g.9000) address to route correctly, > IP_POST_CALLBACK rewrites source address (e.g.3002). There are more > features, like timeouts, statistics etc. RTP session allocation is > driven by SIP router via libipt_RTPPROXY. Because RTP stream are > specified apart from SIP RTP proxy does not know anything about > Call-id,fromtag,totag but only session-id. SIP router is responsible > from connecting them. SIP is mentioned here as example (I need it for > SIP). > > > Here is simplified scenario (no STUN) > > [..] I'm not sure if iptables is really the best place to implement it, but I'll wait for your code. Please send it to the list once you think its ready. >>We currently only accept patches for patch-o-matic that we have an >>interest in maintaining ourselves (in case the author disappears, >>which happens regulary). The two other possibilities are external >>patch-o-matic repositories and/or an account on people.netfilter.org >>if you just need some webspace to publish it. > > > Maybe a link from netfilter.org to a separate sourceforge/berlios is OK > when you are not interested. We can add a link to an external pom repository. From kaber at trash.net Wed Oct 11 12:32:59 2006 From: kaber at trash.net (Patrick McHardy) Date: Wed Oct 11 13:08:45 2006 Subject: [PATCH] libnfnetlink In-Reply-To: <4521185D.8040005@netfilter.org> References: <1159531818.451d0d2a31b47@www.domainfactory-webmail.de> <451D2B3B.7070604@trash.net> <4521185D.8040005@netfilter.org> Message-ID: <452CC85B.4000105@trash.net> Pablo Neira Ayuso wrote: > what do you think about the following solution? > > >> if (len < sizeof(struct nlmsgerr) >> || len < sizeof(struct nlmsghdr)) > > > errno = EBADMSG; > > >>[...] >> if (addrlen != sizeof(peer)) > > > errno = EINVAL; > > >> return -1; >> >> if (peer.nl_pid != 0) > > > errno = ENOMSG; The above all seem fine. > >> return -1; >> >> nlh = (struct nlmsghdr *)buf; >> if (nlh->nlmsg_flags & MSG_TRUNC || status > len) > > > errno = ENOSPC; ENOSPC is fine for MSG_TRUNC, but it is a msghdr flag, not nlmsg. status > len implies serious recvmsg brokeness and it doesn't really make sense to check for kernel bugs, so I'd remove it. From laforge at netfilter.org Wed Oct 11 16:45:52 2006 From: laforge at netfilter.org (Harald Welte) Date: Wed Oct 11 17:53:32 2006 Subject: problem regarding ftp helper In-Reply-To: <398911740610110725u4c132362pff2223f50640920e@mail.gmail.com> References: <398911740610110725u4c132362pff2223f50640920e@mail.gmail.com> Message-ID: <20061011144552.GD3718@(none)> On Wed, Oct 11, 2006 at 07:55:25PM +0530, manu gautam wrote: > By looking at the source code I cudnt figure out that how come helper > is able to put the port information in the expect structure that it > obtains from PORT command packet in case of active FTP. Other things > are pretty clear in the NAT and CONNTRACK files. I'm not really sure if I understand your question correctly. Are you asking why we create an expectation for active FTP? This is mainly for the case where we have a stateful packet filter (or NAT) in front of a FTP Server (rather than in front of the client). In this case, passive / active are reversed, and we need to track (and possibly nat) the active FTP connections. Please post further questions to the netfilter-devel mailinglist -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/netfilter-devel/attachments/20061011/370bc2e6/attachment.pgp From rbscott at cadvium.net Wed Oct 11 20:56:34 2006 From: rbscott at cadvium.net (robert) Date: Wed Oct 11 21:34:04 2006 Subject: ipq and nf_queue compatibility In-Reply-To: <452C8828.6000005@trash.net> References: <452C8828.6000005@trash.net> Message-ID: is there any sequence that will insure both ipq and nfqueue work? should it just never unbind then? I am a little unclear what the difference is between unregister and unbind? --robert On Oct 10, 2006, at 10:59 PM, Patrick McHardy wrote: > robert wrote: >> Hello, >> >> I am porting a program that uses IPQ to NF_QUEUE, and the port went >> very smoothly, but I noticed that if I run the nfqueue version once, >> the ipq version stops working. The NF_QUEUE version always >> works, but >> the other one simple stops functioning. Is there a known >> incompatibility between the two? Or perhaps is there some global >> state >> that I need to cleanup inside of the NFQUEUE version before I >> execute >> the IPQ version. The kernel has both IPQ and NFQUEUE support. >> >> This happens regardless of whether or not I call the function >> nfq_unbind_pf on exit. Not really sure what that function does, >> but it >> was inside of nfqnl_test.c, so I tried it out. > > ip_queue only registeres itself when the module is loaded, > nfnetlink_queue registeres when NFQNL_CFG_CMD_PF_BIND is > received. So once ip_queue has been unregistered it never > registeres again and doesn't receive any packets anymore. > From shemminger at osdl.org Wed Oct 11 22:04:13 2006 From: shemminger at osdl.org (Stephen Hemminger) Date: Wed Oct 11 22:41:43 2006 Subject: [PATCH] Add TCPCONG target to patch-o-matic In-Reply-To: <452C81E2.1040206@trash.net> References: <45235EDC.4080709@aarnet.edu.au> <4524118B.4020903@netfilter.org> <4524BBB2.2000109@aarnet.edu.au> <452A66CA.70603@trash.net> <452B4512.4070705@aarnet.edu.au> <452C81E2.1040206@trash.net> Message-ID: <20061011130413.6d44063f@freekitty> On Wed, 11 Oct 2006 07:32:18 +0200 Patrick McHardy wrote: > Glen Turner wrote: > > Patrick McHardy wrote: > > > >> I don't think iptables is the right place to do this. It should > >> be controllable through routing IMO (which can already control > >> some aspects of congestion control). > > > > > > I too think the choice should usually be done through routing, > > with the route holding the preferred congestion control algorithm > > for traffic with that prefix. Whereas now the preferred algorithm > > is read from a global parameter. > > > > But the algorithm for a particular connection should still be > > able to be changed through iptables. > > > > Firstly, not every application can be easily altered to use > > setsockopt() to select a differing algorithm from the default. > > This is the argument used for the TCPMSS and similar targets. > > The difference is that TCPMSS changes packet data (also for > forwarded packets) and doesn't fiddle around with sockets. > > > As the range of congestion control algorithms grows sysadmins > > will want to choose differing algorithms for differing > > applications. For example, most algorithm's Ack strategies > > interact poorly with transactional and remote procedure call > > traffic, so choosing an algorithm which handles this well > > could make, say, NFS over TCP traffic run a lot faster. That's a problem with delayed ack's not the congestion control stuff. > > Secondly, I want to make it easy for kernel and protocol > > developers to run differing algorithms on differing port > > numbers to test inter-algorithm fairness. Some TCP algorithms > > are quite unfair -- unable even to share a link 50:50 between > > two identical flows started a few seconds apart. A TCPCONG > > target makes it much easier to do this testing. Now that the > > kernel developers are getting good performance on long fat > > pipes the fairness and other attributes of that performance > > will be their next concern. > > It still strikes me as a bit of a hack. Lets see what Stephen > thinks. > I don't like iptables interacting back with the socket state. The only congestion control that makes sense to be application specific is the TCP-LP stuff. The others are just duking it out, to see which one should be the default. I want to put the congestion choice in the route metrics as an option, just haven't got around to doing it that way. The only advantage do doing it in IP tables is that you can make rules by port etc. -- Stephen Hemminger From lucholaf at gmail.com Wed Oct 11 22:33:13 2006 From: lucholaf at gmail.com (Luis Floreani) Date: Wed Oct 11 23:10:32 2006 Subject: new match extension to implement port knocking in one Message-ID: > If you're interested in port knocking, you might want to read this > paper: http://www.acsac.org/2005/abstracts/156.html It covers security > issues relating to port knocking in detail, and presents an architecture > for solving most of them. > > Full disclosure: I wrote that paper. Feel free to contact me if you > have questions. > > Rennie deGraaf > In our implementation, for security, we are using the Tumbler protocol, we found it simple yet powerful, check it out here: http://tumbler.sourceforge.net/. Well, hope to read you paper soon and give you some feedback. Luis From fede.hernandez at gmail.com Wed Oct 11 22:44:04 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Wed Oct 11 23:21:23 2006 Subject: new match extension to implement port knocking in one Message-ID: Rennie deGraaf wrote: > If you're interested in port knocking, you might want to read this > paper: http://www.acsac.org/2005/abstracts/156.html It covers security > issues relating to port knocking in detail, and presents an architecture > for solving most of them. > Full disclosure: I wrote that paper. Feel free to contact me if you > have questions. Hi, I'm one of the developers of the netfilter extension to use portknocking. In our implementation, for security, we are using the Tumbler protocol, we found it simple yet powerful, check it out here: http://tumbler.sourceforge.net/. Well, hope to read you paper soon and give you some feedback. Tell me what you think about our protocol. -- Federico From pablo at netfilter.org Wed Oct 11 23:47:34 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu Oct 12 00:18:28 2006 Subject: nfq_set_verdict_mark In-Reply-To: <452CB33D.8060908@trash.net> References: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> <4521284C.2070000@netfilter.org> <452B2D9A.7080702@trash.net> <452C33FE.6060902@netfilter.org> <452CB33D.8060908@trash.net> Message-ID: <452D6676.8090700@netfilter.org> Patrick McHardy wrote: > Pablo Neira Ayuso wrote: >> Patrick McHardy wrote: >> >>> I'm beginning to wonder how much more kludges we will have in these >>> libraries by continuing to treat them as stable without having had >>> even a single beta version. >> >> OK, I start thinking that I'm getting obsessed with breaking current >> deployed apps :(. I also think that we can solve this minor annoying >> issues by fixing the problem and then releasing a new version asap. > > I checked google code-search and the two users I could find already > do the conversion manually, so they will break. Thats definitely not > good, but I wonder if we should trust that this will be the last > of these bugs or if we should clearly mark this as beta/unstable API > and appologize for not beeing clear from the beginning. Its just > not a good idea to release a library with an interface that is more > or less cast in stone without any real testing. We can warn about incompatibilities in the announce of new releases for this kind of minor issues that we need to fix up and that result in breakages, some kind of "heads up" section. For the rest of the API, I remember that in one of my discussions with Harald we conclude that is better to introduce new API than breaking current just not to annoy users. We can strongly recommend the use of the new API and mark old one as deprecated (with the gcc attribute) to warn users that such obsolete function will vanish soon. That would stagger changes. >> The current release process is too slow, I have the impression that >> nobody is using the lastest official releases. For conntrackd, I'm >> currently doing unnofficial releases of libnetfilter_conntrack because >> the official release is broken with NAT handlings, well apart from the >> fact that I also introduce some patches with new features that I need. > > You're probably right (about people not using official releases) and > definitely right about releasing too seldom. > >> Just tell you that I don't mind about spending some time on >> administration tasks like releases and any other stuff related with the >> website if that can help to speed up the release process. I worked on >> some scripts to automate the release process time ago after the workshop >> that I can recover. > > That would be great. Let me know if you need anything (I think I recall > your keys expired?). I need to renew my key in order to tag new releases in SVN, I also need to generate some kind of "release master GPG key" or something in other to sign new releases. -- 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 glen.turner at aarnet.edu.au Thu Oct 12 02:37:04 2006 From: glen.turner at aarnet.edu.au (Glen Turner) Date: Thu Oct 12 03:14:41 2006 Subject: [PATCH] Add TCPCONG target to patch-o-matic In-Reply-To: <20061011130413.6d44063f@freekitty> References: <45235EDC.4080709@aarnet.edu.au> <4524118B.4020903@netfilter.org> <4524BBB2.2000109@aarnet.edu.au> <452A66CA.70603@trash.net> <452B4512.4070705@aarnet.edu.au> <452C81E2.1040206@trash.net> <20061011130413.6d44063f@freekitty> Message-ID: <452D8E30.5010909@aarnet.edu.au> Stephen Hemminger wrote: > I don't like iptables interacting back with the socket state. Sounds like a no to me :-) Patrick, what's the easiest way to maintain this out of Netfilter? As a patch to patch-o-matic or as a direct patch to iptables and the kernel? [ For those following this from the archive at some time in the future, I'll put the patch at ] > The only congestion control that makes sense to be application specific > is the TCP-LP stuff. The others are just duking it out, to see which > one should be the default. I'd expect to see more application-specific and link-specific algorithms in the future. In the long run you might need more pseudo-algorithms (eg: "default-lossy-link" to select the kernel's default algorithm for wireless links). > I want to put the congestion choice in the route metrics as an option, > just haven't got around to doing it that way. The only advantage do > doing it in IP tables is that you can make rules by port etc. I think it's more complex than that to get a nice behaviour: socket, which gets its default from route, which gets its default from interface, which get its default from the global sysctl. I'm not sure how much of this behaviour can be implemented from user space. Thanks for your response, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au From kaber at trash.net Thu Oct 12 02:57:34 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 03:35:00 2006 Subject: [PATCH] Add TCPCONG target to patch-o-matic In-Reply-To: <452D8E30.5010909@aarnet.edu.au> References: <45235EDC.4080709@aarnet.edu.au> <4524118B.4020903@netfilter.org> <4524BBB2.2000109@aarnet.edu.au> <452A66CA.70603@trash.net> <452B4512.4070705@aarnet.edu.au> <452C81E2.1040206@trash.net> <20061011130413.6d44063f@freekitty> <452D8E30.5010909@aarnet.edu.au> Message-ID: <452D92FE.7020707@trash.net> Glen Turner wrote: > Patrick, what's the easiest way to maintain this out of Netfilter? > As a patch to patch-o-matic or as a direct patch to iptables and > the kernel? I depends on your workflow I guess. I personally prefer to keep patches in git trees, for long-term maintenance patch-o-matic might save you a bit of work by resolving Kconfig and Makefile conflicts automatically. If you're going to set up an external patch-o-matic repository we can add it to the distributed sources.list if you want. From kaber at trash.net Thu Oct 12 02:59:44 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 03:37:06 2006 Subject: ipq and nf_queue compatibility In-Reply-To: References: <452C8828.6000005@trash.net> Message-ID: <452D9380.7030803@trash.net> robert wrote: > is there any sequence that will insure both ipq and nfqueue work? > should it just never unbind then? I am a little unclear what the > difference is between unregister and unbind? You need to unload/reload the ip_queue module if you want it to register again after "unbinding" nfnetlink_queue from AF_INET. From eric at inl.fr Thu Oct 12 08:35:39 2006 From: eric at inl.fr (Eric Leblond) Date: Thu Oct 12 09:13:13 2006 Subject: nfq_set_verdict_mark In-Reply-To: <452D6676.8090700@netfilter.org> References: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> <4521284C.2070000@netfilter.org> <452B2D9A.7080702@trash.net> <452C33FE.6060902@netfilter.org> <452CB33D.8060908@trash.net> <452D6676.8090700@netfilter.org> Message-ID: <1160634939.24065.8.camel@localhost> Le mercredi 11 octobre 2006 ? 23:47 +0200, Pablo Neira Ayuso a ?crit : > We can warn about incompatibilities in the announce of new releases for > this kind of minor issues that we need to fix up and that result in > breakages, some kind of "heads up" section. Why not to add a API release number in the code. As developper of NuFW, I've got no problem to change my code but, I need a way to have my users not bored when they use my software. In fact I can not control which version of libnetfilter_queue. Something like "#define NFQUEUE_API_VERSION NNN" in libnetfilter_queue.h could really be used easily in application code to detect which flavour of the API they need to use. BR, -- Regit > > For the rest of the API, I remember that in one of my discussions with > Harald we conclude that is better to introduce new API than breaking > current just not to annoy users. We can strongly recommend the use of > the new API and mark old one as deprecated (with the gcc attribute) to > warn users that such obsolete function will vanish soon. That would > stagger changes. > > >> The current release process is too slow, I have the impression that > >> nobody is using the lastest official releases. For conntrackd, I'm > >> currently doing unnofficial releases of libnetfilter_conntrack because > >> the official release is broken with NAT handlings, well apart from the > >> fact that I also introduce some patches with new features that I need. > > > > You're probably right (about people not using official releases) and > > definitely right about releasing too seldom. > > > >> Just tell you that I don't mind about spending some time on > >> administration tasks like releases and any other stuff related with the > >> website if that can help to speed up the release process. I worked on > >> some scripts to automate the release process time ago after the workshop > >> that I can recover. > > > > That would be great. Let me know if you need anything (I think I recall > > your keys expired?). > > I need to renew my key in order to tag new releases in SVN, I also need > to generate some kind of "release master GPG key" or something in other > to sign new releases. > -- Eric Leblond INL -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : /pipermail/netfilter-devel/attachments/20061012/261726f0/attachment.pgp From yasuyuki.kozakai at toshiba.co.jp Thu Oct 12 10:11:02 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Oct 12 10:48:37 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610032258.30338@auguste.remlab.net> References: <200610021747.42658@auguste.remlab.net> <200610031430.k93EUJgA008197@toshiba.co.jp> <200610032258.30338@auguste.remlab.net> Message-ID: <200610120811.k9C8B3GM025472@toshiba.co.jp> Hello, sorry for late replying. From: R?mi Denis-Courmont Date: Tue, 3 Oct 2006 22:58:28 +0300 > Le mardi 3 octobre 2006 17:30, vous avez ?crit : > > IPv4 multiport match (and policy match, too) would help you. It has > > the line > > > > #include ../../include/netfilter_ipv4/ipt_multiport.h > > > > and definitions for old kernel are included in the header. > > Ok. This time there is no trace of (xt|XT)_ at all: ??? Did you send intended patch ? It includes XT_MULTI_PORTS as folows. > diff -Nru iptables-1.3.5.orig/extensions/libip6t_multiport.c > iptables-1.3.5/extensions/libip6t_multiport.c > --- iptables-1.3.5.orig/extensions/libip6t_multiport.c 2005-02-19 > 21:19:17.000000000 +0200 > +++ iptables-1.3.5/extensions/libip6t_multiport.c 2006-08-27 > 13:03:36.000000000 +0300 > @@ -20,6 +20,23 @@ > " --dports ...\n" > " match destination port(s)\n" > " --ports port[,port,port]\n" snip > + for (i=0; i + multiinfo->pflags[i] = 0; > + And I noticed that your mailer breaks the patch. For example, > + printf(" "); > +} > + > /* Saves the union ip6t_matchinfo in parsable form to stdout. */ > static void save(const struct ip6t_ip6 *ip, const struct > ip6t_entry_match *match) > { > @@ -246,6 +392,41 @@ > printf(" "); > } ip6t_entry_match *match) is moved to next line. That should be after "const struct ". Regards, -- Yasuyuki Kozakai From kaber at trash.net Thu Oct 12 11:54:18 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 12:31:49 2006 Subject: [NETFILTER 00/06]: Netfilter fixes Message-ID: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Hi Dave, following are a few netfilter fixes for 2.6.19. Please apply, thanks. MAINTAINERS | 8 ++- net/ipv4/netfilter/arp_tables.c | 2 net/ipv4/netfilter/ip_conntrack_netlink.c | 72 +----------------------------- net/ipv4/netfilter/ipt_ECN.c | 6 +- net/ipv4/netfilter/ipt_TOS.c | 6 +- net/netfilter/Kconfig | 4 + net/netfilter/nf_conntrack_netlink.c | 72 +----------------------------- net/netfilter/xt_NFQUEUE.c | 2 net/netfilter/xt_connmark.c | 2 9 files changed, 24 insertions(+), 150 deletions(-) Pablo Neira Ayuso: [NETFILTER]: ctnetlink: Remove debugging messages Patrick McHardy: [NETFILTER]: fix cut-and-paste error in exit functions [NETFILTER]: arp_tables: missing unregistration on module unload [NETFILTER]: ipt_ECN/ipt_TOS: fix incorrect checksum update [NETFILTER]: xt_CONNSECMARK: fix Kconfig dependencies [NETFILTER]: Update MAINTAINERS entry From kaber at trash.net Thu Oct 12 11:54:24 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 12:31:54 2006 Subject: [NETFILTER 04/06]: xt_CONNSECMARK: fix Kconfig dependencies In-Reply-To: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> References: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Message-ID: <20061012095552.11462.86418.sendpatchset@localhost.localdomain> [NETFILTER]: xt_CONNSECMARK: fix Kconfig dependencies CONNSECMARK needs conntrack, add missing dependency to fix linking error with CONNSECMARK=y and CONNTRACK=m. Reported by Toralf Förster . Signed-off-by: Patrick McHardy --- commit 0ab5046ab83e4f0e88c40922701b2bc365f6aa09 tree 4add4ff88904c63e7ff20872f2faff015bbcbc28 parent 889d786a9211434b29e402a501d01a590b072d31 author Patrick McHardy Wed, 11 Oct 2006 10:39:47 +0200 committer Patrick McHardy Wed, 11 Oct 2006 10:39:47 +0200 net/netfilter/Kconfig | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index ce94732..f619c65 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -209,7 +209,9 @@ config NETFILTER_XT_TARGET_SECMARK config NETFILTER_XT_TARGET_CONNSECMARK tristate '"CONNSECMARK" target support' - depends on NETFILTER_XTABLES && (NF_CONNTRACK_SECMARK || IP_NF_CONNTRACK_SECMARK) + depends on NETFILTER_XTABLES && \ + ((NF_CONNTRACK && NF_CONNTRACK_SECMARK) || \ + (IP_NF_CONNTRACK && IP_NF_CONNTRACK_SECMARK)) help The CONNSECMARK target copies security markings from packets to connections, and restores security markings from connections From kaber at trash.net Thu Oct 12 11:54:22 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 12:31:55 2006 Subject: [NETFILTER 03/06]: ipt_ECN/ipt_TOS: fix incorrect checksum update In-Reply-To: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> References: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Message-ID: <20061012095551.11462.57093.sendpatchset@localhost.localdomain> [NETFILTER]: ipt_ECN/ipt_TOS: fix incorrect checksum update Even though the tos field is only a single byte large, the values need to be converted to net-endian for the checkum update so they are in the corrent byte position. Also fix incorrect endian annotations. Reported by Stephane Chazelas Signed-off-by: Patrick McHardy --- commit 889d786a9211434b29e402a501d01a590b072d31 tree 2290ec865a25bb99171ab4c44ea6c463df13a3b1 parent 7f7a882296c917251a7936b41ee001e545a09e6c author Patrick McHardy Wed, 11 Oct 2006 10:07:57 +0200 committer Patrick McHardy Wed, 11 Oct 2006 10:07:57 +0200 net/ipv4/netfilter/ipt_ECN.c | 6 +++--- net/ipv4/netfilter/ipt_TOS.c | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/net/ipv4/netfilter/ipt_ECN.c b/net/ipv4/netfilter/ipt_ECN.c index 12a818a..1aa4517 100644 --- a/net/ipv4/netfilter/ipt_ECN.c +++ b/net/ipv4/netfilter/ipt_ECN.c @@ -28,7 +28,7 @@ static inline int set_ect_ip(struct sk_buff **pskb, const struct ipt_ECN_info *einfo) { struct iphdr *iph = (*pskb)->nh.iph; - __be16 oldtos; + u_int16_t oldtos; if ((iph->tos & IPT_ECN_IP_MASK) != (einfo->ip_ect & IPT_ECN_IP_MASK)) { if (!skb_make_writable(pskb, sizeof(struct iphdr))) @@ -37,8 +37,8 @@ set_ect_ip(struct sk_buff **pskb, const oldtos = iph->tos; iph->tos &= ~IPT_ECN_IP_MASK; iph->tos |= (einfo->ip_ect & IPT_ECN_IP_MASK); - iph->check = nf_csum_update(oldtos ^ htons(0xFFFF), iph->tos, - iph->check); + iph->check = nf_csum_update(htons(oldtos) ^ htons(0xFFFF), + htons(iph->tos), iph->check); } return 1; } diff --git a/net/ipv4/netfilter/ipt_TOS.c b/net/ipv4/netfilter/ipt_TOS.c index 6b8b14c..83b80b3 100644 --- a/net/ipv4/netfilter/ipt_TOS.c +++ b/net/ipv4/netfilter/ipt_TOS.c @@ -30,7 +30,7 @@ target(struct sk_buff **pskb, { const struct ipt_tos_target_info *tosinfo = targinfo; struct iphdr *iph = (*pskb)->nh.iph; - __be16 oldtos; + u_int16_t oldtos; if ((iph->tos & IPTOS_TOS_MASK) != tosinfo->tos) { if (!skb_make_writable(pskb, sizeof(struct iphdr))) @@ -38,8 +38,8 @@ target(struct sk_buff **pskb, iph = (*pskb)->nh.iph; oldtos = iph->tos; iph->tos = (iph->tos & IPTOS_PREC_MASK) | tosinfo->tos; - iph->check = nf_csum_update(oldtos ^ htons(0xFFFF), iph->tos, - iph->check); + iph->check = nf_csum_update(htons(oldtos) ^ htons(0xFFFF), + htons(iph->tos), iph->check); } return IPT_CONTINUE; } From kaber at trash.net Thu Oct 12 11:54:21 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 12:31:55 2006 Subject: [NETFILTER 02/06]: arp_tables: missing unregistration on module unload In-Reply-To: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> References: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Message-ID: <20061012095550.11462.1768.sendpatchset@localhost.localdomain> [NETFILTER]: arp_tables: missing unregistration on module unload Signed-off-by: Patrick McHardy --- commit 7f7a882296c917251a7936b41ee001e545a09e6c tree 9cf7af01ce1b1d8e97caa59d6efceeefab9a3b5b parent c7b1507f3c040c02efa1b955f7180a33a232c4d9 author Patrick McHardy Wed, 11 Oct 2006 09:24:54 +0200 committer Patrick McHardy Wed, 11 Oct 2006 09:24:54 +0200 net/ipv4/netfilter/arp_tables.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c index 17e1a68..0849f1c 100644 --- a/net/ipv4/netfilter/arp_tables.c +++ b/net/ipv4/netfilter/arp_tables.c @@ -1196,6 +1196,8 @@ err1: static void __exit arp_tables_fini(void) { nf_unregister_sockopt(&arpt_sockopts); + xt_unregister_target(&arpt_error_target); + xt_unregister_target(&arpt_standard_target); xt_proto_fini(NF_ARP); } From kaber at trash.net Thu Oct 12 11:54:20 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 12:31:58 2006 Subject: [NETFILTER 01/06]: fix cut-and-paste error in exit functions In-Reply-To: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> References: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Message-ID: <20061012095548.11462.69520.sendpatchset@localhost.localdomain> [NETFILTER]: fix cut-and-paste error in exit functions Signed-off-by: Patrick McHardy --- commit c7b1507f3c040c02efa1b955f7180a33a232c4d9 tree fd21258deca0e5d8859271bb2c745302ce5a1e2a parent 26da6cf44bc574d528d715a17e48f54da061c151 author Patrick McHardy Wed, 11 Oct 2006 08:35:50 +0200 committer Patrick McHardy Wed, 11 Oct 2006 08:35:50 +0200 net/netfilter/xt_NFQUEUE.c | 2 +- net/netfilter/xt_connmark.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/xt_NFQUEUE.c b/net/netfilter/xt_NFQUEUE.c index db9b896..39e1175 100644 --- a/net/netfilter/xt_NFQUEUE.c +++ b/net/netfilter/xt_NFQUEUE.c @@ -68,7 +68,7 @@ static int __init xt_nfqueue_init(void) static void __exit xt_nfqueue_fini(void) { - xt_register_targets(xt_nfqueue_target, ARRAY_SIZE(xt_nfqueue_target)); + xt_unregister_targets(xt_nfqueue_target, ARRAY_SIZE(xt_nfqueue_target)); } module_init(xt_nfqueue_init); diff --git a/net/netfilter/xt_connmark.c b/net/netfilter/xt_connmark.c index 92a5726..a8f0305 100644 --- a/net/netfilter/xt_connmark.c +++ b/net/netfilter/xt_connmark.c @@ -147,7 +147,7 @@ static int __init xt_connmark_init(void) static void __exit xt_connmark_fini(void) { - xt_register_matches(xt_connmark_match, ARRAY_SIZE(xt_connmark_match)); + xt_unregister_matches(xt_connmark_match, ARRAY_SIZE(xt_connmark_match)); } module_init(xt_connmark_init); From kaber at trash.net Thu Oct 12 11:54:25 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 12:31:59 2006 Subject: [NETFILTER 05/06]: Update MAINTAINERS entry In-Reply-To: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> References: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Message-ID: <20061012095554.11462.37340.sendpatchset@localhost.localdomain> [NETFILTER]: Update MAINTAINERS entry Patches should go to myself CC netfilter-devel. Signed-off-by: Patrick McHardy --- commit 8a09f6627c34d4d38ce70377346de18f098937b2 tree c51ffb59734f7ff552c31c69fb3dc25d58606fd7 parent 0ab5046ab83e4f0e88c40922701b2bc365f6aa09 author Patrick McHardy Wed, 11 Oct 2006 10:46:10 +0200 committer Patrick McHardy Wed, 11 Oct 2006 10:46:10 +0200 MAINTAINERS | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 17becb9..a3033a3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2040,11 +2040,13 @@ P: Marc Boucher P: James Morris P: Harald Welte P: Jozsef Kadlecsik -M: coreteam@netfilter.org +P: Patrick McHardy +M: kaber@trash.net +L: netfilter-devel@lists.netfilter.org +L: netfilter@lists.netfilter.org +L: coreteam@netfilter.org W: http://www.netfilter.org/ W: http://www.iptables.org/ -L: netfilter@lists.netfilter.org -L: netfilter-devel@lists.netfilter.org S: Supported NETLABEL From kaber at trash.net Thu Oct 12 11:54:26 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 12:32:00 2006 Subject: [NETFILTER 06/06]: ctnetlink: Remove debugging messages In-Reply-To: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> References: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Message-ID: <20061012095555.11462.20916.sendpatchset@localhost.localdomain> [NETFILTER]: ctnetlink: Remove debugging messages Remove (compilation-breaking) debugging messages introduced at early development stage. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Patrick McHardy --- commit 98a2b2e08556f6269f822594569db42c24160189 tree 060af727f228e84b390ab2b25e847f9318945f34 parent 8a09f6627c34d4d38ce70377346de18f098937b2 author Pablo Neira Ayuso Wed, 11 Oct 2006 10:50:09 +0200 committer Patrick McHardy Wed, 11 Oct 2006 10:50:09 +0200 net/ipv4/netfilter/ip_conntrack_netlink.c | 72 +---------------------------- net/netfilter/nf_conntrack_netlink.c | 72 +---------------------------- 2 files changed, 6 insertions(+), 138 deletions(-) diff --git a/net/ipv4/netfilter/ip_conntrack_netlink.c b/net/ipv4/netfilter/ip_conntrack_netlink.c index 53b6dff..262d0d4 100644 --- a/net/ipv4/netfilter/ip_conntrack_netlink.c +++ b/net/ipv4/netfilter/ip_conntrack_netlink.c @@ -44,13 +44,6 @@ MODULE_LICENSE("GPL"); static char __initdata version[] = "0.90"; -#if 0 -#define DEBUGP printk -#else -#define DEBUGP(format, args...) -#endif - - static inline int ctnetlink_dump_tuples_proto(struct sk_buff *skb, const struct ip_conntrack_tuple *tuple, @@ -398,7 +391,6 @@ #endif /* CONFIG_IP_NF_CONNTRACK_EVENTS static int ctnetlink_done(struct netlink_callback *cb) { - DEBUGP("entered %s\n", __FUNCTION__); if (cb->args[1]) ip_conntrack_put((struct ip_conntrack *)cb->args[1]); return 0; @@ -411,9 +403,6 @@ ctnetlink_dump_table(struct sk_buff *skb struct ip_conntrack_tuple_hash *h; struct list_head *i; - DEBUGP("entered %s, last bucket=%lu id=%u\n", __FUNCTION__, - cb->args[0], *id); - read_lock_bh(&ip_conntrack_lock); last = (struct ip_conntrack *)cb->args[1]; for (; cb->args[0] < ip_conntrack_htable_size; cb->args[0]++) { @@ -452,7 +441,6 @@ out: if (last) ip_conntrack_put(last); - DEBUGP("leaving, last bucket=%lu id=%u\n", cb->args[0], *id); return skb->len; } @@ -466,8 +454,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * { struct nfattr *tb[CTA_IP_MAX]; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_IP_MAX, attr); if (nfattr_bad_size(tb, CTA_IP_MAX, cta_min_ip)) @@ -481,8 +467,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * return -EINVAL; tuple->dst.ip = *(__be32 *)NFA_DATA(tb[CTA_IP_V4_DST-1]); - DEBUGP("leaving\n"); - return 0; } @@ -503,8 +487,6 @@ ctnetlink_parse_tuple_proto(struct nfatt struct ip_conntrack_protocol *proto; int ret = 0; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTO_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTO_MAX, cta_min_proto)) @@ -531,8 +513,6 @@ ctnetlink_parse_tuple(struct nfattr *cda struct nfattr *tb[CTA_TUPLE_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(tuple, 0, sizeof(*tuple)); nfattr_parse_nested(tb, CTA_TUPLE_MAX, cda[type-1]); @@ -557,10 +537,6 @@ ctnetlink_parse_tuple(struct nfattr *cda else tuple->dst.dir = IP_CT_DIR_ORIGINAL; - DUMP_TUPLE(tuple); - - DEBUGP("leaving\n"); - return 0; } @@ -577,8 +553,6 @@ static int ctnetlink_parse_nat_proto(str struct nfattr *tb[CTA_PROTONAT_MAX]; struct ip_nat_protocol *npt; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTONAT_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTONAT_MAX, cta_min_protonat)) @@ -597,7 +571,6 @@ static int ctnetlink_parse_nat_proto(str ip_nat_proto_put(npt); - DEBUGP("leaving\n"); return 0; } @@ -613,8 +586,6 @@ ctnetlink_parse_nat(struct nfattr *nat, struct nfattr *tb[CTA_NAT_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(range, 0, sizeof(*range)); nfattr_parse_nested(tb, CTA_NAT_MAX, nat); @@ -640,7 +611,6 @@ ctnetlink_parse_nat(struct nfattr *nat, if (err < 0) return err; - DEBUGP("leaving\n"); return 0; } #endif @@ -650,8 +620,6 @@ ctnetlink_parse_help(struct nfattr *attr { struct nfattr *tb[CTA_HELP_MAX]; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_HELP_MAX, attr); if (!tb[CTA_HELP_NAME-1]) @@ -679,8 +647,6 @@ ctnetlink_del_conntrack(struct sock *ctn struct ip_conntrack *ct; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -698,10 +664,8 @@ ctnetlink_del_conntrack(struct sock *ctn return err; h = ip_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash\n"); + if (!h) return -ENOENT; - } ct = tuplehash_to_ctrack(h); @@ -716,7 +680,6 @@ ctnetlink_del_conntrack(struct sock *ctn ct->timeout.function((unsigned long)ct); ip_conntrack_put(ct); - DEBUGP("leaving\n"); return 0; } @@ -731,8 +694,6 @@ ctnetlink_get_conntrack(struct sock *ctn struct sk_buff *skb2 = NULL; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nlh->nlmsg_flags & NLM_F_DUMP) { struct nfgenmsg *msg = NLMSG_DATA(nlh); u32 rlen; @@ -770,11 +731,9 @@ #endif return err; h = ip_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash"); + if (!h) return -ENOENT; - } - DEBUGP("tuple found\n"); + ct = tuplehash_to_ctrack(h); err = -ENOMEM; @@ -795,7 +754,6 @@ #endif if (err < 0) goto out; - DEBUGP("leaving\n"); return 0; free: @@ -866,8 +824,6 @@ ctnetlink_change_helper(struct ip_conntr char *helpname; int err; - DEBUGP("entered %s\n", __FUNCTION__); - /* don't change helper of sibling connections */ if (ct->master) return -EINVAL; @@ -938,8 +894,6 @@ ctnetlink_change_conntrack(struct ip_con { int err; - DEBUGP("entered %s\n", __FUNCTION__); - if (cda[CTA_HELP-1]) { err = ctnetlink_change_helper(ct, cda); if (err < 0) @@ -969,7 +923,6 @@ #if defined(CONFIG_IP_NF_CONNTRACK_MARK) ct->mark = ntohl(*(__be32 *)NFA_DATA(cda[CTA_MARK-1])); #endif - DEBUGP("all done\n"); return 0; } @@ -981,8 +934,6 @@ ctnetlink_create_conntrack(struct nfattr struct ip_conntrack *ct; int err = -EINVAL; - DEBUGP("entered %s\n", __FUNCTION__); - ct = ip_conntrack_alloc(otuple, rtuple); if (ct == NULL || IS_ERR(ct)) return -ENOMEM; @@ -1017,7 +968,6 @@ #endif if (ct->helper) ip_conntrack_helper_put(ct->helper); - DEBUGP("conntrack with id %u inserted\n", ct->id); return 0; err: @@ -1033,8 +983,6 @@ ctnetlink_new_conntrack(struct sock *ctn struct ip_conntrack_tuple_hash *h = NULL; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -1058,7 +1006,6 @@ ctnetlink_new_conntrack(struct sock *ctn if (h == NULL) { write_unlock_bh(&ip_conntrack_lock); - DEBUGP("no such conntrack, create new\n"); err = -ENOENT; if (nlh->nlmsg_flags & NLM_F_CREATE) err = ctnetlink_create_conntrack(cda, &otuple, &rtuple); @@ -1074,7 +1021,6 @@ ctnetlink_new_conntrack(struct sock *ctn /* We manipulate the conntrack inside the global conntrack table lock, * so there's no need to increase the refcount */ - DEBUGP("conntrack found\n"); err = -EEXIST; if (!(nlh->nlmsg_flags & NLM_F_EXCL)) err = ctnetlink_change_conntrack(tuplehash_to_ctrack(h), cda); @@ -1249,8 +1195,6 @@ ctnetlink_exp_dump_table(struct sk_buff struct list_head *i; u_int32_t *id = (u_int32_t *) &cb->args[0]; - DEBUGP("entered %s, last id=%llu\n", __FUNCTION__, *id); - read_lock_bh(&ip_conntrack_lock); list_for_each_prev(i, &ip_conntrack_expect_list) { exp = (struct ip_conntrack_expect *) i; @@ -1266,8 +1210,6 @@ ctnetlink_exp_dump_table(struct sk_buff out: read_unlock_bh(&ip_conntrack_lock); - DEBUGP("leaving, last id=%llu\n", *id); - return skb->len; } @@ -1285,8 +1227,6 @@ ctnetlink_get_expect(struct sock *ctnl, struct sk_buff *skb2; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1437,8 +1377,6 @@ ctnetlink_create_expect(struct nfattr *c struct ip_conntrack *ct; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - /* caller guarantees that those three CTA_EXPECT_* exist */ err = ctnetlink_parse_tuple(cda, &tuple, CTA_EXPECT_TUPLE); if (err < 0) @@ -1490,8 +1428,6 @@ ctnetlink_new_expect(struct sock *ctnl, struct ip_conntrack_expect *exp; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1520,8 +1456,6 @@ ctnetlink_new_expect(struct sock *ctnl, err = ctnetlink_change_expect(exp, cda); write_unlock_bh(&ip_conntrack_lock); - DEBUGP("leaving\n"); - return err; } diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index 1721f7c..13cb409 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -47,13 +47,6 @@ MODULE_LICENSE("GPL"); static char __initdata version[] = "0.93"; -#if 0 -#define DEBUGP printk -#else -#define DEBUGP(format, args...) -#endif - - static inline int ctnetlink_dump_tuples_proto(struct sk_buff *skb, const struct nf_conntrack_tuple *tuple, @@ -410,7 +403,6 @@ static int ctnetlink_done(struct netlink { if (cb->args[1]) nf_ct_put((struct nf_conn *)cb->args[1]); - DEBUGP("entered %s\n", __FUNCTION__); return 0; } @@ -425,9 +417,6 @@ ctnetlink_dump_table(struct sk_buff *skb struct nfgenmsg *nfmsg = NLMSG_DATA(cb->nlh); u_int8_t l3proto = nfmsg->nfgen_family; - DEBUGP("entered %s, last bucket=%lu id=%u\n", __FUNCTION__, - cb->args[0], *id); - read_lock_bh(&nf_conntrack_lock); last = (struct nf_conn *)cb->args[1]; for (; cb->args[0] < nf_conntrack_htable_size; cb->args[0]++) { @@ -471,7 +460,6 @@ out: if (last) nf_ct_put(last); - DEBUGP("leaving, last bucket=%lu id=%u\n", cb->args[0], *id); return skb->len; } @@ -482,8 +470,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * struct nf_conntrack_l3proto *l3proto; int ret = 0; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_IP_MAX, attr); l3proto = nf_ct_l3proto_find_get(tuple->src.l3num); @@ -493,8 +479,6 @@ ctnetlink_parse_tuple_ip(struct nfattr * nf_ct_l3proto_put(l3proto); - DEBUGP("leaving\n"); - return ret; } @@ -510,8 +494,6 @@ ctnetlink_parse_tuple_proto(struct nfatt struct nf_conntrack_protocol *proto; int ret = 0; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTO_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTO_MAX, cta_min_proto)) @@ -538,8 +520,6 @@ ctnetlink_parse_tuple(struct nfattr *cda struct nfattr *tb[CTA_TUPLE_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(tuple, 0, sizeof(*tuple)); nfattr_parse_nested(tb, CTA_TUPLE_MAX, cda[type-1]); @@ -566,10 +546,6 @@ ctnetlink_parse_tuple(struct nfattr *cda else tuple->dst.dir = IP_CT_DIR_ORIGINAL; - NF_CT_DUMP_TUPLE(tuple); - - DEBUGP("leaving\n"); - return 0; } @@ -586,8 +562,6 @@ static int ctnetlink_parse_nat_proto(str struct nfattr *tb[CTA_PROTONAT_MAX]; struct ip_nat_protocol *npt; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_PROTONAT_MAX, attr); if (nfattr_bad_size(tb, CTA_PROTONAT_MAX, cta_min_protonat)) @@ -606,7 +580,6 @@ static int ctnetlink_parse_nat_proto(str ip_nat_proto_put(npt); - DEBUGP("leaving\n"); return 0; } @@ -622,8 +595,6 @@ ctnetlink_parse_nat(struct nfattr *nat, struct nfattr *tb[CTA_NAT_MAX]; int err; - DEBUGP("entered %s\n", __FUNCTION__); - memset(range, 0, sizeof(*range)); nfattr_parse_nested(tb, CTA_NAT_MAX, nat); @@ -649,7 +620,6 @@ ctnetlink_parse_nat(struct nfattr *nat, if (err < 0) return err; - DEBUGP("leaving\n"); return 0; } #endif @@ -659,8 +629,6 @@ ctnetlink_parse_help(struct nfattr *attr { struct nfattr *tb[CTA_HELP_MAX]; - DEBUGP("entered %s\n", __FUNCTION__); - nfattr_parse_nested(tb, CTA_HELP_MAX, attr); if (!tb[CTA_HELP_NAME-1]) @@ -690,8 +658,6 @@ ctnetlink_del_conntrack(struct sock *ctn u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -709,10 +675,8 @@ ctnetlink_del_conntrack(struct sock *ctn return err; h = nf_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash\n"); + if (!h) return -ENOENT; - } ct = nf_ct_tuplehash_to_ctrack(h); @@ -727,7 +691,6 @@ ctnetlink_del_conntrack(struct sock *ctn ct->timeout.function((unsigned long)ct); nf_ct_put(ct); - DEBUGP("leaving\n"); return 0; } @@ -744,8 +707,6 @@ ctnetlink_get_conntrack(struct sock *ctn u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nlh->nlmsg_flags & NLM_F_DUMP) { u32 rlen; @@ -779,11 +740,9 @@ #endif return err; h = nf_conntrack_find_get(&tuple, NULL); - if (!h) { - DEBUGP("tuple not found in conntrack hash"); + if (!h) return -ENOENT; - } - DEBUGP("tuple found\n"); + ct = nf_ct_tuplehash_to_ctrack(h); err = -ENOMEM; @@ -804,7 +763,6 @@ #endif if (err < 0) goto out; - DEBUGP("leaving\n"); return 0; free: @@ -876,8 +834,6 @@ ctnetlink_change_helper(struct nf_conn * char *helpname; int err; - DEBUGP("entered %s\n", __FUNCTION__); - if (!help) { /* FIXME: we need to reallocate and rehash */ return -EBUSY; @@ -954,8 +910,6 @@ ctnetlink_change_conntrack(struct nf_con { int err; - DEBUGP("entered %s\n", __FUNCTION__); - if (cda[CTA_HELP-1]) { err = ctnetlink_change_helper(ct, cda); if (err < 0) @@ -985,7 +939,6 @@ #if defined(CONFIG_NF_CONNTRACK_MARK) ct->mark = ntohl(*(u_int32_t *)NFA_DATA(cda[CTA_MARK-1])); #endif - DEBUGP("all done\n"); return 0; } @@ -997,8 +950,6 @@ ctnetlink_create_conntrack(struct nfattr struct nf_conn *ct; int err = -EINVAL; - DEBUGP("entered %s\n", __FUNCTION__); - ct = nf_conntrack_alloc(otuple, rtuple); if (ct == NULL || IS_ERR(ct)) return -ENOMEM; @@ -1028,7 +979,6 @@ #endif add_timer(&ct->timeout); nf_conntrack_hash_insert(ct); - DEBUGP("conntrack with id %u inserted\n", ct->id); return 0; err: @@ -1046,8 +996,6 @@ ctnetlink_new_conntrack(struct sock *ctn u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_MAX, cta_min)) return -EINVAL; @@ -1071,7 +1019,6 @@ ctnetlink_new_conntrack(struct sock *ctn if (h == NULL) { write_unlock_bh(&nf_conntrack_lock); - DEBUGP("no such conntrack, create new\n"); err = -ENOENT; if (nlh->nlmsg_flags & NLM_F_CREATE) err = ctnetlink_create_conntrack(cda, &otuple, &rtuple); @@ -1087,7 +1034,6 @@ ctnetlink_new_conntrack(struct sock *ctn /* We manipulate the conntrack inside the global conntrack table lock, * so there's no need to increase the refcount */ - DEBUGP("conntrack found\n"); err = -EEXIST; if (!(nlh->nlmsg_flags & NLM_F_EXCL)) err = ctnetlink_change_conntrack(nf_ct_tuplehash_to_ctrack(h), cda); @@ -1268,8 +1214,6 @@ ctnetlink_exp_dump_table(struct sk_buff struct nfgenmsg *nfmsg = NLMSG_DATA(cb->nlh); u_int8_t l3proto = nfmsg->nfgen_family; - DEBUGP("entered %s, last id=%llu\n", __FUNCTION__, *id); - read_lock_bh(&nf_conntrack_lock); list_for_each_prev(i, &nf_conntrack_expect_list) { exp = (struct nf_conntrack_expect *) i; @@ -1287,8 +1231,6 @@ ctnetlink_exp_dump_table(struct sk_buff out: read_unlock_bh(&nf_conntrack_lock); - DEBUGP("leaving, last id=%llu\n", *id); - return skb->len; } @@ -1308,8 +1250,6 @@ ctnetlink_get_expect(struct sock *ctnl, u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1460,8 +1400,6 @@ ctnetlink_create_expect(struct nfattr *c struct nf_conn_help *help; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - /* caller guarantees that those three CTA_EXPECT_* exist */ err = ctnetlink_parse_tuple(cda, &tuple, CTA_EXPECT_TUPLE, u3); if (err < 0) @@ -1516,8 +1454,6 @@ ctnetlink_new_expect(struct sock *ctnl, u_int8_t u3 = nfmsg->nfgen_family; int err = 0; - DEBUGP("entered %s\n", __FUNCTION__); - if (nfattr_bad_size(cda, CTA_EXPECT_MAX, cta_min_exp)) return -EINVAL; @@ -1546,8 +1482,6 @@ ctnetlink_new_expect(struct sock *ctnl, err = ctnetlink_change_expect(exp, cda); write_unlock_bh(&nf_conntrack_lock); - DEBUGP("leaving\n"); - return err; } From eric at inl.fr Thu Oct 12 14:03:27 2006 From: eric at inl.fr (Eric Leblond) Date: Thu Oct 12 14:40:59 2006 Subject: [PATCH] ulogd fix for kernel 64bits/userspace 32bits system Message-ID: <1160654607.9238.5.camel@localhost.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : /pipermail/netfilter-devel/attachments/20061012/91d64cc3/attachment-0001.pgp From kaber at trash.net Thu Oct 12 14:10:22 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 14:46:16 2006 Subject: [PATCH] ulogd fix for kernel 64bits/userspace 32bits system In-Reply-To: <1160654607.9238.5.camel@localhost.localdomain> References: <1160654607.9238.5.camel@localhost.localdomain> Message-ID: <452E30AE.9030805@trash.net> Eric Leblond wrote: > Hello, > > This patch fixes ulogd for system with kernel space 64 bits and > userspace 32 bits. > > Auto detection of system type is taken from iptables. We're actually going to remove that and I am very reluctant to add this. - its a compile-time solution and therefor unusable for distributors - it might get accidentally enabled by a distributor should he be crazy enough to compile packages in a mixed environment - it will break if we ever get compat support in the kernel (which is admittedly quite unlikely) So I really need some convincing :) From eric at inl.fr Thu Oct 12 16:14:31 2006 From: eric at inl.fr (Eric Leblond) Date: Thu Oct 12 16:52:17 2006 Subject: [PATCH] ulogd fix for kernel 64bits/userspace 32bits system In-Reply-To: <452E30AE.9030805@trash.net> References: <1160654607.9238.5.camel@localhost.localdomain> <452E30AE.9030805@trash.net> Message-ID: <1160662471.15687.11.camel@localhost.localdomain> Le jeudi 12 octobre 2006 ? 14:10 +0200, Patrick McHardy a ?crit : > Eric Leblond wrote: > > Hello, > We're actually going to remove that and I am very reluctant to > add this. > > - its a compile-time solution and therefor unusable for distributors > > - it might get accidentally enabled by a distributor should he > be crazy enough to compile packages in a mixed environment Both points seem linked with autodetection of system. I agree that it is potentially dangerous. In fact, it may be better to use a configure flag approach ? What do you think ? BR, -- ?ric Leblond, eleblond@inl.fr T?l?phone : 01 44 89 46 39, Fax : 01 44 89 45 01 INL, http://www.inl.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : /pipermail/netfilter-devel/attachments/20061012/95629f5d/attachment.pgp From kaber at trash.net Thu Oct 12 16:23:43 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 17:01:18 2006 Subject: [PATCH] ulogd fix for kernel 64bits/userspace 32bits system In-Reply-To: <1160662471.15687.11.camel@localhost.localdomain> References: <1160654607.9238.5.camel@localhost.localdomain> <452E30AE.9030805@trash.net> <1160662471.15687.11.camel@localhost.localdomain> Message-ID: <452E4FEF.1080100@trash.net> Eric Leblond wrote: > Le jeudi 12 octobre 2006 ? 14:10 +0200, Patrick McHardy a ?crit : > >>- its a compile-time solution and therefor unusable for distributors >> >>- it might get accidentally enabled by a distributor should he >> be crazy enough to compile packages in a mixed environment > > > Both points seem linked with autodetection of system. I agree that it is > potentially dangerous. > > In fact, it may be better to use a configure flag approach ? What do you > think ? That sounds better - ideally with a big warning that states that it is just a workaround and _will_ break in case real compatibility is introduced to the kernel. From kaber at trash.net Thu Oct 12 16:26:49 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 12 17:04:13 2006 Subject: [PATCH] ulogd fix for kernel 64bits/userspace 32bits system In-Reply-To: <452E4FEF.1080100@trash.net> References: <1160654607.9238.5.camel@localhost.localdomain> <452E30AE.9030805@trash.net> <1160662471.15687.11.camel@localhost.localdomain> <452E4FEF.1080100@trash.net> Message-ID: <452E50A9.4050809@trash.net> Patrick McHardy wrote: > Eric Leblond wrote: > >>Le jeudi 12 octobre 2006 ? 14:10 +0200, Patrick McHardy a ?crit : >> >> >>>- its a compile-time solution and therefor unusable for distributors >>> >>>- it might get accidentally enabled by a distributor should he >>> be crazy enough to compile packages in a mixed environment >> >> >>Both points seem linked with autodetection of system. I agree that it is >>potentially dangerous. >> >>In fact, it may be better to use a configure flag approach ? What do you >>think ? > > > That sounds better - ideally with a big warning that states > that it is just a workaround and _will_ break in case real > compatibility is introduced to the kernel. BTW, maybe its even possible to do runtime detection? That would also fix the first issue. From rdenis at simphalempin.com Thu Oct 12 16:29:35 2006 From: rdenis at simphalempin.com (=?iso-8859-1?q?R=E9mi_Denis-Courmont?=) Date: Thu Oct 12 17:07:24 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610120811.k9C8B4Pg002384@toshiba.co.jp> References: <200610021747.42658@auguste.remlab.net> <200610032258.30338@auguste.remlab.net> <200610120811.k9C8B4Pg002384@toshiba.co.jp> Message-ID: <200610121729.36069@auguste.remlab.net> Le jeudi 12 octobre 2006 11:11, Yasuyuki KOZAKAI a ?crit : > ??? Did you send intended patch ? It includes XT_MULTI_PORTS as > folows. Hmm, probably resent the old one accidentally then. Sending the correct patch as attachment to avoid further breakages. -- R?mi Denis-Courmont http://www.remlab.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: iptables-ip6t-multiport-v1.patch Type: text/x-diff Size: 11519 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061012/8052ffbe/iptables-ip6t-multiport-v1.bin From eric at inl.fr Thu Oct 12 18:18:43 2006 From: eric at inl.fr (Eric Leblond) Date: Thu Oct 12 18:56:18 2006 Subject: Resend: Patch : ulogd fix for kernel 64bits/userspace 32bits system In-Reply-To: <452E4FEF.1080100@trash.net> References: <1160654607.9238.5.camel@localhost.localdomain> <452E30AE.9030805@trash.net> <1160662471.15687.11.camel@localhost.localdomain> <452E4FEF.1080100@trash.net> Message-ID: <1160669923.27911.5.camel@localhost.localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : /pipermail/netfilter-devel/attachments/20061012/51b1de9e/attachment-0001.pgp From alan.ezust at presinet.com Thu Oct 12 19:17:55 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Thu Oct 12 19:55:53 2006 Subject: [patch] P-O-M-ng: runme shouldn't pick up backup files Message-ID: <200610121017.55565.alan.ezust@presinet.com> This patch is for the patchomatic runme script. It addresses two issues: 1. When a patch fails, it shows you exactly which file caused the failure. 2. When there are backup files (ending with ~ or beginning with #) they are ignored by POM. -------------- next part -------------- A non-text attachment was scrubbed... Name: runme.patch Type: text/x-diff Size: 2608 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061012/04e74b69/runme.bin From alan.ezust at presinet.com Thu Oct 12 22:01:05 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Thu Oct 12 22:39:12 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <45279039.8090309@netfilter.org> References: <200610031518.10097.alan.ezust@presinet.com> <200610061314.16177.alan.ezust@presinet.com> <45279039.8090309@netfilter.org> Message-ID: <200610121301.06023.alan.ezust@presinet.com> Hi Pablo, I'm still having the same problem. I built libnfnetlink and libnfconntrack from svn, adn then I built conntrack userspace tool 1.0beta2. All of the errors in dmesg are gone now. conntrack -L conntrack still lists nothing. Here is my latest kernel .config file. I am still having the same problem with the conntrack userspace tool, running with Linux 2.6.16.29 - so I'm thinking I will have to upgrade to 2.6.18, but alas, that causes breakages with some of the patchlets that we are maintaining, so I wanted to put that off til later. Is there anything obviously wrong/missing about this kernel configuration? If there are definite incompatibilities with conntrack 1.00beta2 and linux 2.6.16.29, please let me know and I'll stop barking up this tree... $ lsmod nfnetlink_queue 12384 0 ipt_recent 11180 2 ipt_LOG 6496 4 ipt_bin 22020 7 iptable_promisc 1856 1 ipt_multiport 2432 10 ip_conntrack_pptp 10544 0 ip_conntrack_netbios_ns 2784 0 ip_conntrack_irc 6456 0 xt_CONNMARK 2208 2 xt_connmark 1760 2 ipt_DATA 4192 5 ipt_psd 44036 1 xt_state 1888 4 xt_conntrack 2304 4 xt_pkttype 1664 1 xt_MARK 2368 0 ipt_regex 7752 1 tulip 49952 0 eepro100 30576 0 8139too 25376 0 3c59x 44104 0 -------------- next part -------------- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.16.29 # Thu Oct 12 11:54:04 2006 # CONFIG_X86_32=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="presinet" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE="/home/ezust/presinet/projects/firmware/branches/sensor/binary/boot.cpio.uclibc" CONFIG_INITRAMFS_ROOT_UID=0 CONFIG_INITRAMFS_ROOT_GID=0 CONFIG_UID16=y CONFIG_VM86=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set CONFIG_OBSOLETE_INTERMODULE=m # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_LBD=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_ALIGNMENT_16=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_KEXEC is not set CONFIG_PHYSICAL_START=0x100000 CONFIG_DOUBLEFAULT=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y # CONFIG_ACPI_SLEEP is not set CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y # CONFIG_ACPI_HOTKEY is not set CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCIEPORTBUS=y # CONFIG_HOTPLUG_PCI_PCIE is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_ISA_DMA_API=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set # CONFIG_I82365 is not set # CONFIG_TCIC is not set CONFIG_PCMCIA_PROBE=y CONFIG_PCCARD_NONSTATIC=m # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_FAKE=m # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_NETDEBUG=y CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_MULTIPATH=y # CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y # CONFIG_IP_PNP_DHCP is not set # CONFIG_IP_PNP_BOOTP is not set # CONFIG_IP_PNP_RARP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y # CONFIG_IP_PIMSM_V1 is not set # CONFIG_IP_PIMSM_V2 is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set CONFIG_INET_TUNNEL=m CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y CONFIG_TCP_CONG_ADVANCED=y # # TCP congestion control # CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=m CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m # CONFIG_TCP_CONG_HSTCP is not set # CONFIG_TCP_CONG_HYBLA is not set # CONFIG_TCP_CONG_VEGAS is not set # CONFIG_TCP_CONG_SCALABLE is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NETFILTER_XTABLES=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CONNTRACK_EVENTS=y CONFIG_IP_NF_CONNTRACK_NETLINK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=m CONFIG_IP_NF_NETBIOS_NS=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_PPTP=m # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_IPRANGE=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_TTL=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_HASHLIMIT=m # CONFIG_IP_NF_MATCH_POLICY is not set CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m # CONFIG_IP_NF_TARGET_ULOG is not set CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=y 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_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_NAT_PPTP=m CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP_NF_TARGET_IPV4OPTSSTRIP=m CONFIG_IP_NF_MATCH_IPV4OPTIONS=m CONFIG_IP_NF_MATCH_PSD=m CONFIG_IP_NF_SET=m CONFIG_IP_NF_SET_MAX=256 CONFIG_IP_NF_SET_HASHSIZE=1024 CONFIG_IP_NF_SET_IPMAP=m CONFIG_IP_NF_SET_MACIPMAP=m CONFIG_IP_NF_SET_PORTMAP=m CONFIG_IP_NF_SET_IPHASH=m CONFIG_IP_NF_SET_NETHASH=m CONFIG_IP_NF_SET_IPPORTHASH=m CONFIG_IP_NF_SET_IPTREE=m CONFIG_IP_NF_MATCH_SET=m CONFIG_IP_NF_TARGET_SET=m CONFIG_IP_NF_MATCH_U32=m CONFIG_IP_NF_MATCH_BIN=m CONFIG_IP_NF_MATCH_REGEX=m CONFIG_IP_NF_TARGET_DATA=m CONFIG_IP_NF_PROMISC=m # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=y CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m # CONFIG_BRIDGE_EBT_ULOG is not set # # DCCP Configuration (EXPERIMENTAL) # # CONFIG_IP_DCCP is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # # TIPC Configuration (EXPERIMENTAL) # CONFIG_TIPC=m # CONFIG_TIPC_ADVANCED is not set # CONFIG_TIPC_DEBUG is not set # CONFIG_ATM is not set CONFIG_BRIDGE=y CONFIG_VLAN_8021Q=y # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y # CONFIG_NET_SCH_CLK_JIFFIES is not set CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y # CONFIG_NET_SCH_CLK_CPU is not set # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m # CONFIG_NET_SCH_RED is not set CONFIG_NET_SCH_SFQ=m # CONFIG_NET_SCH_TEQL is not set CONFIG_NET_SCH_TBF=m # CONFIG_NET_SCH_GRED is not set CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m # CONFIG_NET_SCH_INGRESS is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m # CONFIG_CLS_U32_PERF is not set CONFIG_CLS_U32_MARK=y # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y # CONFIG_NET_ACT_POLICE is not set CONFIG_NET_ACT_GACT=m # CONFIG_GACT_PROB is not set CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_PEDIT=m # CONFIG_NET_ACT_SIMP is not set CONFIG_NET_CLS_IND=y CONFIG_NET_ESTIMATOR=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_IEEE80211=m CONFIG_IEEE80211_DEBUG=y # CONFIG_IEEE80211_CRYPT_WEP is not set # CONFIG_IEEE80211_CRYPT_CCMP is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # # Connector - unified userspace <-> kernelspace linker # # CONFIG_CONNECTOR is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set # CONFIG_MTD_PARTITIONS is not set # # User Modules And Translation Layers # # CONFIG_MTD_CHAR is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set CONFIG_FTL=y CONFIG_NFTL=y CONFIG_NFTL_RW=y CONFIG_INFTL=y # CONFIG_RFD_FTL is not set # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m CONFIG_MTD_CFI_ADV_OPTIONS=y CONFIG_MTD_CFI_NOSWAP=y # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set # CONFIG_MTD_CFI_GEOMETRY is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_OTP is not set # CONFIG_MTD_CFI_INTELEXT is not set # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_CFI_STAA is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_SC520CDP is not set # CONFIG_MTD_TS5500 is not set # CONFIG_MTD_AMD76XROM is not set # CONFIG_MTD_ICHXROM is not set # CONFIG_MTD_SCB2_FLASH is not set # CONFIG_MTD_L440GX is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # # NAND Flash Device Drivers # CONFIG_MTD_NAND=y CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_IDS=y CONFIG_MTD_NAND_DISKONCHIP=y # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 # CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set # # OneNAND Flash Device Drivers # # CONFIG_MTD_ONENAND is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_ISAPNP is not set # CONFIG_PNPBIOS is not set CONFIG_PNPACPI=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_BLK_DEV_RAM_COUNT=16 # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_CS5535 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=y # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # # SCSI low-level drivers # # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set CONFIG_SCSI_DPT_I2O=m # CONFIG_SCSI_IN2000 is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_AHCI is not set # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=y # CONFIG_SCSI_SATA_MV is not set # CONFIG_SCSI_SATA_NV is not set # CONFIG_SCSI_PDC_ADMA is not set # CONFIG_SCSI_SATA_QSTOR is not set # CONFIG_SCSI_SATA_PROMISE is not set CONFIG_SCSI_SATA_SX4=m # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIL24 is not set CONFIG_SCSI_SATA_SIS=m # CONFIG_SCSI_SATA_ULI is not set # CONFIG_SCSI_SATA_VIA is not set # CONFIG_SCSI_SATA_VITESSE is not set CONFIG_SCSI_SATA_INTEL_COMBINED=y # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set CONFIG_SCSI_IPR=m # CONFIG_SCSI_IPR_TRACE is not set # CONFIG_SCSI_IPR_DUMP is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_NINJA_SCSI is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # CONFIG_IEEE1394_EXPORT_FULL_API is not set # # Device Drivers # # # Texas Instruments PCILynx requires I2C # CONFIG_IEEE1394_OHCI1394=y # # Protocol Drivers # # CONFIG_IEEE1394_VIDEO1394 is not set # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set CONFIG_IEEE1394_RAWIO=y # # I2O device support # # CONFIG_I2O is not set # # Network device support # CONFIG_NETDEVICES=y # CONFIG_IFB is not set CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_NET_SB1000 is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # PHY device support # # CONFIG_PHYLIB is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=y CONFIG_EL2=y CONFIG_ELPLUS=y CONFIG_EL16=y CONFIG_EL3=y # CONFIG_3C515 is not set CONFIG_VORTEX=m CONFIG_TYPHOON=m # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set # CONFIG_TULIP_NAPI is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set # CONFIG_PCMCIA_XIRCOM is not set # CONFIG_PCMCIA_XIRTULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set CONFIG_HP100=m # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m # CONFIG_AMD8111E_NAPI is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set CONFIG_EEPRO100=m CONFIG_E100=m # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m # CONFIG_E1000_NAPI is not set # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # # Ethernet (10000 Mbit) # # CONFIG_CHELSIO_T1 is not set # CONFIG_IXGB is not set CONFIG_S2IO=m # CONFIG_S2IO_NAPI is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # PCMCIA network device support # # CONFIG_NET_PCMCIA is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set CONFIG_NETCONSOLE=y CONFIG_NETPOLL=y # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set # CONFIG_SERIAL_8250_CS is not set # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=y # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=y # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_MWAVE is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # TPM devices # # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set # # I2C support # # CONFIG_I2C is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Hardware Monitoring support # CONFIG_HWMON=y # CONFIG_HWMON_VID is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia Capabilities Port drivers # # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_MDA_CONSOLE=m CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=y CONFIG_USB_STORAGE_DEBUG=y # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_ACECAD is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_ITMTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set CONFIG_USB_MON=y # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set CONFIG_USB_CYTHERM=m # CONFIG_USB_PHIDGETKIT is not set CONFIG_USB_PHIDGETSERVO=m # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TEST is not set # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # InfiniBand support # # CONFIG_INFINIBAND is not set # # EDAC - error detection and reporting (RAS) (EXPERIMENTAL) # # CONFIG_EDAC is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_FS_XIP=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y CONFIG_REISERFS_CHECK=y # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=y # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y # CONFIG_NFSD_V3 is not set CONFIG_NFSD_TCP=y # CONFIG_ROOT_NFS is not set CONFIG_LOCKD=y CONFIG_EXPORTFS=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Instrumentation Support # CONFIG_PROFILING=y CONFIG_OPROFILE=y # CONFIG_KPROBES is not set # # Kernel hacking # # CONFIG_PRINTK_TIME is not set # CONFIG_MAGIC_SYSRQ is not set # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_DEBUG_BUGVERBOSE=y CONFIG_EARLY_PRINTK=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_TEST=m # # Hardware crypto devices # CONFIG_CRYPTO_DEV_PADLOCK=m # CONFIG_CRYPTO_DEV_PADLOCK_AES is not set # # Library routines # CONFIG_CRC_CCITT=m # CONFIG_CRC16 is not set CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_REED_SOLOMON=y CONFIG_REED_SOLOMON_DEC16=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y From alexeyt at freeshell.org Thu Oct 12 22:41:29 2006 From: alexeyt at freeshell.org (Alexey Toptygin) Date: Thu Oct 12 23:19:05 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: Message-ID: On Wed, 11 Oct 2006, Luis Floreani wrote: >> If you're interested in port knocking, you might want to read this >> paper: http://www.acsac.org/2005/abstracts/156.html It covers security >> issues relating to port knocking in detail, and presents an architecture >> for solving most of them. >> >> Full disclosure: I wrote that paper. Feel free to contact me if you >> have questions. >> >> Rennie deGraaf > > In our implementation, for security, we are using the Tumbler protocol, we > found it simple yet powerful, check it out here: > http://tumbler.sourceforge.net/. It seems that Tumbler is not capable of working across NAT, unless the client can somehow obtain its public IP address. Also, it relies on clocks being synchronized, since authentication will fail if the UTC time in minutes is not identical on the client and server. Tumbler is not as stealthy as the techniques in Rennie deGraaf's paper, since it uses an open UDP port. Finally, I doubt the cryptographic security of the Tumbler protocol - it relies on a SHA256 hash over the UTC time (in minutes), the client's IP and the shared secret. Observing a few authentications from the same client will give you hashes of strings with known prefixes (time + IP) and a fixed suffix (the secret). The insertion of the optional username between the time and IP (not at the end as documented) increases security slightly by making the pattern known,fixed,known,fixed but I think some attacks will still be possible because there are multiple ralated plaintexts with no random parts. Alexey From davem at davemloft.net Thu Oct 12 23:09:29 2006 From: davem at davemloft.net (David Miller) Date: Thu Oct 12 23:47:02 2006 Subject: [NETFILTER 00/06]: Netfilter fixes In-Reply-To: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> References: <20061012095547.11462.58507.sendpatchset@localhost.localdomain> Message-ID: <20061012.140929.125895707.davem@davemloft.net> From: Patrick McHardy Date: Thu, 12 Oct 2006 11:54:18 +0200 (MEST) > following are a few netfilter fixes for 2.6.19. Please apply, thanks. All applied, thanks Patrick. From alexeyt at freeshell.org Thu Oct 12 23:30:11 2006 From: alexeyt at freeshell.org (Alexey Toptygin) Date: Fri Oct 13 00:07:39 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: Message-ID: On Thu, 12 Oct 2006, Alexey Toptygin wrote: > Finally, I doubt the cryptographic security of the Tumbler protocol - it > relies on a SHA256 hash over the UTC time (in minutes), the client's IP and > the shared secret. Observing a few authentications from the same client will > give you hashes of strings with known prefixes (time + IP) and a fixed suffix > (the secret). The insertion of the optional username between the time and IP > (not at the end as documented) increases security slightly by making the > pattern known,fixed,known,fixed but I think some attacks will still be > possible because there are multiple ralated plaintexts with no random parts. Never mind this last bit, I wasn't thinking clearly. Alexey From alan.ezust at presinet.com Fri Oct 13 01:09:46 2006 From: alan.ezust at presinet.com (Alan Ezust) Date: Fri Oct 13 01:47:49 2006 Subject: testing installation of conntrack command line tool In-Reply-To: <200610121301.06023.alan.ezust@presinet.com> References: <200610031518.10097.alan.ezust@presinet.com> <45279039.8090309@netfilter.org> <200610121301.06023.alan.ezust@presinet.com> Message-ID: <200610121609.47726.alan.ezust@presinet.com> Here is a little follow-up - I discovered that regardless of what kernel options I enabled, I am unable to actually build the nf_conntrack_core or nf_conntrack_standalone sources in net/netfilter with the Makefile that is generated by linux 2.6.16.29. Currently, the generated Makefile in net/netfilter only builds these files: nf_conntrack_core, nf_conntrack_standalone, if CONFIG_NF_CT_NETLINK is defined. However, there doesn't seem to be such a config option available in the kernel configuration for this version. Adding a line CONFIG_NF_CT_NETLINK to my .config file doesn't seem to make a difference. So in fact, when I thought I was building conntrack, I was not. Is this a known issue? On Thursday 12 October 2006 13:01, Alan Ezust wrote: > Hi Pablo, > > I'm still having the same problem. I built libnfnetlink and libnfconntrack > from svn, adn then I built conntrack userspace tool 1.0beta2. All of the > errors in dmesg are gone now. > > conntrack -L conntrack still lists nothing. > > Here is my latest kernel .config file. I am still having the same problem > with the conntrack userspace tool, running with Linux 2.6.16.29 - so I'm > thinking I will have to upgrade to 2.6.18, but alas, that causes breakages > with some of the patchlets that we are maintaining, so I wanted to put that > off til later. > > Is there anything obviously wrong/missing about this kernel configuration? > > If there are definite incompatibilities with conntrack 1.00beta2 and linux > 2.6.16.29, please let me know and I'll stop barking up this tree... > > $ lsmod > > nfnetlink_queue 12384 0 > ipt_recent 11180 2 > ipt_LOG 6496 4 > ipt_bin 22020 7 > iptable_promisc 1856 1 > ipt_multiport 2432 10 > ip_conntrack_pptp 10544 0 > ip_conntrack_netbios_ns 2784 0 > ip_conntrack_irc 6456 0 > xt_CONNMARK 2208 2 > xt_connmark 1760 2 > ipt_DATA 4192 5 > ipt_psd 44036 1 > xt_state 1888 4 > xt_conntrack 2304 4 > xt_pkttype 1664 1 > xt_MARK 2368 0 > ipt_regex 7752 1 > tulip 49952 0 > eepro100 30576 0 > 8139too 25376 0 > 3c59x 44104 0 From yasuyuki.kozakai at toshiba.co.jp Fri Oct 13 02:50:44 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Oct 13 03:28:21 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610121729.36069@auguste.remlab.net> References: <200610032258.30338@auguste.remlab.net> <200610120811.k9C8B4Pg002384@toshiba.co.jp> <200610121729.36069@auguste.remlab.net> Message-ID: <200610130050.k9D0oj3O013113@toshiba.co.jp> Hello, > Le jeudi 12 octobre 2006 11:11, Yasuyuki KOZAKAI a ?crit : > > ??? Did you send intended patch ? It includes XT_MULTI_PORTS as > > folows. > > Hmm, probably resent the old one accidentally then. > > Sending the correct patch as attachment to avoid further breakages. Thanks, OK, I've update your patch (please see below comments in detail), and also tested with kernel 2.4.33.3 and 2.6 linus tree and ip6tables build with headers in each of them. If no objection, I'll commit the attached patch next week. I appreciate if you tries to build with 2.4 kernel for such changes from next time. From: R?mi Denis-Courmont Date: Thu, 12 Oct 2006 17:29:35 +0300 > Index: iptables/include/ip6tables.h > =================================================================== > --- iptables/include/ip6tables.h (r??vision 6687) > +++ iptables/include/ip6tables.h (copie de travail) > @@ -33,6 +33,9 @@ > > ip6t_chainlabel name; > > + /* Revision of match (0 by default). */ > + u_int8_t revision; > + > const char *version; The declaration for ip6t_get_revision is missing. That doesn't exist in 2.4 kernel. > Index: iptables/ip6tables.c > =================================================================== > --- iptables/ip6tables.c (r??vision 6687) > +++ iptables/ip6tables.c (copie de travail) > @@ -193,6 +193,8 @@ > const char *program_name; > char *lib_dir; > > +int kernel_version; This isn't used anywhere. Regards, -------------- next part -------------- diff --git a/extensions/libip6t_multiport.c b/extensions/libip6t_multiport.c index ed5fffe..166abce 100644 --- a/extensions/libip6t_multiport.c +++ b/extensions/libip6t_multiport.c @@ -5,7 +5,8 @@ #include #include #include -#include +/* To ensure that iptables compiles with an old kernel */ +#include "../include/linux/netfilter_ipv6/ip6t_multiport.h" /* Function which prints out usage message. */ static void @@ -20,6 +21,23 @@ help(void) " --dports ...\n" " match destination port(s)\n" " --ports port[,port,port]\n" +" match both source and destination port(s)\n" +" NOTE: this kernel does not support port ranges in multiport.\n", +IPTABLES_VERSION); +} + +static void +help_v1(void) +{ + printf( +"multiport v%s options:\n" +" --source-ports [!] port[,port:port,port...]\n" +" --sports ...\n" +" match source port(s)\n" +" --destination-ports [!] port[,port:port,port...]\n" +" --dports ...\n" +" match destination port(s)\n" +" --ports [!] port[,port:port,port]\n" " match both source and destination port(s)\n", IPTABLES_VERSION); } @@ -70,6 +88,46 @@ parse_multi_ports(const char *portstring return i; } +static void +parse_multi_ports_v1(const char *portstring, + struct ip6t_multiport_v1 *multiinfo, + const char *proto) +{ + char *buffer, *cp, *next, *range; + unsigned int i; + u_int16_t m; + + buffer = strdup(portstring); + if (!buffer) exit_error(OTHER_PROBLEM, "strdup failed"); + + for (i=0; ipflags[i] = 0; + + for (cp=buffer, i=0; cp && iports[i] = parse_port(cp, proto); + if (range) { + multiinfo->pflags[i] = 1; + multiinfo->ports[++i] = parse_port(range, proto); + if (multiinfo->ports[i-1] >= multiinfo->ports[i]) + exit_error(PARAMETER_PROBLEM, + "invalid portrange specified"); + m <<= 1; + } + } + multiinfo->count = i; + if (cp) exit_error(PARAMETER_PROBLEM, "too many ports specified"); + free(buffer); +} + /* Initialize the match. */ static void init(struct ip6t_entry_match *m, unsigned int *nfcache) @@ -143,6 +201,52 @@ parse(int c, char **argv, int invert, un return 1; } +static int +parse_v1(int c, char **argv, int invert, unsigned int *flags, + const struct ip6t_entry *entry, + unsigned int *nfcache, + struct ip6t_entry_match **match) +{ + const char *proto; + struct ip6t_multiport_v1 *multiinfo + = (struct ip6t_multiport_v1 *)(*match)->data; + + switch (c) { + case '1': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_SOURCE; + break; + + case '2': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_DESTINATION; + break; + + case '3': + check_inverse(argv[optind-1], &invert, &optind, 0); + proto = check_proto(entry); + parse_multi_ports_v1(argv[optind-1], multiinfo, proto); + multiinfo->flags = IP6T_MULTIPORT_EITHER; + break; + + default: + return 0; + } + + if (invert) + multiinfo->invert = 1; + + if (*flags) + exit_error(PARAMETER_PROBLEM, + "multiport can only have one option"); + *flags = 1; + return 1; +} + /* Final check; must specify something. */ static void final_check(unsigned int flags) @@ -210,6 +314,49 @@ print(const struct ip6t_ip6 *ip, printf(" "); } +static void +print_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match, + int numeric) +{ + const struct ip6t_multiport_v1 *multiinfo + = (const struct ip6t_multiport_v1 *)match->data; + unsigned int i; + + printf("multiport "); + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("ports "); + break; + + default: + printf("ERROR "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, numeric); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, numeric); + } + } + printf(" "); +} + /* Saves the union ip6t_matchinfo in parsable form to stdout. */ static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match) { @@ -238,6 +385,41 @@ static void save(const struct ip6t_ip6 * printf(" "); } +static void save_v1(const struct ip6t_ip6 *ip, + const struct ip6t_entry_match *match) +{ + const struct ip6t_multiport_v1 *multiinfo + = (const struct ip6t_multiport_v1 *)match->data; + unsigned int i; + + switch (multiinfo->flags) { + case IP6T_MULTIPORT_SOURCE: + printf("--sports "); + break; + + case IP6T_MULTIPORT_DESTINATION: + printf("--dports "); + break; + + case IP6T_MULTIPORT_EITHER: + printf("--ports "); + break; + } + + if (multiinfo->invert) + printf("! "); + + for (i=0; i < multiinfo->count; i++) { + printf("%s", i ? "," : ""); + print_port(multiinfo->ports[i], ip->proto, 1); + if (multiinfo->pflags[i]) { + printf(":"); + print_port(multiinfo->ports[++i], ip->proto, 1); + } + } + printf(" "); +} + static struct ip6tables_match multiport = { .name = "multiport", .version = IPTABLES_VERSION, @@ -252,8 +434,25 @@ static struct ip6tables_match multiport .extra_opts = opts, }; +static struct ip6tables_match multiport_v1 = { + .next = NULL, + .name = "multiport", + .revision = 1, + .version = IPTABLES_VERSION, + .size = IP6T_ALIGN(sizeof(struct ip6t_multiport_v1)), + .userspacesize = IP6T_ALIGN(sizeof(struct ip6t_multiport_v1)), + .help = &help_v1, + .init = &init, + .parse = &parse_v1, + .final_check = &final_check, + .print = &print_v1, + .save = &save_v1, + .extra_opts = opts +}; + void _init(void) { register_match6(&multiport); + register_match6(&multiport_v1); } diff --git a/include/ip6tables.h b/include/ip6tables.h index b1140b3..406f255 100644 --- a/include/ip6tables.h +++ b/include/ip6tables.h @@ -15,6 +15,18 @@ #define IPPROTO_DCCP 33 #endif +#ifndef IP6T_SO_GET_REVISION_MATCH /* Old kernel source. */ +#define IP6T_SO_GET_REVISION_MATCH (IP6T_BASE_CTL + 2) +#define IP6T_SO_GET_REVISION_TARGET (IP6T_BASE_CTL + 3) + +struct ip6t_get_revision +{ + char name[IP6T_FUNCTION_MAXNAMELEN-1]; + + u_int8_t revision; +}; +#endif /* IP6T_SO_GET_REVISION_MATCH Old kernel source */ + struct ip6tables_rule_match { struct ip6tables_rule_match *next; @@ -33,6 +45,9 @@ struct ip6tables_match ip6t_chainlabel name; + /* Revision of match (0 by default). */ + u_int8_t revision; + const char *version; /* Size of match data. */ diff --git a/include/linux/netfilter_ipv6/ip6t_multiport.h b/include/linux/netfilter_ipv6/ip6t_multiport.h new file mode 100644 index 0000000..8c2cc9d --- /dev/null +++ b/include/linux/netfilter_ipv6/ip6t_multiport.h @@ -0,0 +1,30 @@ +#ifndef _IP6T_MULTIPORT_H +#define _IP6T_MULTIPORT_H + +enum ip6t_multiport_flags +{ + IP6T_MULTIPORT_SOURCE, + IP6T_MULTIPORT_DESTINATION, + IP6T_MULTIPORT_EITHER +}; + +#define IP6T_MULTI_PORTS 15 + +/* Must fit inside union xt_matchinfo: 16 bytes */ +struct ip6t_multiport +{ + u_int8_t flags; /* Type of comparison */ + u_int8_t count; /* Number of ports */ + u_int16_t ports[IP6T_MULTI_PORTS]; /* Ports */ +}; + +struct ip6t_multiport_v1 +{ + u_int8_t flags; /* Type of comparison */ + u_int8_t count; /* Number of ports */ + u_int16_t ports[IP6T_MULTI_PORTS]; /* Ports */ + u_int8_t pflags[IP6T_MULTI_PORTS]; /* Port flags */ + u_int8_t invert; /* Invert flag */ +}; + +#endif /*_IP6T_MULTIPORT_H*/ diff --git a/ip6tables.c b/ip6tables.c index 659041f..92e434c 100644 --- a/ip6tables.c +++ b/ip6tables.c @@ -1102,10 +1102,51 @@ merge_options(struct option *oldopts, co return merge; } +static int compatible_revision(const char *name, u_int8_t revision, int opt) +{ + struct ip6t_get_revision rev; + socklen_t s = sizeof(rev); + int max_rev, sockfd; + + sockfd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW); + if (sockfd < 0) { + fprintf(stderr, "Could not open socket to kernel: %s\n", + strerror(errno)); + exit(1); + } + + strcpy(rev.name, name); + rev.revision = revision; + + max_rev = getsockopt(sockfd, IPPROTO_IPV6, opt, &rev, &s); + if (max_rev < 0) { + /* Definitely don't support this? */ + if (errno == EPROTONOSUPPORT) { + close(sockfd); + return 0; + } else if (errno == ENOPROTOOPT) { + close(sockfd); + /* Assume only revision 0 support (old kernel) */ + return (revision == 0); + } else { + fprintf(stderr, "getsockopt failed strangely: %s\n", + strerror(errno)); + exit(1); + } + } + close(sockfd); + return 1; +} + +static int compatible_match_revision(const char *name, u_int8_t revision) +{ + return compatible_revision(name, revision, IP6T_SO_GET_REVISION_MATCH); +} + void register_match6(struct ip6tables_match *me) { - struct ip6tables_match **i; + struct ip6tables_match **i, *old; if (strcmp(me->version, program_version) != 0) { fprintf(stderr, "%s: match `%s' v%s (I'm v%s).\n", @@ -1113,12 +1154,36 @@ register_match6(struct ip6tables_match * exit(1); } - if (find_match(me->name, DURING_LOAD, NULL)) { - fprintf(stderr, "%s: match `%s' already registered.\n", + /* Revision field stole a char from name. */ + if (strlen(me->name) >= IP6T_FUNCTION_MAXNAMELEN-1) { + fprintf(stderr, "%s: target `%s' has invalid name\n", program_name, me->name); exit(1); } + old = find_match(me->name, DURING_LOAD, NULL); + if (old) { + if (old->revision == me->revision) { + fprintf(stderr, + "%s: match `%s' already registered.\n", + program_name, me->name); + exit(1); + } + + /* Now we have two (or more) options, check compatibility. */ + if (compatible_match_revision(old->name, old->revision) + && old->revision > me->revision) + return; + + /* Replace if compatible. */ + if (!compatible_match_revision(me->name, me->revision)) + return; + + /* Delete old one. */ + for (i = &ip6tables_matches; *i!=old; i = &(*i)->next); + *i = old->next; + } + if (me->size != IP6T_ALIGN(me->size)) { fprintf(stderr, "%s: match `%s' has invalid size %u.\n", program_name, me->name, (unsigned int)me->size); @@ -1761,6 +1826,14 @@ void clear_rule_matches(struct ip6tables *matches = NULL; } +static void set_revision(char *name, u_int8_t revision) +{ + /* Old kernel sources don't have ".revision" field, + but we stole a byte from name. */ + name[IP6T_FUNCTION_MAXNAMELEN - 2] = '\0'; + name[IP6T_FUNCTION_MAXNAMELEN - 1] = revision; +} + int do_command6(int argc, char *argv[], char **table, ip6tc_handle_t *handle) { struct ip6t_entry fw, *e = NULL; @@ -2041,6 +2114,7 @@ int do_command6(int argc, char *argv[], m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); if (m != m->next) @@ -2185,6 +2259,8 @@ int do_command6(int argc, char *argv[], m->m = fw_calloc(1, size); m->m->u.match_size = size; strcpy(m->m->u.user.name, m->name); + set_revision(m->m->u.user.name, + m->revision); if (m->init != NULL) m->init(m->m, &fw.nfcache); From mbr at cipherdyne.org Fri Oct 13 04:50:34 2006 From: mbr at cipherdyne.org (Michael Rash) Date: Fri Oct 13 05:28:12 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: Message-ID: <20061013025034.GB12880@minastirith> On Oct 12, 2006, Alexey Toptygin wrote: > On Wed, 11 Oct 2006, Luis Floreani wrote: > > >>If you're interested in port knocking, you might want to read this > >>paper: http://www.acsac.org/2005/abstracts/156.html It covers security > >>issues relating to port knocking in detail, and presents an architecture > >>for solving most of them. > >> > >>Full disclosure: I wrote that paper. Feel free to contact me if you > >>have questions. > >> > >>Rennie deGraaf > > > >In our implementation, for security, we are using the Tumbler protocol, we > >found it simple yet powerful, check it out here: > >http://tumbler.sourceforge.net/. > > It seems that Tumbler is not capable of working across NAT, unless the > client can somehow obtain its public IP address. Also, it relies on clocks > being synchronized, since authentication will fail if the UTC time in > minutes is not identical on the client and server. Tumbler is not as > stealthy as the techniques in Rennie deGraaf's paper, since it uses an > open UDP port. Why not use fwknop in Single Packet Authorization mode?: http://www.cipherdyne.org/fwknop/ (Disclosure: I wrote it). Here are some of the highlights (parts of this are related to both the original poster's question and the Alexey's observation above about the open UDP port in Tumbler): - Support for both asymmetric and symmetric encryption via Rijndael and GnuPG. If GnuPG is used, then fwknop verifies that the data is both signed and encrypted. Any multi-packet port knocking scheme would have serious difficulty in using an asymmetric cipher because of the generally long key lengths and resulting size of encrypted data. - No open ports on the server side; all packet data is monitored via a sniffer. Iptables should be configured in a default-drop stance for all protected services and for the port on which the SPA packet is sent (UDP 62201 by default, but fwknop also supports sending over ICMP and over a blind TCP ACK packet). - Automatic reconfiguration of the local iptables policy via the IPTables::ChainMgr perl module; this is not as cool as using a netlink socket to communicate to a userspace program, but doing the knock verification in the kernel itself limits your options for doing things like using GnuPG. - Because an encrypted payload is used, any access directive can be used instead of just a pre-determined set of access directives for which the hashes can be worked out as in the Tumbler protocol. A full command channel is also supported by fwknop. - SPA packets are non-replayable in both asymmetric and symmetric encryption modes due to the fact that 16 bytes of random data is included within every packet, and the md5 sum is tracked (and written to disk) on the server side. - Support for multiple users, each with their own encryption keys and authorization rules. - Support for a time window over which an SPA packet is accepted (this feature can easily be disabled if time synchronization is a problem). - Custom patch against openssh, so (after fwknop is run against for the first time so it can cache your command line arguments) you can just do: ssh -K "-L " user@host -- Michael Rash http://www.cipherdyne.org/ Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F From lucholaf at gmail.com Fri Oct 13 04:50:51 2006 From: lucholaf at gmail.com (Luis Floreani) Date: Fri Oct 13 05:28:22 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: Message-ID: On 10/12/06, Alexey Toptygin wrote: > On Wed, 11 Oct 2006, Luis Floreani wrote: > > >> If you're interested in port knocking, you might want to read this > >> paper: http://www.acsac.org/2005/abstracts/156.html It covers security > >> issues relating to port knocking in detail, and presents an architecture > >> for solving most of them. > >> > >> Full disclosure: I wrote that paper. Feel free to contact me if you > >> have questions. > >> > >> Rennie deGraaf > > > > In our implementation, for security, we are using the Tumbler protocol, we > > found it simple yet powerful, check it out here: > > http://tumbler.sourceforge.net/. > > It seems that Tumbler is not capable of working across NAT, unless the > client can somehow obtain its public IP address. Yes, with our implementation you need to know the public IP. On the other hand, the Rennie implementation makes that easier, but from a security point of view, both ways leaves the service open to the public IP address, so anybody behind the NAT has the service port open. That's a general problem with PK. > Also, it relies on clocks > being synchronized, since authentication will fail if the UTC time in > minutes is not identical on the client and server. it's very easy to sync a clock, you can do it with "rdate". e.g: $ rdate time-a.nist.gov > Tumbler is not as > stealthy as the techniques in Rennie deGraaf's paper, since it uses an > open UDP port. In our netfilter extension, the knock ports are CLOSED, also, the server never sends an answer to any client knock, which really means being "stealthy". From kaber at trash.net Fri Oct 13 08:00:34 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Oct 13 08:37:06 2006 Subject: Resend: Patch : ulogd fix for kernel 64bits/userspace 32bits system In-Reply-To: <1160669923.27911.5.camel@localhost.localdomain> References: <1160654607.9238.5.camel@localhost.localdomain> <452E30AE.9030805@trash.net> <1160662471.15687.11.camel@localhost.localdomain> <452E4FEF.1080100@trash.net> <1160669923.27911.5.camel@localhost.localdomain> Message-ID: <452F2B82.5060308@trash.net> Eric Leblond wrote: > You can now do : > ./configure --with-kernel-64-user-32 > to activate the workaround. > > It displays : > > configure: WARNING: The use of the flag kernel-64-user-32 could interfere with kernel evolution. Use it at your own risk. The patch looks good, but doesn't apply: (Stripping trailing CRs from patch.) patching file configure.in (Stripping trailing CRs from patch.) patching file libipulog/include/linux/netfilter_ipv4/ipt_ULOG.h (Stripping trailing CRs from patch.) patching file libipulog/include/libipulog/libipulog.h Hunk #1 FAILED at 1. 1 out of 2 hunks FAILED -- saving rejects to file libipulog/include/libipulog/libipulog.h.rej (Stripping trailing CRs from patch.) patching file Rules.make.in Please rediff against current SVN. From kaber at trash.net Fri Oct 13 08:03:19 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Oct 13 08:39:49 2006 Subject: Resend: Patch : ulogd fix for kernel 64bits/userspace 32bits system In-Reply-To: <452F2B82.5060308@trash.net> References: <1160654607.9238.5.camel@localhost.localdomain> <452E30AE.9030805@trash.net> <1160662471.15687.11.camel@localhost.localdomain> <452E4FEF.1080100@trash.net> <1160669923.27911.5.camel@localhost.localdomain> <452F2B82.5060308@trash.net> Message-ID: <452F2C27.9030603@trash.net> Patrick McHardy wrote: > The patch looks good, but doesn't apply: > > (Stripping trailing CRs from patch.) > patching file configure.in > (Stripping trailing CRs from patch.) > patching file libipulog/include/linux/netfilter_ipv4/ipt_ULOG.h > (Stripping trailing CRs from patch.) > patching file libipulog/include/libipulog/libipulog.h > Hunk #1 FAILED at 1. > 1 out of 2 hunks FAILED -- saving rejects to file > libipulog/include/libipulog/libipulog.h.rej > (Stripping trailing CRs from patch.) > patching file Rules.make.in > > Please rediff against current SVN. Never mind, it was this part: -/* $Id: libipulog.h,v 1.6 2002/07/30 07:23:36 laforge Exp $ */ +/* $Id$ */ I fixed it up manually. Thanks Eric. From kaber at trash.net Fri Oct 13 08:15:41 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Oct 13 08:52:10 2006 Subject: nfq_set_verdict_mark In-Reply-To: <1160634939.24065.8.camel@localhost> References: <986D9B66-68B6-4A02-9762-40224E145496@cadvium.net> <4521284C.2070000@netfilter.org> <452B2D9A.7080702@trash.net> <452C33FE.6060902@netfilter.org> <452CB33D.8060908@trash.net> <452D6676.8090700@netfilter.org> <1160634939.24065.8.camel@localhost> Message-ID: <452F2F0D.1080502@trash.net> Eric Leblond wrote: > Le mercredi 11 octobre 2006 ? 23:47 +0200, Pablo Neira Ayuso a ?crit : > > >>We can warn about incompatibilities in the announce of new releases for >>this kind of minor issues that we need to fix up and that result in >>breakages, some kind of "heads up" section. > > > Why not to add a API release number in the code. > > As developper of NuFW, I've got no problem to change my code but, I need > a way to have my users not bored when they use my software. In fact I > can not control which version of libnetfilter_queue. > > Something like "#define NFQUEUE_API_VERSION NNN" in libnetfilter_queue.h > could really be used easily in application code to detect which flavour > of the API they need to use. That doesn't really solve the problem of incompatibilities. Any breakage is really bad for a supposedly stable library. Pablo's suggestion about adding new functions without breaking the old ones makes sense of course, but there is no guarantee that we won't fuck up again. Which is why I wanted to raise the question whether we want to continue this way or go back to beta state until we're reasonable sure about the API. Well, for now I guess the best way is to add the new functions and go through a really long beta phase with the new API (after releasing the current versions, which contain quite a few bugfixes since the last release). From retesh.chadha at gmail.com Fri Oct 13 08:50:22 2006 From: retesh.chadha at gmail.com (Retesh Chadha) Date: Fri Oct 13 09:27:50 2006 Subject: query regarding hashlimit using ipset src,dst tuple Message-ID: Hi I have a requirement as follows - Say there are 2 source IPs - src1 and src2, and 2 destination IP - dst1, dst2. I need to limit src1->dst1 as well as src2-dst2 communication but want unlimited src2->dst1 communication. I have a ipset KNOWN, which contains src1, src2, dst1, dst2 Now i write a rule as follows - iptables -A INPUT_CHAIN --match hashlimit --hashlimit 1000/s --hashlimit-mode srcipdstip --hashlimit-name foo -m set --set KNOWN src,dst -j ACCEPT But this will limit the src2->dst1 communication as well, which I dont want. Is there a way to add ip1,ip2 as a tuple in a ipset the way we can do for ip1%port? Is there a mode which can help me do this, using a single iptable rule as above? Is there a way to specify multiple ipsets in 1 iptable rule? Thanks & Regards Retesh Chadha From fede.hernandez at gmail.com Fri Oct 13 15:35:32 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Fri Oct 13 16:13:07 2006 Subject: new match extension to implement port knocking in one Message-ID: > On Oct 12, 2006, Alexey Toptygin wrote: > > > On Wed, 11 Oct 2006, Luis Floreani wrote: > > > > >>If you're interested in port knocking, you might want to read this > > >>paper: http://www.acsac.org/2005/abstracts/156.html It covers security > > >>issues relating to port knocking in detail, and presents an architecture > > >>for solving most of them. > > >> > > >>Full disclosure: I wrote that paper. Feel free to contact me if you > > >>have questions. > > >> > > >>Rennie deGraaf > > > > > >In our implementation, for security, we are using the Tumbler protocol, we > > >found it simple yet powerful, check it out here: > > >http://tumbler.sourceforge.net/. > > > > It seems that Tumbler is not capable of working across NAT, unless the > > client can somehow obtain its public IP address. Also, it relies on clocks > > being synchronized, since authentication will fail if the UTC time in > > minutes is not identical on the client and server. Tumbler is not as > > stealthy as the techniques in Rennie deGraaf's paper, since it uses an > > open UDP port. > > Why not use fwknop in Single Packet Authorization mode?: Why not using iptables to implement port knocking? You won't depend on any daemon. If you know the iptables syntaxis, you don't need to learn the daemon syntaxis or its configuration. -- Federico From fede.hernandez at gmail.com Sat Oct 14 00:01:54 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Sat Oct 14 00:39:27 2006 Subject: netfilter-devel Digest, Vol 27, Issue 18 In-Reply-To: <452eff66.604d9017.02d2.ffffb024SMTPIN_ADDED@mx.google.com> References: <452eff66.604d9017.02d2.ffffb024SMTPIN_ADDED@mx.google.com> Message-ID: > On Oct 12, 2006, Alexey Toptygin wrote: > > > On Wed, 11 Oct 2006, Luis Floreani wrote: > > > > >>If you're interested in port knocking, you might want to read this > > >>paper: http://www.acsac.org/2005/abstracts/156.html It covers security > > >>issues relating to port knocking in detail, and presents an architecture > > >>for solving most of them. > > >> > > >>Full disclosure: I wrote that paper. Feel free to contact me if you > > >>have questions. > > >> > > >>Rennie deGraaf > > > > > >In our implementation, for security, we are using the Tumbler protocol, we > > >found it simple yet powerful, check it out here: > > >http://tumbler.sourceforge.net/. > > > > It seems that Tumbler is not capable of working across NAT, unless the > > client can somehow obtain its public IP address. Also, it relies on clocks > > being synchronized, since authentication will fail if the UTC time in > > minutes is not identical on the client and server. Tumbler is not as > > stealthy as the techniques in Rennie deGraaf's paper, since it uses an > > open UDP port. > > Why not use fwknop in Single Packet Authorization mode?: Why not using iptables to implement port knocking? You won't depend on any daemon. If you know the iptables syntaxis, you don't need to learn the daemon syntaxis or its configuration. -- Federico From mbr at cipherdyne.org Sat Oct 14 19:19:57 2006 From: mbr at cipherdyne.org (Michael Rash) Date: Sat Oct 14 19:57:54 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: Message-ID: <20061014171957.GA31268@minastirith> On Oct 13, 2006, J. Federico Hernandez wrote: > >On Oct 12, 2006, Alexey Toptygin wrote: > > > >> On Wed, 11 Oct 2006, Luis Floreani wrote: > >> > >> >>If you're interested in port knocking, you might want to read this > >> >>paper: http://www.acsac.org/2005/abstracts/156.html It covers > >security > >> >>issues relating to port knocking in detail, and presents an > >architecture > >> >>for solving most of them. > >> >> > >> >>Full disclosure: I wrote that paper. Feel free to contact me if you > >> >>have questions. > >> >> > >> >>Rennie deGraaf > >> > > >> >In our implementation, for security, we are using the Tumbler protocol, > >we > >> >found it simple yet powerful, check it out here: > >> >http://tumbler.sourceforge.net/. > >> > >> It seems that Tumbler is not capable of working across NAT, unless the > >> client can somehow obtain its public IP address. Also, it relies on > >clocks > >> being synchronized, since authentication will fail if the UTC time in > >> minutes is not identical on the client and server. Tumbler is not as > >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an > >> open UDP port. > > > >Why not use fwknop in Single Packet Authorization mode?: > > Why not using iptables to implement port knocking? > You won't depend on any daemon. > > If you know the iptables syntaxis, you don't need to learn the daemon > syntaxis or its configuration. > > Federico Well, I agree that having an implementation that builds some port knocking capabilities directly into iptables is a good thing for the reasons you mention. However, I would say that there are some design considerations that warrant userspace implementations as well. Users should be able to select the system that offers the best security properties, and putting both the authentication and authorization verification code in the kernel is not always going to meet everyone's needs. (Sorry for the length of this email, but I want to be thorough). First, port knocking as opposed to single packet strategies have some serious problems: - Hard to solve the replay problem - Insufficient data transfer rate and reliability because of necessary time delays to enforce packet ordering to make reasonably sized data transfers (asymmetric encryption is not even an option) - Knock sequences look like port scans - Trivially easy to bust a knock sequence just by spoofing a duplicate packet into the sequence The NAT issue and the lack of association between a knock sequence and follow-on connection mentioned in deGraaf's paper are important, but I think we basically have to live with it in any practical implementation that is generally deployable. And, these two limitations extend to single-packet solutions as well. (Although, if you run both SPA and the follow-on SSH connection over the Tor network - at the expense of having an established TCP connection for the SPA packet - and you use the MapAddress functionality to request a specific exit router, then it is possible to overcome the NAT issue, see http://www.cipherdyne.org/fwknop/docs/talks/dc14_fwknop_slides.pdf). Still, single-packet solutions are generally the way to go (assuming we are looking for a scheme that has good security properties). So, your hmac method from within iptables is the most interesting. Some differences between this method and using a userspace daemon with an encrypted payload include: - Clients cannot include information that the server might use to differentiate them. For example, the server might require that the client include both a valid username and crypt() password on the local system that can be verified (or even talking with an LDAP server first) before opening the firewall. If you changed your protocol to include the hmac of the and the appended additional information, that would work, but it would have to be sent in the clear. Your userspace daemon could perform these userland verifications, but by then the firewall is already open. (Fwknop supports the username/password verification via crypt(), but not the LDAP bit yet). - The above also extends to the clients determining the access rules themselves, and also sending complete commands across. (Neither of these are probably a big requirement on the part of users, but they are worth mentioning, and fwknop supports both). - The hmac non-replay functionality does allow replays for up to one minute, correct? I.e. multiple identical hmac packets could be sent for up to one minute and all would be honored by iptables? Suppose a user does: knock.sh opensecret; ssh user@host "do command"; knock.sh closesecret Then an attacker would still have one minute in order to replay the first opensecret packet, and the IP would be allowed through until the attacker decides to voluntarily send the closesecret packet, yes? Fwknop never allows duplicate SPA packets, period. - The hmac functionality allows new sessions to be initiated until a client decides to close access. This magnifies the NAT problem. In fwknop, because all ACCEPT rules are automatically deleted after a configurable amount of time and sessions remain open with Netfilter's conntrack facilities, the NAT problem is minimized. I wonder if you could move to a timeout architecture within your pknock match? - Finally, a userspace implementation is free to support any number of encryption schemes (as implemented by projects that concentrate in that area), many of which I doubt will ever be put within the kernel. Fwknop can take advantage of the benefits of asymmetric ciphers with GnuPG (as implemented by the GnuPG project itself) for example. While I think that having the hmac functionality in iptables would meet the needs of many users, I think the above shows that the effort of learning a new daemon syntax is worth having a userspace implementation with more robust security properties. If I have misunderstood your architecture, please correct me. -- Michael Rash http://www.cipherdyne.org/ Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F From thezema at gmail.com Sun Oct 15 15:01:19 2006 From: thezema at gmail.com (Thomas Mader) Date: Sun Oct 15 15:39:42 2006 Subject: remove connections notification by conntrack? In-Reply-To: <4516A577.7080802@netfilter.org> References: <200609221359.22676.thezema@gmail.com> <200609241151.31689.thezema@gmail.com> <4516A577.7080802@netfilter.org> Message-ID: <200610151501.28715.thezema@gmail.com> Hi Pablo, we figured out what the problem was some time ago, sorry for the delay. We forgot to put it back as you said earlier. We want to publish our code soon here on the mailinglist to finish this topic and to help others with our code as an example but we don't find out how to send ICMP packets from kernelspace. Maybe you or somebody else could point us to some code example or something so we can implement it? We searched the kernel code and the net for examples but we wasn't successful at finding working examples. We want to send an ICMP echo request to the destination of the UDP flows and measure the round-trip-time with the returning echo reply. Here is something of what we tried to send such a request. struct sk_buff *buf; struct iphdr* iph = (struct iphdr*)kmalloc(sizeof(struct iphdr), GFP_KERNEL); struct icmphdr* icmph = (struct icmphdr*)kmalloc(sizeof(struct icmphdr), GFP_KERNEL); if (!iph || !icmph) printk("Could not allocate iph or icmph\n"); buf = alloc_skb(sizeof(struct iphdr) + sizeof(struct icmphdr)+ 2*(skb->dev->addr_len+4) + LL_RESERVED_SPACE(skb->dev), GFP_ATOMIC); //buf = dev_alloc_skb(sizeof(struct iphdr) + sizeof(struct icmphdr)); if(!buf) printk("error\n"); skb_reserve(buf, LL_RESERVED_SPACE(skb->dev)); buf->nh.iph = buf->data; icmph = (struct icmphdr *) skb_put(buf,sizeof(struct iphdr) + sizeof(struct icmphdr) + 2*(skb->dev->addr_len+4)); buf->dev = skb->dev; buf->protocol = htons(ETH_P_IP); buf->sk = skb->sk; icmph->type = ICMP_ECHO; //8 icmph->code = ICMP_ECHO; //0 icmph->checksum = 0; icmph->un.echo.id = connection_id; icmph->un.echo.sequence = 0; iph->version = 4; iph->ihl = 5; iph->tos = 0; iph->tot_len = sizeof(struct iphdr) + sizeof(struct icmphdr); iph->id = htons(0); iph->frag_off = 0; iph->ttl = 64; iph->protocol = IPPROTO_ICMP; // iph->check //in_cksum((unsigned short *)ip, sizeof(struct iphdr)); iph->saddr = skb->nh.iph->daddr; iph->daddr = skb->nh.iph->saddr; // buf.mac.raw = // buf.cb = NULL; buf->h.icmph = icmph; buf->nh.iph = iph; p->echo_request = 1;*/ //TODO send ICMP echo request // We are getting a warning for the first arg here, dunno why //icmp_send(buf, 8, 0, 0); //icmp_send(buf, ICMP_ECHO , ICMP_ECHO , 0); skb->sk = icmp_socket->sk; icmp_send(skb, ICMP_ECHO, ICMP_ECHO, 0); //kfree(buf); //kfree(iph); //kfree(icmph); best regards, Thomas On Sunday 24 September 2006 17:34, you wrote: > Thomas Mader wrote: > > On Sunday 24 September 2006 05:10, Pablo Neira Ayuso wrote: > >> events & IPCT_DESTROY > >> > >>> printk("We have been notified that connection %d was deleted!\n", > >>> ct->id); } > >>> > >>> return 0; > >>> } > >>> > >>> > >>> static struct notifier_block ctnl_notifier = { > >>> .notifier_call = ipaddr_conntrack_event, > >>> }; > >>> > >>> > >>> static int __init init(void) > >>> { > >>> int ret; > >>> need_conntrack(); > >>> ret = ip_conntrack_register_notifier(&ctnl_notifier); > >>> if (ret < 0) { > >>> printk("ipaddr_init: cannot register notifier.\n"); > >>> goto err_unreg_notifier; > >>> } > >>> //ip_conntrack_destroyed = destroyed_connect; > >>> > >>> printk(KERN_CRIT "init!\n"); > >>> return ipt_register_match(&ipaddr_match); > >>> > >>> err_unreg_notifier: > >>> ip_conntrack_unregister_notifier(&ctnl_notifier); > >>> return 1; > >>> } > >>> > >>> But the problem remains the same. It works for TCP and I get properly > >>> notified about those but not about UDP. > >> > >> Try with what I told you above and let me know if it works > > > > No it doesn't. I tried "events & IPCT_DESTROY" already and it didn't > > work. Now I tested it once again with same result. > > Works fine here with the toy module attached: > > Sep 24 17:30:52 Decadence kernel: protonum=17 > Sep 24 17:31:26 Decadence last message repeated 2 times > Sep 24 17:31:47 Decadence kernel: protonum=6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061015/66992f38/attachment-0001.pgp From pablo at netfilter.org Sun Oct 15 18:11:02 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Sun Oct 15 18:41:53 2006 Subject: remove connections notification by conntrack? In-Reply-To: <200610151501.28715.thezema@gmail.com> References: <200609221359.22676.thezema@gmail.com> <200609241151.31689.thezema@gmail.com> <4516A577.7080802@netfilter.org> <200610151501.28715.thezema@gmail.com> Message-ID: <45325D96.9090004@netfilter.org> Thomas Mader wrote: > we figured out what the problem was some time ago, sorry for the delay. We > forgot to put it back as you said earlier. > We want to publish our code soon here on the mailinglist to finish this topic > and to help others with our code as an example but we don't find out how to > send ICMP packets from kernelspace. > Maybe you or somebody else could point us to some code example or something so > we can implement it? We searched the kernel code and the net for examples but > we wasn't successful at finding working examples. Is send_icmp what you look for? See ipt_REJECT.c, I think that it can serve as example. -- 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 thezema at gmail.com Sun Oct 15 19:03:00 2006 From: thezema at gmail.com (Thomas Mader) Date: Sun Oct 15 19:41:15 2006 Subject: remove connections notification by conntrack? In-Reply-To: <45325D96.9090004@netfilter.org> References: <200609221359.22676.thezema@gmail.com> <200610151501.28715.thezema@gmail.com> <45325D96.9090004@netfilter.org> Message-ID: <200610151903.05371.thezema@gmail.com> We started to look into ipt_REJECT.c and searched through the code for send_icmp examples but we never were successful on sending paket. It seems the problems lies in the setup of an skb for send_icmp. As you can see from the codesample earlier we played around with setting it up but nothing worked. We also tried to generate a raw socket for it but nothing was successful. We also never found a code part in the kernel where the skb is created by searching on occurances of send_icmp. On Sunday 15 October 2006 18:11, you wrote: > Thomas Mader wrote: > > we figured out what the problem was some time ago, sorry for the delay. > > We forgot to put it back as you said earlier. > > We want to publish our code soon here on the mailinglist to finish this > > topic and to help others with our code as an example but we don't find > > out how to send ICMP packets from kernelspace. > > Maybe you or somebody else could point us to some code example or > > something so we can implement it? We searched the kernel code and the net > > for examples but we wasn't successful at finding working examples. > > Is send_icmp what you look for? See ipt_REJECT.c, I think that it can > serve as example. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061015/894fafee/attachment.pgp From tsuneo.yoshioka at f-secure.com Mon Oct 16 05:17:58 2006 From: tsuneo.yoshioka at f-secure.com (Yoshioka Tsuneo) Date: Mon Oct 16 05:55:49 2006 Subject: Request: including tproxy patch to official iptables/kernel. Message-ID: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> Hello netfilter developers There is tproxy patch for netfilter(iptables). tproxy enables application to set source IP address. I think that only tproxy patch can enable transparent proxy keeping source IP addresses. And, until now, tproxy is developed and is used for long term, and seems stable to include official iptables/kernel release. There is also a patch for latest kernel. So, I would like to suggest to include tproxy patch to official iptables/kernel release. Can you think about including this patch to official iptables/kernel release, if possible ? TPROXY http://www.balabit.com/products/oss/tproxy/ patch-o-matic extra repository tproxy - iptables TPROXY target http://www.iptables.org/projects/patch-o-matic/pom-extra.html#pom-extra-tproxy Thank you ! -- Nihon F-Secure Corporation (Yoshioka Tsuneo) E-MAIL: Tsuneo.Yoshioka@f-secure.com From kaber at trash.net Mon Oct 16 07:48:34 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 16 08:26:47 2006 Subject: Request: including tproxy patch to official iptables/kernel. In-Reply-To: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> References: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> Message-ID: <45331D32.5070209@trash.net> Yoshioka Tsuneo wrote: > Hello netfilter developers > > There is tproxy patch for netfilter(iptables). > tproxy enables application to set source IP address. > I think that only tproxy patch can enable transparent proxy keeping > source IP addresses. > > And, until now, tproxy is developed and is used for long term, and seems > stable to include official iptables/kernel release. There is also a patch > for latest kernel. > > So, I would like to suggest to include tproxy patch to official > iptables/kernel release. > Can you think about including this patch to official iptables/kernel > release, if possible ? > > TPROXY > http://www.balabit.com/products/oss/tproxy/ > > patch-o-matic extra repository > tproxy - iptables TPROXY target > http://www.iptables.org/projects/patch-o-matic/pom-extra.html#pom-extra-tproxy These look quite old (2.4). The TPROXY developers were working on a new approach last year at the netfilter workshop, but I don't know if there was any further progress. Please talk to them directly and ask them if they want to merge it upstream, and if so to submit patches. From tsuneo.yoshioka at f-secure.com Mon Oct 16 09:28:42 2006 From: tsuneo.yoshioka at f-secure.com (Yoshioka Tsuneo) Date: Mon Oct 16 10:06:29 2006 Subject: Request: including tproxy patch to official iptables/kernel. In-Reply-To: <45331D32.5070209@trash.net> References: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> <45331D32.5070209@trash.net> Message-ID: <20061016161823.E8F0.TSUNEO.YOSHIOKA@f-secure.com> Hello Patrick McHardy Thank you for your reply ! > > So, I would like to suggest to include tproxy patch to official > > iptables/kernel release. > > Can you think about including this patch to official iptables/kernel > > release, if possible ? > > > > TPROXY > > http://www.balabit.com/products/oss/tproxy/ > > > > patch-o-matic extra repository > > tproxy - iptables TPROXY target > > http://www.iptables.org/projects/patch-o-matic/pom-extra.html#pom-extra-tproxy > > > These look quite old (2.4). The TPROXY developers were working on > a new approach last year at the netfilter workshop, but I don't > know if there was any further progress. Please talk to them directly > and ask them if they want to merge it upstream, and if so to submit > patches. Both patch for kernel2.4 and 2.6 is available on the following URL. http://www.balabit.com/downloads/tproxy/linux-2.4/ Now, following packages are available as the latest version. cttproxy-2.4.32-2.0.5.tar.gz File 70.47k 09/12/2006 cttproxy-2.4.33-2.0.5.tar.gz File 70.29k 09/12/2006 cttproxy-2.6.16-2.0.5.tar.gz File 55.49k 09/12/2006 cttproxy-2.6.17-2.0.5.tar.gz File 55.64k 09/12/2006 cttproxy-2.6.18-2.0.5.tar.gz File 55.58k 09/12/2006 Is there any other thing I or the patch developer can do ? I would appreciate it if you can merge these patches to the official iptables/release. How about it ? Thank you ! -- Nihon F-Secure Corporation (Yoshioka Tsuneo) E-MAIL: Tsuneo.Yoshioka@f-secure.com From kaber at trash.net Mon Oct 16 09:56:36 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 16 10:34:32 2006 Subject: Request: including tproxy patch to official iptables/kernel. In-Reply-To: <20061016161823.E8F0.TSUNEO.YOSHIOKA@f-secure.com> References: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> <45331D32.5070209@trash.net> <20061016161823.E8F0.TSUNEO.YOSHIOKA@f-secure.com> Message-ID: <45333B34.5070400@trash.net> Yoshioka Tsuneo wrote: > I would appreciate it if you can merge these patches to the official > iptables/release. How about it ? Again, please talk to the TPROXY developers and ask them to submit patches in case they want to merge it. From fede.hernandez at gmail.com Mon Oct 16 17:10:46 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Mon Oct 16 17:48:39 2006 Subject: new match extension to implement port knocking in one Message-ID: > On Oct 14, 2006, Michael Rash wrote: > > > On Oct 13, 2006, J. Federico Hernandez wrote: > > > > >On Oct 12, 2006, Alexey Toptygin wrote: > > > > > >> On Wed, 11 Oct 2006, Luis Floreani wrote: > > >> > > >> >>If you're interested in port knocking, you might want to read this > > >> >>paper: http://www.acsac.org/2005/abstracts/156.html It covers > > >security > > >> >>issues relating to port knocking in detail, and presents an > > >architecture > > >> >>for solving most of them. > > >> >> > > >> >>Full disclosure: I wrote that paper. Feel free to contact me if you > > >> >>have questions. > > >> >> > > >> >>Rennie deGraaf > > >> > > > >> >In our implementation, for security, we are using the Tumbler protocol, > > >we > > >> >found it simple yet powerful, check it out here: > > >> >http://tumbler.sourceforge.net/. > > >> > > >> It seems that Tumbler is not capable of working across NAT, unless the > > >> client can somehow obtain its public IP address. Also, it relies on > > >clocks > > >> being synchronized, since authentication will fail if the UTC time in > > >> minutes is not identical on the client and server. Tumbler is not as > > >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an > > >> open UDP port. > > > > > >Why not use fwknop in Single Packet Authorization mode?: > > > > Why not using iptables to implement port knocking? > > You won't depend on any daemon. > > > > If you know the iptables syntaxis, you don't need to learn the daemon > > syntaxis or its configuration. > > > > Well, I agree that having an implementation that builds some port > knocking capabilities directly into iptables is a good thing for the > reasons you mention. However, I would say that there are some design > considerations that warrant userspace implementations as well. Users > should be able to select the system that offers the best security > properties, and putting both the authentication and authorization > verification code in the kernel is not always going to meet everyone's > needs. We think that recognizing a port knocking sequence is an issue of the firewall (netfilter in this case), and if you want to open a port after a correct seq, the firewall is also the place. But sometimes you want to trigger a more complex action from this correct knock seq (e.g. start a webserver), so we allow to send a netlink msg from kernel to a listening userspace application that could decide what action to take. This userspace app is not scanning logs nor sniffing your iface, it's just waiting to receive an important message from kernel. here is a nice intro to netlink sockets: http://www.linuxjournal.com/article/7356 > First, port knocking as opposed to single packet strategies have some > serious problems: > > - Hard to solve the replay problem > - Insufficient data transfer rate and reliability because of necessary > time delays to enforce packet ordering to make reasonably sized > data transfers (asymmetric encryption is not even an option) > - Knock sequences look like port scans Tumbler is a Single Packet Authorization protocol. We offer 2 modes of operation: the traditional port knock sequence and the SPA way. > - Trivially easy to bust a knock sequence just by spoofing a duplicate > packet into the sequence This is not possible with our anti-replay option. Luis Floreani: "In our implementation there is no room for replay, cause each knock must change from minute to minute, and we just allow one knock per peer(IP) per minute. So if you knock(open), then connect, then knock(close), in the remaining minute, a replay would be useless cause that peer is "blocked" in that minute. Look at the function has_logged_during_this_minute(), that solves this issue." Rennie deGraaf: "That's quite a clever idea. I never thought of using rate-limiting in my system." > The NAT issue and the lack of association between a knock sequence and > follow-on connection mentioned in deGraaf's paper are important, but I > think we basically have to live with it in any practical implementation > that is generally deployable. And, these two limitations extend to > single-packet solutions as well. The NAT issue is a general problem with portknocking. Doesn't exist any portknocking application that solves it, for a while. > (Although, if you run both SPA and the > follow-on SSH connection over the Tor network - at the expense of having > an established TCP connection for the SPA packet - and you use the > MapAddress functionality to request a specific exit router, then it is > possible to overcome the NAT issue, see > http://www.cipherdyne.org/fwknop/docs/talks/dc14_fwknop_slides.pdf). I will read this paper soon. > Still, single-packet solutions are generally the way to go (assuming we > are looking for a scheme that has good security properties). > > So, your hmac method from within iptables is the most interesting. Some > differences between this method and using a userspace daemon with an > encrypted payload include: > > - Clients cannot include information that the server might use to > differentiate them. For example, the server might require that the > client include both a valid username and crypt() password on the local > system that can be verified (or even talking with an LDAP server > first) before opening the firewall. If you changed your protocol to > include the hmac of the and the appended > additional information, that would work, but it would have to be sent > in the clear. Yes, adding users would allow granularity decisions, by now we prefer a more general and simple approach. Maybe in a near future we consider users. > - The above also extends to the clients determining the access rules > themselves, and also sending complete commands across. (Neither of > these are probably a big requirement on the part of users, but they > are worth mentioning, and fwknop supports both). Yes, sending commands could be seen as a good feature, but also could be a security issue, We prefer to "hardcode" the action in the iptables rule or let the userspace app (see netlink sockets) decide the action, rather than the client. > - The hmac non-replay functionality does allow replays for up to one > minute, correct? I.e. multiple identical hmac packets could be sent > for up to one minute and all would be honored by iptables? Suppose > a user does: > > knock.sh opensecret; ssh user@host "do command"; knock.sh closesecret > > Then an attacker would still have one minute in order to replay the > first opensecret packet, and the IP would be allowed through until > the attacker decides to voluntarily send the closesecret packet, yes? as mentioned before, we just allow ONE knock PER peer(IP) PER minute. Replay attacks are not possible here, cause the epoch min do change every min. > - The hmac functionality allows new sessions to be initiated until a > client decides to close access. This magnifies the NAT problem. > In fwknop, because all ACCEPT rules are automatically deleted > after a configurable amount of time and sessions remain open with > Netfilter's conntrack facilities, the NAT problem is minimized. Yes, we are thinking about this idea of conntrack to avoid the "manual" close knock, but remember that someone could cause a DoS, spoofing your IP and just trying to establish a connection before you. > I wonder if you could move to a timeout architecture within your pknock > match? We have a garbage collector that runs from time to time to clean already allowed and "defunct" peers. > - Finally, a userspace implementation is free to support any number of > encryption schemes (as implemented by projects that concentrate in that > area), many of which I doubt will ever be put within the kernel. > Fwknop can take advantage of the benefits of asymmetric ciphers with > GnuPG (as implemented by the GnuPG project itself) for example. With a port knocking application any users manipulate firewall rules. Would you allow that any users or application change your firewall configuration on the fly? What happens if a port knocking daemon is shutdowned by a remote attacker. If the daemon dies, then no further authentication is possible. > While I think that having the hmac functionality in iptables would meet > the needs of many users, I think the above shows that the effort of > learning a new daemon syntax is worth having a userspace implementation > with more robust security properties. If I have misunderstood your > architecture, please correct me. We think our architecture is flexible enough so you can spread functionality between kernel and userspace (through netlink sockets), as we we mention before. regards, -- Federico From pablo at netfilter.org Tue Oct 17 03:23:43 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Tue Oct 17 03:54:36 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: Message-ID: <4534309F.8000200@netfilter.org> J. Federico Hernandez wrote: >> On Oct 14, 2006, Michael Rash wrote: >> >> Well, I agree that having an implementation that builds some port >> knocking capabilities directly into iptables is a good thing for the >> reasons you mention. However, I would say that there are some design >> considerations that warrant userspace implementations as well. Users >> should be able to select the system that offers the best security >> properties, and putting both the authentication and authorization >> verification code in the kernel is not always going to meet everyone's >> needs. > > We think that recognizing a port knocking sequence is an issue of the > firewall (netfilter in this case), and if you want to open a port > after a correct seq, the firewall is also the place. But sometimes you > want to trigger a more complex action from this correct knock seq > (e.g. start a webserver), so we allow to send a netlink msg from > kernel to a listening userspace application that could decide what > action to take. This userspace app is not scanning logs nor sniffing > your iface, it's just waiting to receive an important message from > kernel. Perhaps I'm just influenced by my first impression but I think that this thing should be in userspace. We are providing the appropiate netfilter netlink subsystems (nfqueue, nflog...) to implement this as a userland daemon. -- 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 retesh.chadha at gmail.com Tue Oct 17 08:05:30 2006 From: retesh.chadha at gmail.com (Retesh) Date: Tue Oct 17 08:43:27 2006 Subject: performance impact by increasing number of ipsets Message-ID: Hi I want to increase the number of IPsets in a system to a high number say 50000 (default is 255). What will be the impact on performance? Has someone tried this, or can some explain the implementation of the ipsets, so that I can estimate the impact on kernel? Thanks & Regards Retesh Chadha From retesh.chadha at gmail.com Tue Oct 17 08:09:35 2006 From: retesh.chadha at gmail.com (Retesh) Date: Tue Oct 17 08:47:29 2006 Subject: work on ip%ip ipset Message-ID: Hi Currently, is there any work going on, for developing a IPSet like ipiphash containing a pair of IPs as ip1%ip2, similiar to ipporthash as ip%port. This can be useful in case when scrip as well as dstip need to be stored as a tuple in a single ipset. Thanks & Regards Retesh Chadha From kadlec at blackhole.kfki.hu Tue Oct 17 10:00:00 2006 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Tue Oct 17 10:37:50 2006 Subject: performance impact by increasing number of ipsets In-Reply-To: References: Message-ID: On Tue, 17 Oct 2006, Retesh wrote: > I want to increase the number of IPsets in a system to a high number > say 50000 (default is 255). What will be the impact on performance? No problem - the sets are referred by index in netfilter (i.e in the iptables rules). The set *creation* in such a high number can take a while, however. > Has someone tried this, or can some explain the implementation of the > ipsets, so that I can estimate the impact on kernel? I haven't heard about such an extreme setup. But if such a high number of sets are really required I'd investigate other solutions like nf-hipac, which might easily be a better solution. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From kadlec at blackhole.kfki.hu Tue Oct 17 10:09:31 2006 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Tue Oct 17 10:47:20 2006 Subject: work on ip%ip ipset In-Reply-To: References: Message-ID: On Tue, 17 Oct 2006, Retesh wrote: > Currently, is there any work going on, for developing a IPSet like > ipiphash containing a pair of IPs as ip1%ip2, similiar to ipporthash > as ip%port. ipset is in maintenace mode: bugfixes and minor (backward-compatible) changes are accepted/added to the code only. nfset is under development (alas, with a huge gap in the active work), focusing on the follwing features: - netlink kernel-user interface instead of [sg]etopt - "binding" is dropped as a dead-end and new set types like the one you mentioned will be introduced: ip-ip pairs, etc. - IPv6 address support 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 retesh.chadha at gmail.com Tue Oct 17 10:45:27 2006 From: retesh.chadha at gmail.com (Retesh) Date: Tue Oct 17 11:23:26 2006 Subject: work on ip%ip ipset In-Reply-To: References: Message-ID: Hi Jozsef When is nfset implementation expected to be released? Thanks & Regards Retesh Chadha From kadlec at blackhole.kfki.hu Tue Oct 17 11:07:15 2006 From: kadlec at blackhole.kfki.hu (Jozsef Kadlecsik) Date: Tue Oct 17 11:45:04 2006 Subject: work on ip%ip ipset In-Reply-To: References: Message-ID: On Tue, 17 Oct 2006, Retesh wrote: > When is nfset implementation expected to be released? I expect it to be released in the first quarter of 2007. 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 fede.hernandez at gmail.com Tue Oct 17 14:19:16 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Tue Oct 17 14:57:16 2006 Subject: new match extension to implement port knocking in one In-Reply-To: <4534309F.8000200@netfilter.org> References: <4534309F.8000200@netfilter.org> Message-ID: On 10/16/06, Pablo Neira Ayuso wrote: > J. Federico Hernandez wrote: > >> On Oct 14, 2006, Michael Rash wrote: > >> > >> Well, I agree that having an implementation that builds some port > >> knocking capabilities directly into iptables is a good thing for the > >> reasons you mention. However, I would say that there are some design > >> considerations that warrant userspace implementations as well. Users > >> should be able to select the system that offers the best security > >> properties, and putting both the authentication and authorization > >> verification code in the kernel is not always going to meet everyone's > >> needs. > > > > We think that recognizing a port knocking sequence is an issue of the > > firewall (netfilter in this case), and if you want to open a port > > after a correct seq, the firewall is also the place. But sometimes you > > want to trigger a more complex action from this correct knock seq > > (e.g. start a webserver), so we allow to send a netlink msg from > > kernel to a listening userspace application that could decide what > > action to take. This userspace app is not scanning logs nor sniffing > > your iface, it's just waiting to receive an important message from > > kernel. > > Perhaps I'm just influenced by my first impression but I think that this > thing should be in userspace. We are providing the appropiate netfilter > netlink subsystems (nfqueue, nflog...) to implement this as a userland > daemon. > When all you want is to open a port after a correct sequence of knocks, instead of sending from the kernel all the knocks to the userspace, and then setting a new iptables rule so the kernel firewall takes an action, it would be better to leave the whole work to the kernel and avoid the transition kernel->userspace->kernel. In other more complex situations, you can recognize the knocks in the kernel and let a userspace app take an action using netlink sockets, as you say, but you should never allow a port knocking app to add or remove firewall rules on the fly. Regards. -- Federico From eric at inl.fr Tue Oct 17 16:05:12 2006 From: eric at inl.fr (Eric Leblond) Date: Tue Oct 17 16:43:50 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: <4534309F.8000200@netfilter.org> Message-ID: <1161093912.20036.3.camel@localhost.localdomain> Le mardi 17 octobre 2006 ? 09:19 -0300, J. Federico Hernandez a ?crit : > On 10/16/06, Pablo Neira Ayuso wrote: > > J. Federico Hernandez wrote: > > >> On Oct 14, 2006, Michael Rash wrote: > > >> > > >> Well, I agree that having an implementation that builds some port > > >> knocking capabilities directly into iptables is a good thing for the > > > > Perhaps I'm just influenced by my first impression but I think that this > > thing should be in userspace. We are providing the appropiate netfilter > > netlink subsystems (nfqueue, nflog...) to implement this as a userland > > daemon. > > > > When all you want is to open a port after a correct sequence of > knocks, instead of sending from the kernel all the knocks to the > userspace, and then setting a new iptables rule so the kernel firewall > takes an action, it would be better to leave the whole work to the > kernel and avoid the transition kernel->userspace->kernel. kernel->userspace->kernel is really not a problem for nowadays computer. Simply think about snort-inline which is able to handle a great amount of traffic. > In other more complex situations, you can recognize the knocks in the > kernel and let a userspace app take an action using netlink sockets, > as you say, but you should never allow a port knocking app to add or > remove firewall rules on the fly. I don't think this was Pablo's intention : you can queue packet for all port including the one that must pass through and when the port knocking sequence is complete, allow packet to go through target port from userspace. BR, -- ?ric Leblond, eleblond@inl.fr T?l?phone : 01 44 89 46 39, Fax : 01 44 89 45 01 INL, http://www.inl.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : /pipermail/netfilter-devel/attachments/20061017/8a485991/attachment.pgp From hidden at balabit.hu Tue Oct 17 16:38:24 2006 From: hidden at balabit.hu (KOVACS Krisztian) Date: Tue Oct 17 17:16:41 2006 Subject: Request: including tproxy patch to official iptables/kernel. In-Reply-To: <45331D32.5070209@trash.net> References: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> <45331D32.5070209@trash.net> Message-ID: <200610171638.25425@nienna> Hi, On Monday 16 October 2006 07:48, Patrick McHardy wrote: > > So, I would like to suggest to include tproxy patch to official > > iptables/kernel release. > > These look quite old (2.4). The TPROXY developers were working on > a new approach last year at the netfilter workshop, but I don't > know if there was any further progress. Please talk to them directly > and ask them if they want to merge it upstream, and if so to submit > patches. Yes, there was significant progress since then, we're testing the patches at the moment. There still are a couple of problems with the new approach, but it certainly looks promising. I'll post the patches on netfilter-devel for review and comments as soon as things have settled down a bit. Instead of trying to get the 2.0 branch of tproxy merged into mainline we're concentrating our efforts on getting the new code working. As the maintainer of the current tproxy patchset, I do not consider it clean and safe enough to have it merged upstream. Moreover, I think there's no general consensus between networking maintainers whether or not the features tproxy provides are worth the hassles. Transparent proxying features have been removed during the 2.3 development as there seemed little interest in those. Of course there are a handful of companies interested in having the feature in mainline, but let's face the facts: the majority of users do not care about tproxy. That's why I don't even try to get it merged. -- Regards, Krisztian Kovacs From mbr at cipherdyne.org Tue Oct 17 17:12:05 2006 From: mbr at cipherdyne.org (Michael Rash) Date: Tue Oct 17 17:56:02 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: Message-ID: <20061017151205.GA6494@minastirith> On Oct 16, 2006, J. Federico Hernandez wrote: > >On Oct 14, 2006, Michael Rash wrote: > > > >> On Oct 13, 2006, J. Federico Hernandez wrote: > >> > >> >On Oct 12, 2006, Alexey Toptygin wrote: > >> > > >> >> On Wed, 11 Oct 2006, Luis Floreani wrote: > >> >> > >> >> >>If you're interested in port knocking, you might want to read this > >> >> >>paper: http://www.acsac.org/2005/abstracts/156.html It covers > >> >security > >> >> >>issues relating to port knocking in detail, and presents an > >> >architecture > >> >> >>for solving most of them. > >> >> >> > >> >> >>Full disclosure: I wrote that paper. Feel free to contact me if > >you > >> >> >>have questions. > >> >> >> > >> >> >>Rennie deGraaf > >> >> > > >> >> >In our implementation, for security, we are using the Tumbler > >protocol, > >> >we > >> >> >found it simple yet powerful, check it out here: > >> >> >http://tumbler.sourceforge.net/. > >> >> > >> >> It seems that Tumbler is not capable of working across NAT, unless the > >> >> client can somehow obtain its public IP address. Also, it relies on > >> >clocks > >> >> being synchronized, since authentication will fail if the UTC time in > >> >> minutes is not identical on the client and server. Tumbler is not as > >> >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an > >> >> open UDP port. > >> > > >> >Why not use fwknop in Single Packet Authorization mode?: > >> > >> Why not using iptables to implement port knocking? > >> You won't depend on any daemon. > >> > >> If you know the iptables syntaxis, you don't need to learn the daemon > >> syntaxis or its configuration. > >> > > > >Well, I agree that having an implementation that builds some port > >knocking capabilities directly into iptables is a good thing for the > >reasons you mention. However, I would say that there are some design > >considerations that warrant userspace implementations as well. Users > >should be able to select the system that offers the best security > >properties, and putting both the authentication and authorization > >verification code in the kernel is not always going to meet everyone's > >needs. > > We think that recognizing a port knocking sequence is an issue of the > firewall (netfilter in this case), and if you want to open a port > after a correct seq, the firewall is also the place. But sometimes you > want to trigger a more complex action from this correct knock seq > (e.g. start a webserver), so we allow to send a netlink msg from > kernel to a listening userspace application that could decide what > action to take. This userspace app is not scanning logs nor sniffing > your iface, it's just waiting to receive an important message from > kernel. > > here is a nice intro to netlink sockets: > > http://www.linuxjournal.com/article/7356 > > >First, port knocking as opposed to single packet strategies have some > >serious problems: > > > >- Hard to solve the replay problem > >- Insufficient data transfer rate and reliability because of necessary > > time delays to enforce packet ordering to make reasonably sized > > data transfers (asymmetric encryption is not even an option) > >- Knock sequences look like port scans > > Tumbler is a Single Packet Authorization protocol. We offer 2 modes of > operation: the traditional port knock sequence and the SPA way. Right, I was treating the two modes separately (port knocking vs. SPA). I'm trying to make the case that port knocking has enough problems to motivate people to use an SPA solution instead. > >- Trivially easy to bust a knock sequence just by spoofing a duplicate > > packet into the sequence > > This is not possible with our anti-replay option. > > Luis Floreani: "In our implementation there is no room for replay, > cause each knock must change from minute to minute, and we just allow > one knock per peer(IP) per minute. So if you knock(open), then > connect, then knock(close), in the remaining minute, a replay would be > useless cause that peer is "blocked" in that minute. Look at the > function has_logged_during_this_minute(), that solves this issue." > > Rennie deGraaf: "That's quite a clever idea. I never thought of using > rate-limiting in my system." Spoofing a duplicate packet into a port knock sequence is not a replay attack. This is a DoS attack against your knock server; an attacker can force the client to appear to not know the correct knock sequence. This is yet another reason to switch to an SPA solution because it is so trivially easy to do. > >The NAT issue and the lack of association between a knock sequence and > >follow-on connection mentioned in deGraaf's paper are important, but I > >think we basically have to live with it in any practical implementation > >that is generally deployable. And, these two limitations extend to > >single-packet solutions as well. > > The NAT issue is a general problem with portknocking. Doesn't exist > any portknocking application that solves it, for a while. > > >(Although, if you run both SPA and the > >follow-on SSH connection over the Tor network - at the expense of having > >an established TCP connection for the SPA packet - and you use the > >MapAddress functionality to request a specific exit router, then it is > >possible to overcome the NAT issue, see > >http://www.cipherdyne.org/fwknop/docs/talks/dc14_fwknop_slides.pdf). > > I will read this paper soon. > > >Still, single-packet solutions are generally the way to go (assuming we > >are looking for a scheme that has good security properties). > > > >So, your hmac method from within iptables is the most interesting. Some > >differences between this method and using a userspace daemon with an > >encrypted payload include: > > > >- Clients cannot include information that the server might use to > > differentiate them. For example, the server might require that the > > client include both a valid username and crypt() password on the local > > system that can be verified (or even talking with an LDAP server > > first) before opening the firewall. If you changed your protocol to > > include the hmac of the and the appended > > additional information, that would work, but it would have to be sent > > in the clear. > > Yes, adding users would allow granularity decisions, by now we prefer > a more general and simple approach. Maybe in a near future we consider > users. Ok, but doesn't "considering users" imply more user space type functions? Sure, I suppose you can read the /etc/shadow file from kernel space and then do crypt() from within the kernel, but this is limited and seems wrong. What if you want to tie access to a remote LDAP server for example? Your user space app could do it, but then user-specific information would have to be transmitted over the netlink socket as well, correct? > >- The above also extends to the clients determining the access rules > > themselves, and also sending complete commands across. (Neither of > > these are probably a big requirement on the part of users, but they > > are worth mentioning, and fwknop supports both). > > Yes, sending commands could be seen as a good feature, but also could > be a security issue, We prefer to "hardcode" the action in the > iptables rule or let the userspace app (see netlink sockets) decide > the action, rather than the client. Yes, sending commands could be a security issue, and this is not enabled by default in fwknop; it is just there for those who find it useful (and also find that the security risks are acceptable given that fwknop is compatible with things like GnuPG, etc.). > >- The hmac non-replay functionality does allow replays for up to one > > minute, correct? I.e. multiple identical hmac packets could be sent > > for up to one minute and all would be honored by iptables? Suppose > > a user does: > > > >knock.sh opensecret; ssh user@host "do command"; knock.sh closesecret > > > > Then an attacker would still have one minute in order to replay the > > first opensecret packet, and the IP would be allowed through until > > the attacker decides to voluntarily send the closesecret packet, yes? > > as mentioned before, we just allow ONE knock PER peer(IP) PER minute. > Replay attacks are not possible here, cause the epoch min do change > every min. Ok, that's cool. > >- The hmac functionality allows new sessions to be initiated until a > > client decides to close access. This magnifies the NAT problem. > > In fwknop, because all ACCEPT rules are automatically deleted > > after a configurable amount of time and sessions remain open with > > Netfilter's conntrack facilities, the NAT problem is minimized. > > Yes, we are thinking about this idea of conntrack to avoid the > "manual" close knock, but remember that someone could cause a DoS, > spoofing your IP and just trying to establish a connection before you. I'm not sure I understand. It seems like this would be an issue only if you allow just one follow-on connection per SPA packet, yes? Fwknop uses a timeout window, so it doesn't matter how many connections are established as long as it is within the window. > > I wonder if you could move to a timeout architecture within your pknock > > match? > > We have a garbage collector that runs from time to time to clean > already allowed and "defunct" peers. > > >- Finally, a userspace implementation is free to support any number of > > encryption schemes (as implemented by projects that concentrate in that > > area), many of which I doubt will ever be put within the kernel. > > Fwknop can take advantage of the benefits of asymmetric ciphers with > > GnuPG (as implemented by the GnuPG project itself) for example. > > With a port knocking application any users manipulate firewall rules. > Would you allow that any users or application change your firewall > configuration on the fly? With strong enough security properties and a good design, yes. Fwknop always keeps rules within a custom chain in order to separate them from an existing iptables policy, has a well-defined mechanism for manipulating rules, etc. > What happens if a port knocking daemon is shutdowned by a remote > attacker. If the daemon dies, then no further authentication is > possible. Fwknop has a process monitoring daemon, and is written in a (mostly) buffer safe language (perl). Being able to be shutdown by an attacker implies a bug or design flaw - these can exist in the kernel as well to more damaging effect. > >While I think that having the hmac functionality in iptables would meet > >the needs of many users, I think the above shows that the effort of > >learning a new daemon syntax is worth having a userspace implementation > >with more robust security properties. If I have misunderstood your > >architecture, please correct me. > > We think our architecture is flexible enough so you can spread > functionality between kernel and userspace (through netlink sockets), > as we we mention before. > > regards, > > -- > Federico -- Michael Rash http://www.cipherdyne.org/ Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F From tsuneo.yoshioka at f-secure.com Tue Oct 17 18:17:55 2006 From: tsuneo.yoshioka at f-secure.com (Yoshioka Tsuneo) Date: Tue Oct 17 18:56:02 2006 Subject: [tproxy] Re: Request: including tproxy patch to official iptables/kernel. In-Reply-To: <200610171638.25425@nienna> References: <45331D32.5070209@trash.net> <200610171638.25425@nienna> Message-ID: <20061018010325.F515.TSUNEO.YOSHIOKA@f-secure.com> Hello KOVACS Krisztian > Yes, there was significant progress since then, we're testing the > patches at the moment. There still are a couple of problems with the new > approach, but it certainly looks promising. I'll post the patches on > netfilter-devel for review and comments as soon as things have settled > down a bit. Thank you for your planning to new tproxy version. I'm looking forward to the new version ! > Moreover, I think there's no general consensus between networking > maintainers whether or not the features tproxy provides are worth the > hassles. Transparent proxying features have been removed during the 2.3 > development as there seemed little interest in those. Of course there are > a handful of companies interested in having the feature in mainline, but > let's face the facts: the majority of users do not care about tproxy. > That's why I don't even try to get it merged. I think that this is not so minor request. At long as I heard, most of transparent-proxy user want to keep source IP address, if possible. Changing source IP address prevent IP address based access control or make it difficult to analize log files, or tracing. Some of appliance server can keep source IP addresses, but I think that it is better that normal kernel user can use this feature without difficulty, too. Thank you ! -- Nihon F-Secure Corporation (Yoshioka Tsuneo) E-MAIL: Tsuneo.Yoshioka@f-secure.com > > Hi, > > On Monday 16 October 2006 07:48, Patrick McHardy wrote: > > > So, I would like to suggest to include tproxy patch to official > > > iptables/kernel release. > > > > These look quite old (2.4). The TPROXY developers were working on > > a new approach last year at the netfilter workshop, but I don't > > know if there was any further progress. Please talk to them directly > > and ask them if they want to merge it upstream, and if so to submit > > patches. > > Yes, there was significant progress since then, we're testing the > patches at the moment. There still are a couple of problems with the new > approach, but it certainly looks promising. I'll post the patches on > netfilter-devel for review and comments as soon as things have settled > down a bit. > > Instead of trying to get the 2.0 branch of tproxy merged into mainline > we're concentrating our efforts on getting the new code working. As the > maintainer of the current tproxy patchset, I do not consider it clean and > safe enough to have it merged upstream. > > Moreover, I think there's no general consensus between networking > maintainers whether or not the features tproxy provides are worth the > hassles. Transparent proxying features have been removed during the 2.3 > development as there seemed little interest in those. Of course there are > a handful of companies interested in having the feature in mainline, but > let's face the facts: the majority of users do not care about tproxy. > That's why I don't even try to get it merged. > > -- > Regards, > Krisztian Kovacs > _______________________________________________ > tproxy mailing list > tproxy@lists.balabit.hu > https://lists.balabit.hu/mailman/listinfo/tproxy From rbscott at cadvium.net Wed Oct 18 00:10:25 2006 From: rbscott at cadvium.net (robert) Date: Wed Oct 18 00:48:41 2006 Subject: nfqueue/ipq difference Message-ID: <1318F807-9466-4960-9ABE-1350E9B81E6C@cadvium.net> As I was migrating to NFQUEUE, I noticed a small difference. If you are polling on an IPQ filedescriptor, then the error bit is set if the queue runs out of buffer space. In NFQUEUE, the error bit is never set, but after doing a read, there is an error. This error bit is relatively important and in most applications would want to handle a read since both IPQ and NFQUEUE will not queue any new packets until the entire buffer is flushed. (at least, this is the behavior that I am seeing). If anyone is interested, i could post two small test programs that illustrate this behavior. (not sure if this would be considered a bug). cheers, robert From rbscott at cadvium.net Wed Oct 18 00:43:06 2006 From: rbscott at cadvium.net (robert) Date: Wed Oct 18 01:21:13 2006 Subject: queue_maxlen Message-ID: <2BDDB86A-ABD4-4C53-AE17-498AB0F52B28@cadvium.net> Does NFQUEUE use the value in /proc/sys/net/ip_queue_maxlen? If not, is it possible to modify the maximum queue length for NFQUEUE? cheers, robert From eric at inl.fr Wed Oct 18 00:54:45 2006 From: eric at inl.fr (Eric Leblond) Date: Wed Oct 18 01:32:49 2006 Subject: queue_maxlen In-Reply-To: <2BDDB86A-ABD4-4C53-AE17-498AB0F52B28@cadvium.net> References: <2BDDB86A-ABD4-4C53-AE17-498AB0F52B28@cadvium.net> Message-ID: <1161125685.4002.33.camel@localhost.localdomain> Hi, Le mardi 17 octobre 2006 ? 15:43 -0700, robert a ?crit : > Does NFQUEUE use the value in /proc/sys/net/ip_queue_maxlen? If not, > is it possible to modify the maximum queue length for NFQUEUE? Not with vanilla tree. I've post a patch to enable it some times ago but It has not been incorporated into main tree : http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3628 http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3629 With that patch it is possible to do so on a per-queue basis by using the new function nfq_set_queue_maxlen. BR, -- Eric Leblond From fede.hernandez at gmail.com Wed Oct 18 02:32:12 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Wed Oct 18 03:10:14 2006 Subject: new match extension to implement port knocking in one In-Reply-To: <1161093912.20036.3.camel@localhost.localdomain> References: <4534309F.8000200@netfilter.org> <1161093912.20036.3.camel@localhost.localdomain> Message-ID: On 10/17/06, Eric Leblond wrote: > Le mardi 17 octobre 2006 ? 09:19 -0300, J. Federico Hernandez a ?crit : > > On 10/16/06, Pablo Neira Ayuso wrote: > > > J. Federico Hernandez wrote: > > > >> On Oct 14, 2006, Michael Rash wrote: > > > >> > > > >> Well, I agree that having an implementation that builds some port > > > >> knocking capabilities directly into iptables is a good thing for the > > > > > > Perhaps I'm just influenced by my first impression but I think that this > > > thing should be in userspace. We are providing the appropiate netfilter > > > netlink subsystems (nfqueue, nflog...) to implement this as a userland > > > daemon. > > > > > > > When all you want is to open a port after a correct sequence of > > knocks, instead of sending from the kernel all the knocks to the > > userspace, and then setting a new iptables rule so the kernel firewall > > takes an action, it would be better to leave the whole work to the > > kernel and avoid the transition kernel->userspace->kernel. > > kernel->userspace->kernel is really not a problem for nowadays computer. > Simply think about snort-inline which is able to handle a great amount > of traffic. the fact that nowadays computers have much more power, doesn't mean that you can forget about a simple, less complex and correct design. By the way, Linux runs in a wide spectrum of devices, like mobile devices, where you musn't waste resources. (see linksys ap wireless, smart phones, etc) regards, -- Federico From fede.hernandez at gmail.com Wed Oct 18 03:01:17 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Wed Oct 18 03:39:23 2006 Subject: new match extension to implement port knocking in one In-Reply-To: <20061017151205.GA6494@minastirith> References: <20061017151205.GA6494@minastirith> Message-ID: On 10/17/06, Michael Rash wrote: > On Oct 16, 2006, J. Federico Hernandez wrote: > > > >On Oct 14, 2006, Michael Rash wrote: > > > > > >> On Oct 13, 2006, J. Federico Hernandez wrote: > > >> > > >> >On Oct 12, 2006, Alexey Toptygin wrote: > > >> > > > >> >> On Wed, 11 Oct 2006, Luis Floreani wrote: > > >> >> > > >> >> >>If you're interested in port knocking, you might want to read this > > >> >> >>paper: http://www.acsac.org/2005/abstracts/156.html It covers > > >> >security > > >> >> >>issues relating to port knocking in detail, and presents an > > >> >architecture > > >> >> >>for solving most of them. > > >> >> >> > > >> >> >>Full disclosure: I wrote that paper. Feel free to contact me if > > >you > > >> >> >>have questions. > > >> >> >> > > >> >> >>Rennie deGraaf > > >> >> > > > >> >> >In our implementation, for security, we are using the Tumbler > > >protocol, > > >> >we > > >> >> >found it simple yet powerful, check it out here: > > >> >> >http://tumbler.sourceforge.net/. > > >> >> > > >> >> It seems that Tumbler is not capable of working across NAT, unless the > > >> >> client can somehow obtain its public IP address. Also, it relies on > > >> >clocks > > >> >> being synchronized, since authentication will fail if the UTC time in > > >> >> minutes is not identical on the client and server. Tumbler is not as > > >> >> stealthy as the techniques in Rennie deGraaf's paper, since it uses an > > >> >> open UDP port. > > >> > > > >> >Why not use fwknop in Single Packet Authorization mode?: > > >> > > >> Why not using iptables to implement port knocking? > > >> You won't depend on any daemon. > > >> > > >> If you know the iptables syntaxis, you don't need to learn the daemon > > >> syntaxis or its configuration. > > >> > > > > > >Well, I agree that having an implementation that builds some port > > >knocking capabilities directly into iptables is a good thing for the > > >reasons you mention. However, I would say that there are some design > > >considerations that warrant userspace implementations as well. Users > > >should be able to select the system that offers the best security > > >properties, and putting both the authentication and authorization > > >verification code in the kernel is not always going to meet everyone's > > >needs. > > > > We think that recognizing a port knocking sequence is an issue of the > > firewall (netfilter in this case), and if you want to open a port > > after a correct seq, the firewall is also the place. But sometimes you > > want to trigger a more complex action from this correct knock seq > > (e.g. start a webserver), so we allow to send a netlink msg from > > kernel to a listening userspace application that could decide what > > action to take. This userspace app is not scanning logs nor sniffing > > your iface, it's just waiting to receive an important message from > > kernel. > > > > here is a nice intro to netlink sockets: > > > > http://www.linuxjournal.com/article/7356 > > > > >First, port knocking as opposed to single packet strategies have some > > >serious problems: > > > > > >- Hard to solve the replay problem > > >- Insufficient data transfer rate and reliability because of necessary > > > time delays to enforce packet ordering to make reasonably sized > > > data transfers (asymmetric encryption is not even an option) > > >- Knock sequences look like port scans > > > > Tumbler is a Single Packet Authorization protocol. We offer 2 modes of > > operation: the traditional port knock sequence and the SPA way. > > Right, I was treating the two modes separately (port knocking vs. SPA). > I'm trying to make the case that port knocking has enough problems to > motivate people to use an SPA solution instead. we agree, that's why we offer both solutions. > > > > > >- Clients cannot include information that the server might use to > > > differentiate them. For example, the server might require that the > > > client include both a valid username and crypt() password on the local > > > system that can be verified (or even talking with an LDAP server > > > first) before opening the firewall. If you changed your protocol to > > > include the hmac of the and the appended > > > additional information, that would work, but it would have to be sent > > > in the clear. > > > > Yes, adding users would allow granularity decisions, by now we prefer > > a more general and simple approach. Maybe in a near future we consider > > users. > > Ok, but doesn't "considering users" imply more user space type functions? > Sure, I suppose you can read the /etc/shadow file from kernel space and > then do crypt() from within the kernel, but this is limited and seems > wrong. What if you want to tie access to a remote LDAP server for > example? Your user space app could do it, but then user-specific > information would have to be transmitted over the netlink socket as > well, correct? > the listening(netlink sockets) userspace app can receive as much information as you want, in fact, the bytes received from the socket are casted to a struct, containing n items. > > > >- The hmac functionality allows new sessions to be initiated until a > > > client decides to close access. This magnifies the NAT problem. > > > In fwknop, because all ACCEPT rules are automatically deleted > > > after a configurable amount of time and sessions remain open with > > > Netfilter's conntrack facilities, the NAT problem is minimized. > > > > Yes, we are thinking about this idea of conntrack to avoid the > > "manual" close knock, but remember that someone could cause a DoS, > > spoofing your IP and just trying to establish a connection before you. > > I'm not sure I understand. It seems like this would be an issue only if > you allow just one follow-on connection per SPA packet, yes? Fwknop > uses a timeout window, so it doesn't matter how many connections are > established as long as it is within the window. > ok, in our case, if you do not do the "close" knock, you also have a timeout window configurable as a the kernel module param. seems that fwknop is an interesting app, but we are looking for a more kernel oriented feedback. ;-) regards, -- Federico From pablo at netfilter.org Wed Oct 18 16:46:36 2006 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Wed Oct 18 17:17:32 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: <4534309F.8000200@netfilter.org> <1161093912.20036.3.camel@localhost.localdomain> Message-ID: <45363E4C.4030201@netfilter.org> J. Federico Hernandez wrote: > On 10/17/06, Eric Leblond wrote: >> Le mardi 17 octobre 2006 ? 09:19 -0300, J. Federico Hernandez a ?crit : >> > On 10/16/06, Pablo Neira Ayuso wrote: >> > > J. Federico Hernandez wrote: >> > > >> On Oct 14, 2006, Michael Rash wrote: >> > > >> >> > > >> Well, I agree that having an implementation that builds some port >> > > >> knocking capabilities directly into iptables is a good thing >> for the >> > > >> > > Perhaps I'm just influenced by my first impression but I think >> that this >> > > thing should be in userspace. We are providing the appropiate >> netfilter >> > > netlink subsystems (nfqueue, nflog...) to implement this as a >> userland >> > > daemon. >> > > >> > >> > When all you want is to open a port after a correct sequence of >> > knocks, instead of sending from the kernel all the knocks to the >> > userspace, and then setting a new iptables rule so the kernel firewall >> > takes an action, it would be better to leave the whole work to the >> > kernel and avoid the transition kernel->userspace->kernel. >> >> kernel->userspace->kernel is really not a problem for nowadays computer. >> Simply think about snort-inline which is able to handle a great amount >> of traffic. > > the fact that nowadays computers have much more power, doesn't mean > that you can forget about a simple, less complex and correct design. I'm unsure that putting things in kernel implies less complexity and correct design, it depends on the case. > By the way, Linux runs in a wide spectrum of devices, like mobile > devices, where you musn't waste resources. (see linksys ap wireless, > smart phones, etc) I think that the main question is how many packets you would need to pass to userspace. -- 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 Thu Oct 19 08:06:44 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Thu Oct 19 08:45:06 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610130050.k9D0oj3O013113@toshiba.co.jp> <452A7286.3080403@trash.net> References: <200610120811.k9C8B4Pg002384@toshiba.co.jp> <200610121729.36069@auguste.remlab.net> <200610130050.k9D0oj3O013113@toshiba.co.jp> Message-ID: <200610190606.k9J66ksI028653@toshiba.co.jp> Hi, Patrick, I've found the following your mail and would I be better to commit this until next version of iptables ? From: Patrick McHardy Date: Mon, 09 Oct 2006 18:02:14 +0200 > We should consider moving away from using the kernel headers directly. > Breaking compilation of old iptables versions is not too bad IMO, > old binaries will still work and someone compiling old iptables with > a new kernel can just as well just compile a new version. > > Unfortunately 1.3.6 won't compile with 2.6.19, so we might have to put > out a new version soon. From: Yasuyuki KOZAKAI Date: Fri, 13 Oct 2006 09:50:44 +0900 (JST) > > Hello, > > > Le jeudi 12 octobre 2006 11:11, Yasuyuki KOZAKAI a ?crit : > > > ??? Did you send intended patch ? It includes XT_MULTI_PORTS as > > > folows. > > > > Hmm, probably resent the old one accidentally then. > > > > Sending the correct patch as attachment to avoid further breakages. > > Thanks, > > OK, I've update your patch (please see below comments in detail), and also > tested with kernel 2.4.33.3 and 2.6 linus tree and ip6tables build with > headers in each of them. > > If no objection, I'll commit the attached patch next week. > > I appreciate if you tries to build with 2.4 kernel for such changes > from next time. > > > From: R?mi Denis-Courmont > Date: Thu, 12 Oct 2006 17:29:35 +0300 > > > Index: iptables/include/ip6tables.h > > =================================================================== > > --- iptables/include/ip6tables.h (r??vision 6687) > > +++ iptables/include/ip6tables.h (copie de travail) > > @@ -33,6 +33,9 @@ > > > > ip6t_chainlabel name; > > > > + /* Revision of match (0 by default). */ > > + u_int8_t revision; > > + > > const char *version; > > The declaration for ip6t_get_revision is missing. That doesn't exist > in 2.4 kernel. > > > Index: iptables/ip6tables.c > > =================================================================== > > --- iptables/ip6tables.c (r??vision 6687) > > +++ iptables/ip6tables.c (copie de travail) > > @@ -193,6 +193,8 @@ > > const char *program_name; > > char *lib_dir; > > > > +int kernel_version; > > This isn't used anywhere. > > Regards, > From kaber at trash.net Thu Oct 19 16:53:29 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 19 17:32:09 2006 Subject: [tproxy] Re: Request: including tproxy patch to official iptables/kernel. In-Reply-To: <20061017150147.GD1598@xi.wantstofly.org> References: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> <45331D32.5070209@trash.net> <200610171638.25425@nienna> <20061017150147.GD1598@xi.wantstofly.org> Message-ID: <45379169.4030504@trash.net> Lennert Buytenhek wrote: > On Tue, Oct 17, 2006 at 04:38:24PM +0200, KOVACS Krisztian wrote: > > >> Moreover, I think there's no general consensus between networking >>maintainers whether or not the features tproxy provides are worth the >>hassles. Transparent proxying features have been removed during the 2.3 >>development as there seemed little interest in those. Of course there are >>a handful of companies interested in having the feature in mainline, but >>let's face the facts: the majority of users do not care about tproxy. > > > There's other features and drivers in Linux where a similar thing > applies. If tproxy doesn't get into the way when it's not used or > turned off, why shouldn't it be merged? Thats exactly what I was going to say :) From kaber at trash.net Thu Oct 19 16:58:23 2006 From: kaber at trash.net (Patrick McHardy) Date: Thu Oct 19 17:36:45 2006 Subject: Request: including tproxy patch to official iptables/kernel. In-Reply-To: <200610171638.25425@nienna> References: <20061016114331.AF36.TSUNEO.YOSHIOKA@f-secure.com> <45331D32.5070209@trash.net> <200610171638.25425@nienna> Message-ID: <4537928F.1060900@trash.net> KOVACS Krisztian wrote: > Yes, there was significant progress since then, we're testing the > patches at the moment. There still are a couple of problems with the new > approach, but it certainly looks promising. I'll post the patches on > netfilter-devel for review and comments as soon as things have settled > down a bit. Great. > Instead of trying to get the 2.0 branch of tproxy merged into mainline > we're concentrating our efforts on getting the new code working. As the > maintainer of the current tproxy patchset, I do not consider it clean and > safe enough to have it merged upstream. Yes, the old patches are a bit risky I think. But the new approach (in case its still the same) looked like a nice way. > Moreover, I think there's no general consensus between networking > maintainers whether or not the features tproxy provides are worth the > hassles. Transparent proxying features have been removed during the 2.3 > development as there seemed little interest in those. Of course there are > a handful of companies interested in having the feature in mainline, but > let's face the facts: the majority of users do not care about tproxy. > That's why I don't even try to get it merged. I have no problem with that if it doesn't affect users not using it. From oan at frozentux.net Thu Oct 19 18:20:19 2006 From: oan at frozentux.net (Oskar Andreasson) Date: Thu Oct 19 18:58:32 2006 Subject: [rfc][update]iptables-tutorial 1.2.2 Message-ID: <1161274820.22792.91.camel@LAPTOP4.MSHOME> Hi All, Thought I'd make a small update on the iptables-tutorial since it's now been longer than I originally anticipated for this release. I'm still waiting for the first copy of the book to arrive, hence the delay. I still have a few things to add to get up to 2.6.18 standards, but I got (hopefully) 1-2 weeks before my personal deadline for the project. Would anyone care to give any suggestions on things that are either more important than the ones in the listed TODO, or that you believe should be included? Also, the book will be 'perfect bound' hard-cover, 9x6", and right now is closing in on 400 pages, and that's where I hope it will stop for now :-). The page count can go up/down pending any layout changes however. It will run at 33-35 USD + shipping per copy. Sidenote, the current french translation seems to be done directly from the chunky html source, as noted in the TODO. Would anyone be willing to make a change of this? Also, basically all the translations needs to be updated if anyone feels inclined... The current changelog looks as follows: 1.2.2 * Added SCTP match. * Added addrtype match. * Added link to policy routing using linux by Matthew G. Marsh. * Added some internal links for better cross linking. * Added comment match. * Added hashlimit match. * Added new --cmd-owner to owner match. * Added realm match. * Added important.gif image sign. * Fixed --limit-burst, bad explanation. * Fixed s/package/packet/ in MARK target. ("G.W. Haywood" ) * Added raw table in traversing_of_tables_and_chains.sgml * Updated tables_traverse.gif with raw table and switched fonts. * Added UNTRACKED and new untracked connections section in statemachine.sgml. * Removed internal catalogs etc, living off of local ones instead. * Added SCTP characteristics section to tcp_ip_repetition.sgml * Added all images for the SCTP chapters. * Remade all header images from the tcp_ip_repetition.sgml chapter. * Added SCTP headers section in the tcp_ip_repetition.sgml chapter. My TODO for the tutorial looks like this: * nf-log?? * Add all new targets in 2.6 kernel and iptables-1.3.6. -- CLUSTERIP -- CONNMARK -- CONNSECMARK? -- SECMARK? -- NOTRACK -- NFQUEUE? * Remake flow images (Basically all images except header images). * Add section about VPN and iptables (ie, private incoming traffic to netfilter box with public iface and vpn iface on top). including routing. nat'ed ipsec, openvpn. filtering ipsec, openvpn. * French translation needs to be done in DocBook SGML, please? Should fix problem with wrong charset encoding. * Improve explanation of chain traversal. Add explanation of user defined chains. * Create index. -- -- Oskar Andreasson http://www.frozentux.net mail/sip: oan@frozentux.net icq: 33147668 msn: allostra@hotmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20061019/4c88793c/attachment.pgp From kslee109 at gmail.com Fri Oct 20 08:18:37 2006 From: kslee109 at gmail.com (=?utf-8?B?7J206re87IiY?=) Date: Fri Oct 20 08:59:16 2006 Subject: How many rules were supported iptables? Message-ID: <003b01c6f40f$9700b2d0$1319939c@LGE.NET> Hi All. I have a problem that is how many rules were supported iptables. The program which I maintain and repair generated iptables rules automatically. Now, I encounter this problem. Source and destination IP address is written range by user.( ex, 1.1.1.1~1.1.1.10 ) then our program generated 10 IP address(1.1.1.1, 1.1.1.2, 1.1.1.3, ? , 1.1.1.10) and make 10 iptables rules. Unfortunately, user wrote iptables rules like this, 10,000 rules is generated. ?? iptalbes ?A FORWARD ?p tcp ?s 1.1.1.1~1.1.1.100 ?d 2.2.2.1~2.2.2.100 ?j QUEUE?. Do 10,000 rules operate safely?? Or Some rules don?t operate normally?? If some rules don?t operate normally, how many rules iptables does support?? From kslee109 at gmail.com Fri Oct 20 08:28:27 2006 From: kslee109 at gmail.com (=?utf-8?B?7J206re87IiY?=) Date: Fri Oct 20 09:08:59 2006 Subject: How many rules were supported iptables? Message-ID: <003e01c6f410$f70baf30$1319939c@LGE.NET> Hi All. I have a problem that is how many rules were supported iptables. The program which I maintain and repair generated iptables rules automatically. Now, I encounter this problem. Source and destination IP address is written range by user.( ex, 1.1.1.1~1.1.1.10 ) then our program generated 10 IP address(1.1.1.1, 1.1.1.2, 1.1.1.3, ? , 1.1.1.10) and make 10 iptables rules. Unfortunately, user wrote iptables rules like this, 10,000 rules is generated. ?? iptalbes ?A FORWARD ?p tcp ?s 1.1.1.1~1.1.1.100 ?d 2.2.2.1~2.2.2.100 ?j QUEUE?. Do 10,000 rules operate safely?? Or Some rules don?t operate normally?? If some rules don?t operate normally, how many rules iptables does support?? From pme at ufh.se Fri Oct 20 08:43:33 2006 From: pme at ufh.se (Peter) Date: Fri Oct 20 09:22:09 2006 Subject: How many rules were supported iptables? In-Reply-To: <003e01c6f410$f70baf30$1319939c@LGE.NET> References: <003e01c6f410$f70baf30$1319939c@LGE.NET> Message-ID: <45387015.40305@ufh.se> ??? wrote: >Hi All. >I have a problem that is how many rules were supported iptables. >The program which I maintain and repair generated iptables rules automatically. >Now, I encounter this problem. >Source and destination IP address is written range by user.( ex, 1.1.1.1~1.1.1.10 ) then our program generated 10 IP address(1.1.1.1, 1.1.1.2, 1.1.1.3, ? , 1.1.1.10) and make 10 iptables rules. >Unfortunately, user wrote iptables rules like this, 10,000 rules is generated. >?? iptalbes ?A FORWARD ?p tcp ?s 1.1.1.1~1.1.1.100 ?d 2.2.2.1~2.2.2.100 ?j QUEUE?. >Do 10,000 rules operate safely?? Or Some rules don?t operate normally?? >If some rules don?t operate normally, how many rules iptables does support?? > > > > It's the 4 MB in total size of rules. (This is the maximum size of a chunc of data copy from userspace to kernel space in one syscall) From dada1 at cosmosbay.com Fri Oct 20 09:06:42 2006 From: dada1 at cosmosbay.com (Eric Dumazet) Date: Fri Oct 20 09:45:00 2006 Subject: How many rules were supported iptables? In-Reply-To: <45387015.40305@ufh.se> References: <003e01c6f410$f70baf30$1319939c@LGE.NET> <45387015.40305@ufh.se> Message-ID: <45387582.5050901@cosmosbay.com> Peter a ?crit : > ??? wrote: > >> Hi All. >> I have a problem that is how many rules were supported iptables. >> The program which I maintain and repair generated iptables rules >> automatically. >> Now, I encounter this problem. >> Source and destination IP address is written range by user.( ex, >> 1.1.1.1~1.1.1.10 ) then our program generated 10 IP address(1.1.1.1, >> 1.1.1.2, 1.1.1.3, ? , 1.1.1.10) and make 10 iptables rules. >> Unfortunately, user wrote iptables rules like this, 10,000 rules is >> generated. >> ?? iptalbes ?A FORWARD ?p tcp ?s 1.1.1.1~1.1.1.100 ?d >> 2.2.2.1~2.2.2.100 ?j QUEUE?. >> Do 10,000 rules operate safely?? Or Some rules don?t operate normally?? >> If some rules don?t operate normally, how many rules iptables does >> support?? >> >> >> >> > It's the 4 MB in total size of rules. (This is the maximum size of a > chunc of data copy from userspace to kernel space in > one syscall) Hi Peter I was not aware on this 4MB limit. Could you please tell us where this limit is applied in kernel sources ? Thank you From m.innocenti at cineca.it Fri Oct 20 09:13:52 2006 From: m.innocenti at cineca.it (m.innocenti@cineca.it) Date: Fri Oct 20 09:52:09 2006 Subject: How many rules were supported iptables? In-Reply-To: <003e01c6f410$f70baf30$1319939c@LGE.NET> References: <003e01c6f410$f70baf30$1319939c@LGE.NET> Message-ID: <45387731.1020201@cineca.it> ??? ha scritto: > Hi All. > I have a problem that is how many rules were supported iptables. > The program which I maintain and repair generated iptables rules automatically. > Now, I encounter this problem. > Source and destination IP address is written range by user.( ex, 1.1.1.1~1.1.1.10 ) then our program generated 10 IP address(1.1.1.1, 1.1.1.2, 1.1.1.3, ? , 1.1.1.10) and make 10 iptables rules. > Unfortunately, user wrote iptables rules like this, 10,000 rules is generated. > ?? iptalbes ?A FORWARD ?p tcp ?s 1.1.1.1~1.1.1.100 ?d 2.2.2.1~2.2.2.100 ?j QUEUE?. I think you should use the module iprange or ipset. > Do 10,000 rules operate safely?? Or Some rules don?t operate normally?? 10000 rules in one chain have a great impact on performance (http://people.netfilter.org/kadlec/nftest.pdf). -- ********************************************************************** Marco Innocenti Gruppo Infrastruttura e Sicurezza CINECA phone:+39 0516171553 / fax:+39 0516132198 Via Magnanelli 6/3 e-mail: innocenti@cineca.it 40033 Casalecchio di Reno Bologna (Italia) ********************************************************************** From kaber at trash.net Fri Oct 20 12:06:49 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Oct 20 12:45:06 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <200610190606.k9J66kRd002796@toshiba.co.jp> References: <200610120811.k9C8B4Pg002384@toshiba.co.jp> <200610121729.36069@auguste.remlab.net> <200610130050.k9D0oj3O013113@toshiba.co.jp> <200610190606.k9J66kRd002796@toshiba.co.jp> Message-ID: <45389FB9.8020901@trash.net> Yasuyuki KOZAKAI wrote: > Hi, Patrick, > > I've found the following your mail and would I be better to commit this > until next version of iptables ? The patch looks fine, I guess we can add it since we still have a few weeks until we should release a new version. From kaber at trash.net Fri Oct 20 12:03:58 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Oct 20 13:05:10 2006 Subject: queue_maxlen In-Reply-To: <1161125685.4002.33.camel@localhost.localdomain> References: <2BDDB86A-ABD4-4C53-AE17-498AB0F52B28@cadvium.net> <1161125685.4002.33.camel@localhost.localdomain> Message-ID: <45389F0E.6000000@trash.net> Eric Leblond wrote: > Hi, > > Le mardi 17 octobre 2006 ? 15:43 -0700, robert a ?crit : > >>Does NFQUEUE use the value in /proc/sys/net/ip_queue_maxlen? If not, >>is it possible to modify the maximum queue length for NFQUEUE? > > > Not with vanilla tree. > > I've post a patch to enable it some times ago but It has not been > incorporated into main tree : > > http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3628 > http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3629 > > With that patch it is possible to do so on a per-queue basis by using > the new function nfq_set_queue_maxlen. Please resend, I probably missed it. From kaber at trash.net Fri Oct 20 12:02:50 2006 From: kaber at trash.net (Patrick McHardy) Date: Fri Oct 20 13:05:11 2006 Subject: nfqueue/ipq difference In-Reply-To: <1318F807-9466-4960-9ABE-1350E9B81E6C@cadvium.net> References: <1318F807-9466-4960-9ABE-1350E9B81E6C@cadvium.net> Message-ID: <45389ECA.4010504@trash.net> robert wrote: > As I was migrating to NFQUEUE, I noticed a small difference. If you > are polling on an IPQ filedescriptor, then the error bit is set if the > queue runs out of buffer space. In NFQUEUE, the error bit is never > set, but after doing a read, there is an error. This error bit is > relatively important and in most applications would want to handle a > read since both IPQ and NFQUEUE will not queue any new packets until > the entire buffer is flushed. (at least, this is the behavior that I > am seeing). > > If anyone is interested, i could post two small test programs that > illustrate this behavior. (not sure if this would be considered a bug). Please, I can not see any difference between ipq and nfnetlink_queue. From yasuyuki.kozakai at toshiba.co.jp Fri Oct 20 13:48:13 2006 From: yasuyuki.kozakai at toshiba.co.jp (Yasuyuki KOZAKAI) Date: Fri Oct 20 14:26:47 2006 Subject: [PATCH] iptables: ip6table version support and libip6t_multiport.fix In-Reply-To: <45389FB9.8020901@trash.net> References: <200610130050.k9D0oj3O013113@toshiba.co.jp> <200610190606.k9J66kRd002796@toshiba.co.jp> <45389FB9.8020901@trash.net> Message-ID: <200610201148.k9KBmFIu022043@toshiba.co.jp> From: Patrick McHardy Date: Fri, 20 Oct 2006 12:06:49 +0200 > Yasuyuki KOZAKAI wrote: > > Hi, Patrick, > > > > I've found the following your mail and would I be better to commit this > > until next version of iptables ? > > The patch looks fine, I guess we can add it since we still have a few > weeks until we should release a new version. OK, I've commited it. Thanks. -- Yasuyuki Kozakai From eric at inl.fr Fri Oct 20 18:40:21 2006 From: eric at inl.fr (Eric Leblond) Date: Fri Oct 20 19:18:53 2006 Subject: [Patch 1/2] queue_maxlen In-Reply-To: <45389F0E.6000000@trash.net> References: <2BDDB86A-ABD4-4C53-AE17-498AB0F52B28@cadvium.net> <1161125685.4002.33.camel@localhost.localdomain> <45389F0E.6000000@trash.net> Message-ID: <1161362421.7529.1.camel@localhost.localdomain> Hi, Here's the kernel patch for queue_maxlen settings. BR, Le vendredi 20 octobre 2006 ? 12:03 +0200, Patrick McHardy a ?crit : > Eric Leblond wrote: > > Hi, > > > > Le mardi 17 octobre 2006 ? 15:43 -0700, robert a ?crit : > > > >>Does NFQUEUE use the value in /proc/sys/net/ip_queue_maxlen? If not, > >>is it possible to modify the maximum queue length for NFQUEUE? > > > > > > Not with vanilla tree. > > > > I've post a patch to enable it some times ago but It has not been > > incorporated into main tree : > > > > http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3628 > > http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3629 > > > > With that patch it is possible to do so on a per-queue basis by using > > the new function nfq_set_queue_maxlen. > > Please resend, I probably missed it. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: specify-queue-max-length-from-userspace.patch Type: text/x-vhdl Size: 1187 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061020/99b8cf88/specify-queue-max-length-from-userspace.bin From eric at inl.fr Fri Oct 20 18:41:35 2006 From: eric at inl.fr (Eric Leblond) Date: Fri Oct 20 19:19:57 2006 Subject: [Patch 2/2] queue_maxlen In-Reply-To: <45389F0E.6000000@trash.net> References: <2BDDB86A-ABD4-4C53-AE17-498AB0F52B28@cadvium.net> <1161125685.4002.33.camel@localhost.localdomain> <45389F0E.6000000@trash.net> Message-ID: <1161362495.7529.4.camel@localhost.localdomain> Hi, Here's the userspace patch against libnetfilter_queue. BR, Le vendredi 20 octobre 2006 ? 12:03 +0200, Patrick McHardy a ?crit : > Eric Leblond wrote: > > Hi, > > > > Le mardi 17 octobre 2006 ? 15:43 -0700, robert a ?crit : > > > >>Does NFQUEUE use the value in /proc/sys/net/ip_queue_maxlen? If not, > >>is it possible to modify the maximum queue length for NFQUEUE? > > > > > > Not with vanilla tree. > > > > I've post a patch to enable it some times ago but It has not been > > incorporated into main tree : > > > > http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3628 > > http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3629 > > > > With that patch it is possible to do so on a per-queue basis by using > > the new function nfq_set_queue_maxlen. > > Please resend, I probably missed it. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: libnetfilter_queue-specify-queue-max-length-from-userspace.patch Type: text/x-vhdl Size: 2633 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061020/6d663329/libnetfilter_queue-specify-queue-max-length-from-userspace.bin From wangbj at lzu.edu.cn Mon Oct 23 08:52:07 2006 From: wangbj at lzu.edu.cn (Wang, Baojun) Date: Mon Oct 23 09:31:08 2006 Subject: rtsp-conntrack compile failed on 2.6.16 kernel Message-ID: <361646925.14969@eyou.net> hi, list: I have met some problems with rtsp-conntrack patch, kernel version is 2.6.16, patch with the svn version of patch-o-matic(./runme exra) and iptables, both revision are 6688. any ideas? thanks very much! scripts/Makefile.build:51: kbuild: net/ipv4/netfilter/Makefile - Usage of export-objs is obsolete in 2.6. Please fix! CC [M] net/ipv4/netfilter/ip_nat_rtsp.o net/ipv4/netfilter/ip_nat_rtsp.c: In function `rtsp_mangle_tran': net/ipv4/netfilter/ip_nat_rtsp.c:167: warning: implicit declaration of function `ip_conntrack_change_expect' net/ipv4/netfilter/ip_nat_rtsp.c: In function `expected': net/ipv4/netfilter/ip_nat_rtsp.c:368: error: storage size of `mr' isn't known net/ipv4/netfilter/ip_nat_rtsp.c:376: error: structure has no member named `initialized' net/ipv4/netfilter/ip_nat_rtsp.c:368: warning: unused variable `mr' net/ipv4/netfilter/ip_nat_rtsp.c: In function `help_out': net/ipv4/netfilter/ip_nat_rtsp.c:411: error: structure has no member named `seq' net/ipv4/netfilter/ip_nat_rtsp.c:431: error: `ct' undeclared (first use in this function) net/ipv4/netfilter/ip_nat_rtsp.c:431: error: (Each undeclared identifier is reported only once net/ipv4/netfilter/ip_nat_rtsp.c:431: error: for each function it appears in.) net/ipv4/netfilter/ip_nat_rtsp.c:431: error: incompatible type for argument 2 of `rtsp_mangle_tran' net/ipv4/netfilter/ip_nat_rtsp.c:431: warning: passing arg 3 of `rtsp_mangle_tran' from incompatible pointer type net/ipv4/netfilter/ip_nat_rtsp.c:431: warning: passing arg 4 of `rtsp_mangle_tran' from incompatible pointer type net/ipv4/netfilter/ip_nat_rtsp.c:431: warning: passing arg 5 of `rtsp_mangle_tran' makes integer from pointer without a cast net/ipv4/netfilter/ip_nat_rtsp.c:431: error: too many arguments to function `rtsp_mangle_tran' net/ipv4/netfilter/ip_nat_rtsp.c: At top level: net/ipv4/netfilter/ip_nat_rtsp.c:450: error: parameter `ct_rtsp_info' has just a forward declaration net/ipv4/netfilter/ip_nat_rtsp.c:449: error: parameter `ctinfo' has just a forward declaration net/ipv4/netfilter/ip_nat_rtsp.c:448: error: parameter `pskb' has just a forward declaration net/ipv4/netfilter/ip_nat_rtsp.c: In function `help': net/ipv4/netfilter/ip_nat_rtsp.c:462: error: too many arguments to function `help_out' net/ipv4/netfilter/ip_nat_rtsp.c:454: warning: unused variable `tcph' net/ipv4/netfilter/ip_nat_rtsp.c:455: warning: unused variable `datalen' net/ipv4/netfilter/ip_nat_rtsp.c: In function `fini': net/ipv4/netfilter/ip_nat_rtsp.c:475: error: `ip_nat_rtsp_hook' undeclared (first use in this function) net/ipv4/netfilter/ip_nat_rtsp.c: In function `init': net/ipv4/netfilter/ip_nat_rtsp.c:483: error: `ip_nat_rtsp_hook' undeclared (first use in this function) net/ipv4/netfilter/ip_nat_rtsp.c: At top level: net/ipv4/netfilter/ip_nat_rtsp.c:65: warning: `ports' defined but not used net/ipv4/netfilter/ip_nat_rtsp.c:69: warning: `num_ports' defined but not used net/ipv4/netfilter/ip_nat_rtsp.c:367: warning: `expected' defined but not used make[3]: *** [net/ipv4/netfilter/ip_nat_rtsp.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 -- Wang, Baojun Lanzhou University Distributed & Embedded System Lab http://dslab.lzu.edu.cn School of Information Science and Engeneering wangbj@lzu.edu.cn Tianshui South Road 222. Lanzhou 730000 .P.R.China Tel:+86-931-8912025 Fax:+86-931-8912022 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20061023/49114fd8/attachment-0001.pgp From kaber at trash.net Mon Oct 23 13:23:58 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 23 14:02:38 2006 Subject: rtsp-conntrack compile failed on 2.6.16 kernel In-Reply-To: <361646925.14969@eyou.net> References: <361646925.14969@eyou.net> Message-ID: <453CA64E.9010102@trash.net> Wang, Baojun wrote: > hi, list: > > I have met some problems with rtsp-conntrack patch, kernel version is > 2.6.16, patch with the svn version of patch-o-matic(./runme exra) and > iptables, both revision are 6688. any ideas? thanks very much! > > scripts/Makefile.build:51: kbuild: net/ipv4/netfilter/Makefile - Usage > of export-objs is obsolete in 2.6. Please fix! Looks like you somehow managed to apply the 2.4 version of the patch. Most likely the 2.6 version won't work either, but it should be easier to fix. From fede.hernandez at gmail.com Mon Oct 23 15:31:14 2006 From: fede.hernandez at gmail.com (J. Federico Hernandez) Date: Mon Oct 23 16:09:56 2006 Subject: new match extension to implement port knocking in one In-Reply-To: <45363E4C.4030201@netfilter.org> References: <4534309F.8000200@netfilter.org> <1161093912.20036.3.camel@localhost.localdomain> <45363E4C.4030201@netfilter.org> Message-ID: On 10/18/06, Pablo Neira Ayuso wrote: > J. Federico Hernandez wrote: > > On 10/17/06, Eric Leblond wrote: > >> Le mardi 17 octobre 2006 ? 09:19 -0300, J. Federico Hernandez a ?crit : > >> > On 10/16/06, Pablo Neira Ayuso wrote: > >> > > J. Federico Hernandez wrote: > >> > > >> On Oct 14, 2006, Michael Rash wrote: > >> > > >> > >> > > >> Well, I agree that having an implementation that builds some port > >> > > >> knocking capabilities directly into iptables is a good thing > >> for the > >> > > > >> > > Perhaps I'm just influenced by my first impression but I think > >> that this > >> > > thing should be in userspace. We are providing the appropiate > >> netfilter > >> > > netlink subsystems (nfqueue, nflog...) to implement this as a > >> userland > >> > > daemon. > >> > > > >> > > >> > When all you want is to open a port after a correct sequence of > >> > knocks, instead of sending from the kernel all the knocks to the > >> > userspace, and then setting a new iptables rule so the kernel firewall > >> > takes an action, it would be better to leave the whole work to the > >> > kernel and avoid the transition kernel->userspace->kernel. > >> > >> kernel->userspace->kernel is really not a problem for nowadays computer. > >> Simply think about snort-inline which is able to handle a great amount > >> of traffic. > > > > the fact that nowadays computers have much more power, doesn't mean > > that you can forget about a simple, less complex and correct design. > > I'm unsure that putting things in kernel implies less complexity and > correct design, it depends on the case. > Putting things in kernel doesn't mean less complexity, but on port knocking case means a correct design and better performance. WIth traditional port knocking applications you have to switch kernelspace ->userspase->kernelspace several times. Furthermore, you have to load the regex engine for parsing the firewall logs and you have to access the hard disk each minute for parsing logs files. In our opinion, this is not a correct design. We don't want to say that you don't use port knocking applications, we just offer an alternative solution for port knocking. Regards, -- Federico From mael.boutin at laposte.net Mon Oct 23 17:22:01 2006 From: mael.boutin at laposte.net (mael.boutin) Date: Mon Oct 23 18:00:42 2006 Subject: Problem using connection tracking Message-ID: Hi, First excuse me for my poor english ... I'm having problems using conntrack. Everything was ok while i was using the old ip_conntrack. However, now i need to use it with IPv6. The problem i'm facing is with the new connection tracking system, i can't receive any conntrack events neither IPv4 nor IPv6. Moreover, the conntrack application is not working : - conntrack -L returns invalid parameters - conntrack -E dumps nothing I think it is a problem related with the configuration of the kernel (attached). I'm using a 2.6.15.6 Linux Kernel and i can't go to a newer kernel. libnetfilter_conntrack-0.0.31 libnfnetlink-0.0.16 Thanks in advance for your help Regards, Ma?l ----------------- Acc?dez au courrier ?lectronique de La Poste sur www.laposte.net ou sur 3615 LAPOSTENET (0,34? TTC /mn) 1 Giga de stockage gratuit ? Antispam et antivirus int?gr?s -------------- next part -------------- A non-text attachment was scrubbed... Name: =?iso-8859-1?Q?config?= Type: application/octet-stream Size: 43619 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061023/6524d033/iso-8859-1Qconfig-0001.obj From kaber at trash.net Mon Oct 23 18:25:16 2006 From: kaber at trash.net (Patrick McHardy) Date: Mon Oct 23 19:03:55 2006 Subject: Problem using connection tracking In-Reply-To: References: Message-ID: <453CECEC.3090807@trash.net> mael.boutin wrote: > Hi, > > First excuse me for my poor english ... > > I'm having problems using conntrack. Everything was ok while i > was using the old ip_conntrack. However, now i need to use it > with IPv6. > > The problem i'm facing is with the new connection tracking > system, i can't receive any conntrack events neither IPv4 nor > IPv6. > > Moreover, the conntrack application is not working : > - conntrack -L returns invalid parameters > - conntrack -E dumps nothing > > I think it is a problem related with the configuration of the > kernel (attached). > > I'm using a 2.6.15.6 Linux Kernel and i can't go to a newer > kernel. ctnetlink support for nf_conntrack was added in 2.6.16. From eric at inl.fr Mon Oct 23 21:46:52 2006 From: eric at inl.fr (Eric Leblond) Date: Mon Oct 23 22:25:41 2006 Subject: new match extension to implement port knocking in one In-Reply-To: References: <4534309F.8000200@netfilter.org> <1161093912.20036.3.camel@localhost.localdomain> <45363E4C.4030201@netfilter.org> Message-ID: <1161632812.5359.8.camel@localhost> Le lundi 23 octobre 2006 ? 10:31 -0300, J. Federico Hernandez a ?crit : > On 10/18/06, Pablo Neira Ayuso wrote: > > J. Federico Hernandez wrote: > > > On 10/17/06, Eric Leblond wrote: > > >> > > > >> > When all you want is to open a port after a correct sequence of > > >> > knocks, instead of sending from the kernel all the knocks to the > > >> > userspace, and then setting a new iptables rule so the kernel firewall > > >> > takes an action, it would be better to leave the whole work to the > > >> > kernel and avoid the transition kernel->userspace->kernel. > > >> > > >> kernel->userspace->kernel is really not a problem for nowadays computer. > > >> Simply think about snort-inline which is able to handle a great amount > > >> of traffic. > > > > > > the fact that nowadays computers have much more power, doesn't mean > > > that you can forget about a simple, less complex and correct design. > > > > I'm unsure that putting things in kernel implies less complexity and > > correct design, it depends on the case. > > > > Putting things in kernel doesn't mean less complexity, but on port > knocking case means a correct design and better performance. > > WIth traditional port knocking applications you have to switch > kernelspace ->userspase->kernelspace several times. Furthermore, you > have to load the regex engine for parsing the firewall logs and you > have to access the hard disk each minute for parsing logs files. In > our opinion, this is not a correct design. We do not understand each other about the way I (and pablo I think) propose you to do because the solution I thought off do not use log analysis... Let's say port knocking is 4138 2345 4577 to open port 22 Then just do iptables -A INPUT -p tcp -m multiport --dports 4138,2345,4577,22 -j QUEUE Your userspace application wait for packets coming from queue, drop them when they come from knocking ports (but store the knock) and accept packet to port 22 if we just had a correct knocking sequence before. This is simple, do not use complex algorithms and should fit on all small routers. BR, -- Eric Leblond INL -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : /pipermail/netfilter-devel/attachments/20061023/74e87ace/attachment.pgp From oan at frozentux.net Tue Oct 24 01:03:45 2006 From: oan at frozentux.net (Oskar Andreasson) Date: Tue Oct 24 01:42:16 2006 Subject: --dport in uml crash Message-ID: <1161644625.8705.16.camel@LAPTOP4.MSHOME> Using UML kernel 2.6.18 and iptables-1.3.6. Specifying iptables -A INPUT -p tcp --dport 23 -j ACCEPT generates a hard crash of the UML system. -j ACCEPT on it's own works flawless and -p tcp also works flawless, so i assume it's the --dport causing the crash for some reason. I've been unable to get a look at the error messages since the xterm closes down before I get a chance to read it (lots of something scrolls by before closing however), any suggestions on how to get the errors are welcome, or if anyone else can replicate them would also be welcome :). Let me know if there is any more information that might be needed, or if this is an UML related bug? -- -- Oskar Andreasson http://www.frozentux.net mail/sip: oan@frozentux.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20061024/6a9d8286/attachment.pgp From oan at frozentux.net Tue Oct 24 01:09:53 2006 From: oan at frozentux.net (Oskar Andreasson) Date: Tue Oct 24 01:48:15 2006 Subject: --dport in uml crash In-Reply-To: <1161644625.8705.16.camel@LAPTOP4.MSHOME> References: <1161644625.8705.16.camel@LAPTOP4.MSHOME> Message-ID: <1161644993.8705.18.camel@LAPTOP4.MSHOME> Strike that, error on my part, ran the binary against the wrong libc version. On Tue, 2006-10-24 at 01:03 +0200, Oskar Andreasson wrote: > Using UML kernel 2.6.18 and iptables-1.3.6. > Specifying iptables -A INPUT -p tcp --dport 23 -j ACCEPT generates a > hard crash of the UML system. > -j ACCEPT on it's own works flawless and -p tcp also works flawless, so > i assume it's the --dport causing the crash for some reason. > > I've been unable to get a look at the error messages since the xterm > closes down before I get a chance to read it (lots of something scrolls > by before closing however), any suggestions on how to get the errors are > welcome, or if anyone else can replicate them would also be welcome :). > > Let me know if there is any more information that might be needed, or if > this is an UML related bug? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20061024/475f887e/attachment.pgp From kaber at trash.net Tue Oct 24 00:39:21 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 24 01:48:56 2006 Subject: [Patch 1/2] queue_maxlen In-Reply-To: <1161362421.7529.1.camel@localhost.localdomain> References: <2BDDB86A-ABD4-4C53-AE17-498AB0F52B28@cadvium.net> <1161125685.4002.33.camel@localhost.localdomain> <45389F0E.6000000@trash.net> <1161362421.7529.1.camel@localhost.localdomain> Message-ID: <453D4499.3000900@trash.net> Eric Leblond wrote: > Here's the kernel patch for queue_maxlen settings. This looks fine, but the merge window for 2.6.19 is closed. I'm going to queue this in my inbox for 2.6.20 until Dave opens his net-2.6.20 tree, but I might ask for a resend if it stops applying for some reason. From kaber at trash.net Tue Oct 24 01:17:00 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 24 01:55:39 2006 Subject: --dport in uml crash In-Reply-To: <1161644625.8705.16.camel@LAPTOP4.MSHOME> References: <1161644625.8705.16.camel@LAPTOP4.MSHOME> Message-ID: <453D4D6C.5050508@trash.net> Oskar Andreasson wrote: > Using UML kernel 2.6.18 and iptables-1.3.6. > Specifying iptables -A INPUT -p tcp --dport 23 -j ACCEPT generates a > hard crash of the UML system. > -j ACCEPT on it's own works flawless and -p tcp also works flawless, so > i assume it's the --dport causing the crash for some reason. It is reproducable? > I've been unable to get a look at the error messages since the xterm > closes down before I get a chance to read it (lots of something scrolls > by before closing however), any suggestions on how to get the errors are > welcome, or if anyone else can replicate them would also be welcome :). > > Let me know if there is any more information that might be needed, or if > this is an UML related bug? Based on my experience I would guess that its UML, but it works pretty reliable in the past few month for me. I'm unable to reproduce the problem, can you send me your config please? You could also get the "umlgdb" script and run uml in debug mode, gdb should be able to tell you more. From mael.boutin at laposte.net Tue Oct 24 09:36:57 2006 From: mael.boutin at laposte.net (mael.boutin@laposte.net) Date: Tue Oct 24 10:15:48 2006 Subject: Problem using connection tracking Message-ID: > You should be able to grab the patches from the git tree. > Its one big patch and a few fixes on top. Or just copy > the Makefile/Kconfig entries and the .c file from 2.6.16. > Excuse me for annoying you again, but could you explain me in more details where to grab the patches. I am not used to do that Thanks for your help Regards, Acc?dez au courrier ?lectronique de La Poste sur www.laposte.net ou sur 3615 LAPOSTENET (0,34? TTC /mn) 1 Giga de stockage gratuit ? Antispam et antivirus int?gr?s From oan at frozentux.net Tue Oct 24 10:57:37 2006 From: oan at frozentux.net (Oskar Andreasson) Date: Tue Oct 24 11:36:09 2006 Subject: CLUSTERIP and UML crash, was [Re: --dport in uml crash] In-Reply-To: <453D4D6C.5050508@trash.net> References: <1161644625.8705.16.camel@LAPTOP4.MSHOME> <453D4D6C.5050508@trash.net> Message-ID: <1161680257.8705.31.camel@LAPTOP4.MSHOME> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : /pipermail/netfilter-devel/attachments/20061024/faacef19/attachment-0001.pgp From laforge at netfilter.org Tue Oct 24 13:35:51 2006 From: laforge at netfilter.org (Harald Welte) Date: Tue Oct 24 14:15:09 2006 Subject: Daily svn snapshots now working again (was Re: patch-o-matic-ng stopped ?) In-Reply-To: <1265.85.68.10.218.1161688632.squirrel@www.on-fire.net> References: <1265.85.68.10.218.1161688632.squirrel@www.on-fire.net> Message-ID: <20061024113551.GN6045@sunbeam.de.gnumonks.org> On Tue, Oct 24, 2006 at 01:17:12PM +0200, Wilfried BARNAVON wrote: > I was used to test new linux kernels with > experimental patches for netfilter, and - oh surprise !- the last month > patch-o-matic-ng archives are more and more little, and finally with a > null content ! You can find the current patch-o-matic-ng repository at http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/ > What happens ? Is this the end of a centralized and structured > iptables developpement ? Is there a break in the developpement team ? patch-o-matic[-ng] alwayas was a collection of various contributions from people around the net, not a form of centralized and structured development > Is there a secret replacement of netfilter that justifies this > carelessness ? nobody is careless. you just seem to be the first person to report that problem to me. > Just a bug in the patch-o-matic-ng "tar-gz" generator ? Exactly. It's fixed now, please use the ftp://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20061024.tar.bz2 snapshot that I just created. Cheers, -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/netfilter-devel/attachments/20061024/31eed8ea/attachment.pgp From kaber at trash.net Tue Oct 24 16:14:55 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 24 16:53:47 2006 Subject: Problem using connection tracking In-Reply-To: References: Message-ID: <453E1FDF.3030403@trash.net> mael.boutin@laposte.net wrote: >>You should be able to grab the patches from the git tree. >>Its one big patch and a few fixes on top. Or just copy >>the Makefile/Kconfig entries and the .c file from 2.6.16. >> > > > Excuse me for annoying you again, but could you explain me in more details where to grab the patches. Either from git (http://kernel.org/git) or just copy the files from 2.6.16. From kaber at trash.net Tue Oct 24 16:24:32 2006 From: kaber at trash.net (Patrick McHardy) Date: Tue Oct 24 17:03:19 2006 Subject: CLUSTERIP and UML crash, was [Re: --dport in uml crash] In-Reply-To: <1161680257.8705.31.camel@LAPTOP4.MSHOME> References: <1161644625.8705.16.camel@LAPTOP4.MSHOME> <453D4D6C.5050508@trash.net> <1161680257.8705.31.camel@LAPTOP4.MSHOME> Message-ID: <453E2220.3090506@trash.net> Oskar Andreasson wrote: > Hi Patrick, > > I'm sorry for the delayed reply, I had to get some sleep. The original > problem seems to have been caused by compiling iptables-1.3.6 against > libc6 and then running against an old libc5. It works flawless now that > they are both the correct version. > > However, I got another kernel panic from the CLUSTERIP target > (possibly?). If not, please let me know where to get this info to:) > > server1:~# iptables -A INPUT -d 192.168.0.5 -p tcp --dport 4444 -j > CLUSTERIP --new --hashmode sourceip --clustermac 01:00:00:00:00:20 > --total-nodes 1 --local-node 1 > ip_tables: (C) 2000-2006 Netfilter Core Team > Kernel panic - not syncing: Kernel mode fault at addr 0xa0be74, ip > 0x400d8cbe > > EIP: 0073:[<400d8cbe>] CPU: 0 Not tainted ESP: 007b:bfb31118 EFLAGS: > 00200246 > Not tainted > EAX: ffffffda EBX: 00000000 ECX: 40019000 EDX: 00000400 > ESI: 08050ef0 EDI: 4014e6c0 EBP: bfb3112c DS: 007b ES: 007b > a0bc3728: [] notifier_call_chain+0x28/0x50 > a0bc3744: [] panic