ebtables-devel Mailing List for Ethernet bridge tables (Page 7)
Brought to you by:
bdschuym
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(9) |
Jun
(6) |
Jul
(5) |
Aug
(7) |
Sep
(13) |
Oct
(9) |
Nov
(11) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(13) |
Feb
(8) |
Mar
(32) |
Apr
(21) |
May
(15) |
Jun
(7) |
Jul
(35) |
Aug
(26) |
Sep
(29) |
Oct
(13) |
Nov
(4) |
Dec
(32) |
2004 |
Jan
(2) |
Feb
(20) |
Mar
(9) |
Apr
|
May
(7) |
Jun
(22) |
Jul
(7) |
Aug
(6) |
Sep
(15) |
Oct
(17) |
Nov
(12) |
Dec
(16) |
2005 |
Jan
(6) |
Feb
(15) |
Mar
(17) |
Apr
(27) |
May
(13) |
Jun
(43) |
Jul
(3) |
Aug
(12) |
Sep
(16) |
Oct
(12) |
Nov
(9) |
Dec
(10) |
2006 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
(2) |
Jul
(15) |
Aug
(2) |
Sep
(1) |
Oct
(5) |
Nov
(5) |
Dec
(10) |
2007 |
Jan
(2) |
Feb
(14) |
Mar
(19) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
(9) |
Sep
(6) |
Oct
(7) |
Nov
(4) |
Dec
|
2008 |
Jan
(11) |
Feb
(43) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
(4) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Michael M. <mi...@bl...> - 2007-02-05 21:48:22
|
Hi, I've put together some code to allow IPTables to filter PPPoE traffic in the same way that bridge-nf allows iptables to filter VLAN traffic. I don't have much experience with this code so my approach is very simplistic and modelled after the VLAN code. I have some questions as comments in the patches. I also added a new sysctl entry to allow the functionality to be disabled. The patch is against 2.6.15. Comments appreciated. It works fine for me but I wanted some input before submitting it "officially". Thanks, Mike Milner --- a/include/linux/sysctl.h 2006-03-02 16:18:41.000000000 -0500 +++ b/include/linux/sysctl.h 2007-01-16 15:42:27.000000000 -0500 @@ -726,6 +726,7 @@ enum { NET_BRIDGE_NF_CALL_IPTABLES = 2, NET_BRIDGE_NF_CALL_IP6TABLES = 3, NET_BRIDGE_NF_FILTER_VLAN_TAGGED = 4, + NET_BRIDGE_NF_FILTER_PPPOE_TAGGED = 5, }; /* CTL_PROC names: */ --- a/include/linux/netfilter_bridge.h 2006-03-02 16:18:41.000000000 -0500 +++ b/include/linux/netfilter_bridge.h 2007-02-02 14:31:15.000000000 -0500 @@ -72,6 +72,19 @@ void nf_bridge_maybe_copy_header(struct if (skb->protocol == __constant_htons(ETH_P_8021Q)) { memcpy(skb->data - 18, skb->nf_bridge->data, 18); skb_push(skb, 4); + } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + /* + * Not sure about '24'. Default else block below + * copies 16 bytes. Block above copies 18 (2 more) but + * skb_push's 4 bytes. VLAN header is 4 bytes, so why + * aren't 4 extra bytes being memcpy'd? + * + * I'm memcpy'ing AND skb_push'ing 8 extra bytes, the size + * of the PPPoE header. + */ + memcpy(skb->data - 24, skb->nf_bridge->data, 24); + skb_push(skb, 8); } else memcpy(skb->data - 16, skb->nf_bridge->data, 16); } @@ -84,6 +97,13 @@ void nf_bridge_save_header(struct sk_buf if (skb->protocol == __constant_htons(ETH_P_8021Q)) header_size = 18; + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) + header_size = 24; + /* + * Why does the VLAN code only increase the header by 2 bytes? + * AFAIK the VLAN header is 4 bytes. I reserve 8 extra bytes, + * the size of the PPPoE header. + */ memcpy(skb->nf_bridge->data, skb->data - header_size, header_size); } --- a/net/bridge/br_netfilter.c 2006-03-09 08:19:49.000000000 -0500 +++ b/net/bridge/br_netfilter.c 2007-02-05 16:26:13.000000000 -0500 @@ -12,6 +12,7 @@ * Oct 06 2003: filter encapsulated IP/ARP VLAN traffic on untagged bridge * (bdschuym) * Sep 01 2004: add IPv6 filtering (bdschuym) + * Jan 16 2007: let iptables see bridged PPPoE traffic (mdmilner) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -28,6 +29,7 @@ #include <linux/skbuff.h> #include <linux/if_ether.h> #include <linux/if_vlan.h> +#include <linux/ppp_defs.h> #include <linux/netfilter_bridge.h> #include <linux/netfilter_ipv4.h> #include <linux/netfilter_ipv6.h> @@ -53,6 +55,7 @@ static int brnf_call_iptables = 1; static int brnf_call_ip6tables = 1; static int brnf_call_arptables = 1; static int brnf_filter_vlan_tagged = 1; +static int brnf_filter_pppoe_tagged = 1; #else #define brnf_filter_vlan_tagged 1 #endif @@ -67,6 +70,43 @@ static int brnf_filter_vlan_tagged = 1; hdr->h_vlan_encapsulated_proto == __constant_htons(ETH_P_ARP) && \ brnf_filter_vlan_tagged) +/** + * Entire Ethernet + PPPoE + PPP header + */ +struct pppoe_ethhdr { + unsigned char h_dest[ETH_ALEN]; /* destination eth addr */ + unsigned char h_source[ETH_ALEN]; /* source ether addr */ + __be16 h_pppoe_proto; /* Should always be 0x8864 */ +#if defined(__LITTLE_ENDIAN_BITFIELD) + __u8 ver : 4; + __u8 type : 4; +#elif defined(__BIG_ENDIAN_BITFIELD) + __u8 type : 4; + __u8 ver : 4; +#else +#error "Please fix <asm/byteorder.h>" +#endif + __u8 code; + __u16 sid; + __u16 length; + __be16 h_pppoe_encapsulated_proto; +} __attribute__ ((packed)); + +#define PPPOE_HLEN (sizeof(struct pppoe_ethhdr) - ETH_HLEN) + +/* Extracts the pppoe_ethhdr from an sk_buff */ +static inline struct pppoe_ethhdr *pppoe_eth_hdr(const struct sk_buff *skb) +{ + return (struct pppoe_ethhdr *)skb->mac.raw; +} + +#define IS_PPPOE_IP (skb->protocol == __constant_htons(ETH_P_PPP_SES) && \ + pppoe->h_pppoe_encapsulated_proto == __constant_htons(PPP_IP) && \ + brnf_filter_pppoe_tagged) +//#define IS_PPPOE_IPV6 (skb->protocol == __constant_htons(ETH_P_PPP_SES) && \ +// pppoe->h_pppoe_encapsulated_proto == __constant_htons(PPP_P_IPV6) && \ +// brnf_filter_pppoe_tagged) + /* We need these fake structures to make netfilter happy -- * lots of places assume that skb->dst != NULL, which isn't * all that unreasonable. @@ -195,6 +235,10 @@ static int br_nf_pre_routing_finish_brid skb_pull(skb, VLAN_HLEN); skb->nh.raw += VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_pull(skb, PPPOE_HLEN); + skb->nh.raw += PPPOE_HLEN; + } skb->dst->output(skb); } return 0; @@ -246,6 +290,11 @@ bridged_dnat: skb_push(skb, VLAN_HLEN); skb->nh.raw -= VLAN_HLEN; } + else if (skb->protocol == + __constant_htons(ETH_P_PPP_SES)) { + skb_push(skb, PPPOE_HLEN); + skb->nh.raw -= PPPOE_HLEN; + } NF_HOOK_THRESH(PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL, br_nf_pre_routing_finish_bridge, @@ -266,6 +315,10 @@ bridged_dnat: skb_push(skb, VLAN_HLEN); skb->nh.raw -= VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_push(skb, PPPOE_HLEN); + skb->nh.raw -= PPPOE_HLEN; + } NF_HOOK_THRESH(PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL, br_handle_frame_finish, 1); @@ -408,6 +461,7 @@ static unsigned int br_nf_pre_routing(un struct sk_buff *skb = *pskb; struct nf_bridge_info *nf_bridge; struct vlan_ethhdr *hdr = vlan_eth_hdr(*pskb); + struct pppoe_ethhdr *pppoe = pppoe_eth_hdr(*pskb); if (skb->protocol == __constant_htons(ETH_P_IPV6) || IS_VLAN_IPV6) { #ifdef CONFIG_SYSCTL @@ -427,7 +481,8 @@ static unsigned int br_nf_pre_routing(un return NF_ACCEPT; #endif - if (skb->protocol != __constant_htons(ETH_P_IP) && !IS_VLAN_IP) + if (skb->protocol != __constant_htons(ETH_P_IP) && !IS_VLAN_IP && + !IS_PPPOE_IP) return NF_ACCEPT; if ((skb = skb_share_check(*pskb, GFP_ATOMIC)) == NULL) @@ -436,6 +491,13 @@ static unsigned int br_nf_pre_routing(un if (skb->protocol == __constant_htons(ETH_P_8021Q)) { skb_pull(skb, VLAN_HLEN); } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + /* Not sure why VLAN doesn't have the '+=' line, but PPPoE + * doesn't work without it + */ + skb_pull(skb, PPPOE_HLEN); + skb->nh.raw += PPPOE_HLEN; + } if (!pskb_may_pull(skb, sizeof(struct iphdr))) goto inhdr_error; @@ -522,6 +584,10 @@ static int br_nf_forward_finish(struct s skb_push(skb, VLAN_HLEN); skb->nh.raw -= VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_push(skb, PPPOE_HLEN); + skb->nh.raw -= PPPOE_HLEN; + } NF_HOOK_THRESH(PF_BRIDGE, NF_BR_FORWARD, skb, in, skb->dev, br_forward_finish, 1); return 0; @@ -539,6 +605,7 @@ static unsigned int br_nf_forward_ip(uns struct sk_buff *skb = *pskb; struct nf_bridge_info *nf_bridge; struct vlan_ethhdr *hdr = vlan_eth_hdr(skb); + struct pppoe_ethhdr *pppoe = pppoe_eth_hdr(skb); struct net_device *parent; int pf; @@ -549,7 +616,8 @@ static unsigned int br_nf_forward_ip(uns if (!parent) return NF_DROP; - if (skb->protocol == __constant_htons(ETH_P_IP) || IS_VLAN_IP) + if (skb->protocol == __constant_htons(ETH_P_IP) || IS_VLAN_IP || + IS_PPPOE_IP) pf = PF_INET; else pf = PF_INET6; @@ -558,6 +626,10 @@ static unsigned int br_nf_forward_ip(uns skb_pull(*pskb, VLAN_HLEN); (*pskb)->nh.raw += VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_pull(*pskb, PPPOE_HLEN); + (*pskb)->nh.raw += PPPOE_HLEN; + } nf_bridge = skb->nf_bridge; if (skb->pkt_type == PACKET_OTHERHOST) { @@ -617,6 +689,10 @@ static int br_nf_local_out_finish(struct skb_push(skb, VLAN_HLEN); skb->nh.raw -= VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_push(skb, PPPOE_HLEN); + skb->nh.raw -= PPPOE_HLEN; + } NF_HOOK_THRESH(PF_BRIDGE, NF_BR_LOCAL_OUT, skb, NULL, skb->dev, br_forward_finish, NF_BR_PRI_FIRST + 1); @@ -652,12 +728,14 @@ static unsigned int br_nf_local_out(unsi struct sk_buff *skb = *pskb; struct nf_bridge_info *nf_bridge; struct vlan_ethhdr *hdr = vlan_eth_hdr(skb); + struct pppoe_ethhdr *pppoe = pppoe_eth_hdr(skb); int pf; if (!skb->nf_bridge) return NF_ACCEPT; - if (skb->protocol == __constant_htons(ETH_P_IP) || IS_VLAN_IP) + if (skb->protocol == __constant_htons(ETH_P_IP) || IS_VLAN_IP || + IS_PPPOE_IP) pf = PF_INET; else pf = PF_INET6; @@ -687,6 +765,10 @@ static unsigned int br_nf_local_out(unsi skb_push(skb, VLAN_HLEN); skb->nh.raw -= VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_push(skb, PPPOE_HLEN); + skb->nh.raw -= PPPOE_HLEN; + } NF_HOOK(PF_BRIDGE, NF_BR_FORWARD, skb, realindev, skb->dev, br_forward_finish); @@ -705,6 +787,10 @@ static unsigned int br_nf_local_out(unsi skb_pull(skb, VLAN_HLEN); (*pskb)->nh.raw += VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_pull(skb, PPPOE_HLEN); + (*pskb)->nh.raw += PPPOE_HLEN; + } /* IP forwarded traffic has a physindev, locally * generated traffic hasn't. */ if (realindev != NULL) { @@ -736,6 +822,7 @@ static unsigned int br_nf_post_routing(u struct sk_buff *skb = *pskb; struct nf_bridge_info *nf_bridge = (*pskb)->nf_bridge; struct vlan_ethhdr *hdr = vlan_eth_hdr(skb); + struct pppoe_ethhdr *pppoe = pppoe_eth_hdr(skb); struct net_device *realoutdev = bridge_parent(skb->dev); int pf; @@ -755,7 +842,8 @@ static unsigned int br_nf_post_routing(u if (!realoutdev) return NF_DROP; - if (skb->protocol == __constant_htons(ETH_P_IP) || IS_VLAN_IP) + if (skb->protocol == __constant_htons(ETH_P_IP) || IS_VLAN_IP || + IS_PPPOE_IP) pf = PF_INET; else pf = PF_INET6; @@ -778,6 +866,10 @@ static unsigned int br_nf_post_routing(u skb_pull(skb, VLAN_HLEN); skb->nh.raw += VLAN_HLEN; } + else if (skb->protocol == __constant_htons(ETH_P_PPP_SES)) { + skb_pull(skb, PPPOE_HLEN); + skb->nh.raw += PPPOE_HLEN; + } nf_bridge_save_header(skb); @@ -1004,6 +1096,14 @@ static ctl_table brnf_table[] = { .mode = 0644, .proc_handler = &brnf_sysctl_call_tables, }, + { + .ctl_name = NET_BRIDGE_NF_FILTER_PPPOE_TAGGED, + .procname = "bridge-nf-filter-pppoe-tagged", + .data = &brnf_filter_pppoe_tagged, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &brnf_sysctl_call_tables, + }, { .ctl_name = 0 } }; |
From: Patrick M. <ka...@tr...> - 2007-01-09 11:02:13
|
Bart De Schuymer wrote: > Hi Patrick, > > The included patch translates arpt_counters to xt_counters, making > userspace arptables compile against recent kernels. Applied, thanks Bart. |
From: Bart De S. <bds...@pa...> - 2007-01-07 15:38:39
|
Hi Patrick, The included patch translates arpt_counters to xt_counters, making userspace arptables compile against recent kernels. Please apply, Bart Signed-off-by: Bart De Schuymer <bds...@pa...> |
From: Al V. <vi...@ft...> - 2006-12-26 17:57:20
|
On Mon, Dec 25, 2006 at 11:42:32PM -0500, Chuck Ebbert wrote: > ebtables: don't compute gap until we know we have an ebt_entry > > We must check the bitmap field to make sure we have an ebt_entry and > not an ebt_entries struct before using fields from ebt_entry. > > Signed-off-by: Chuck Ebbert <763...@co...> Acked-by: Al Viro <vi...@ze...> My fault. |
From: Santiago G. M. <ma...@ma...> - 2006-12-26 14:18:31
|
Sorry for not replying before but I could not do any tests before today a= s I didn't have access to any of the machines. > Bingo! Yes, I can confirm that your patch solves the problem, at least on my tes= t cases. Thanks for your help! Regards... --=20 Santiago Garc=EDa Manti=F1=E1n |
From: Chuck E. <763...@co...> - 2006-12-26 04:45:21
|
In-Reply-To: <458...@th...> On Sat, 23 Dec 2006 22:07:46 -0500, Christopher S. Aker wrote: > We're hitting this too, on both 2.6.16.36 and 2.6.19.1. > > BUG: unable to handle kernel paging request at virtual address f8cec008 > printing eip: > c0462272 > *pde = 00000000 > Oops: 0000 [#1] > SMP > Modules linked in: e1000 > CPU: 1 > EIP: 0060:[<c0462272>] Not tainted VLI > EFLAGS: 00010286 (2.6.19.1-1-bigmem #1) > EIP is at translate_table+0x2b3/0xddf > Considering I've never had these problems before, and that both stable > (2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to > guess that it's something that went into both of them very recently. Bingo! It is dying here: static inline int ebt_check_entry(struct ebt_entry *e, struct ebt_table_info *newinfo, const char *name, unsigned int *cnt, unsigned int valid_hooks, struct ebt_cl_stack *cl_s, unsigned int udc_cnt) { struct ebt_entry_target *t; struct ebt_target *target; unsigned int i, j, hook = 0, hookmask = 0; size_t gap = e->next_offset - e->target_offset; <================ int ret; /* don't mess with the struct ebt_entries */ if (e->bitmask == 0) return 0; when trying to access e->next_offset, which may or may not exist because 'e' sometimes points to a 'struct ebt_entries', not 'struct ebt_entry' (note the comment before the 'if'.) This code was recently added. So this (untested) patch should fix it (I tried to move the computation to a place where it's efficient.) If so it's needed for 2.6.16.x, 2.6.18.x, 2.6.19.x and 2.6.20-rc. ebtables: don't compute gap until we know we have an ebt_entry We must check the bitmap field to make sure we have an ebt_entry and not an ebt_entries struct before using fields from ebt_entry. Signed-off-by: Chuck Ebbert <763...@co...> --- 2.6.19.1-32smp.orig/net/bridge/netfilter/ebtables.c +++ 2.6.19.1-32smp/net/bridge/netfilter/ebtables.c @@ -575,7 +575,7 @@ ebt_check_entry(struct ebt_entry *e, str struct ebt_entry_target *t; struct ebt_target *target; unsigned int i, j, hook = 0, hookmask = 0; - size_t gap = e->next_offset - e->target_offset; + size_t gap; int ret; /* don't mess with the struct ebt_entries */ @@ -625,6 +625,7 @@ ebt_check_entry(struct ebt_entry *e, str if (ret != 0) goto cleanup_watchers; t = (struct ebt_entry_target *)(((char *)e) + e->target_offset); + gap = e->next_offset - e->target_offset; target = find_target_lock(t->u.name, &ret, &ebt_mutex); if (!target) goto cleanup_watchers; -- MBTI: IXTP |
From: Christopher S. A. <ca...@th...> - 2006-12-25 01:09:03
|
Christopher S. Aker wrote: > Patrick McHardy wrote: >> I'm trying to reproduce this (without success so far), please send your >> kernel config and your ebtables script. >> >> You could try if 2.6.19 works, there were some ebtables changes in >> 2.6.19.1 that touched this code. > > We're hitting this too, on both 2.6.16.36 and 2.6.19.1. > > BUG: unable to handle kernel paging request at virtual address f8cec008 > printing eip: > c0462272 > *pde = 00000000 > Oops: 0000 [#1] > SMP > Modules linked in: e1000 > CPU: 1 > EIP: 0060:[<c0462272>] Not tainted VLI > EFLAGS: 00010286 (2.6.19.1-1-bigmem #1) > EIP is at translate_table+0x2b3/0xddf > eax: f8ce2000 ebx: 00000004 ecx: f6d53e90 edx: f8ce2000 > esi: f8cebfa0 edi: 0000000e ebp: 00000000 esp: f6d53e08 > ds: 007b es: 007b ss: 0068 > Process ebtables (pid: 4788, ti=f6d52000 task=f6d51550 task.ti=f6d52000) > Stack: f6d53e40 c0540440 00000007 f6d53ebc 00000001 00000028 00000000 > 00000000 > 00000004 00000fa0 00000fd0 f8d38000 f8ce2000 f6d53e90 00000000 > 80000000 > 00000000 00000000 00000000 00000004 00000014 00000000 00000014 > 00000600 > Call Trace: > [<c0462f5f>] do_replace+0x113/0x6da > [<c0142267>] get_page_from_freelist+0x8c/0xa8 > [<c0463f4c>] do_ebt_set_ctl+0x2d/0x2e > [<c03efbc2>] nf_sockopt+0xfa/0xfc > [<c03efbe7>] nf_setsockopt+0x23/0x2b > [<c03fac35>] ip_setsockopt+0x86/0x91 > [<c03d54ef>] sock_common_setsockopt+0x23/0x2f > [<c03d2d69>] sys_setsockopt+0x61/0xac > [<c03d33f3>] sys_socketcall+0x1e9/0x249 > [<c0114348>] do_page_fault+0x0/0x664 > [<c0102bc5>] sysenter_past_esp+0x56/0x79 > [<c047007b>] svc_recv+0x9c/0x3f5 > ======================= > Code: 30 3b 28 0f 83 5c 02 00 00 8b 54 24 30 8b 74 24 24 8b 4c 24 34 8b > 5c 24 4c 03 72 24 8b 79 20 89 5c 24 20 c7 44 24 1c 00 00 00 00 <8b> 56 > 68 8b 46 6c 29 d0 31 d2 89 44 24 14 8b 06 85 c0 0f 84 f7 > EIP: [<c0462272>] translate_table+0x2b3/0xddf SS:ESP 0068:f6d53e08 > > > Unable to handle kernel paging request at virtual address f8a3b00c > printing eip: > c03cce45 > *pde = 00000000 > Oops: 0000 [#13] > SMP > Modules linked in: e1000 > CPU: 1 > EIP: 0060:[<c03cce45>] Not tainted VLI > EFLAGS: 00010246 (2.6.16.36-1-bigmem #1) > EIP is at translate_table+0x47b/0xfc2 > eax: d8fbbc3c ebx: 00000098 ecx: c049b780 edx: 00000000 > esi: f8a3afa0 edi: 0000000e ebp: 00000001 esp: d8fbbb7c > ds: 007b es: 007b ss: 0068 > Process ebtables (pid: 7917, threadinfo=d8fba000 task=e7892550) > Stack: <0>c049b75c f8a3af78 c04468f8 d8fbbbcc c049b740 00000007 d8fbbc68 > d30f4260 > 000000d2 d8fba000 d30f4240 d8fba000 00000028 00000004 00000000 > 00000004 > 00000000 00000fa0 00000fd0 f8a8e000 00000000 f8a38000 00000000 > 00000000 > Call Trace: > [<c03cdbd0>] do_replace+0x16b/0x887 > [<c03ced74>] copy_everything_to_user+0x21a/0x35c > [<c03ceef6>] do_ebt_set_ctl+0x40/0x42 > [<c0354ee0>] nf_sockopt+0x11f/0x121 > [<c0354f19>] nf_setsockopt+0x37/0x3b > [<c0360b14>] ip_setsockopt+0x3f9/0xb0e > [<c0354e6e>] nf_sockopt+0xad/0x121 > [<c0354f54>] nf_getsockopt+0x37/0x3b > [<c03617e6>] ip_getsockopt+0x5bd/0x62b > [<c012360e>] current_fs_time+0x5d/0x78 > [<c0178813>] touch_atime+0x7d/0xcd > [<c014b366>] zap_pte_range+0xf1/0x316 > [<c014b68e>] unmap_page_range+0x103/0x174 > [<c02228a7>] prio_tree_remove+0x77/0xe7 > [<c014358c>] buffered_rmqueue+0x155/0x209 > [<c014358c>] buffered_rmqueue+0x155/0x209 > [<c014376e>] get_page_from_freelist+0x8c/0xa6 > [<c014376e>] get_page_from_freelist+0x8c/0xa6 > [<c01437de>] __alloc_pages+0x56/0x309 > [<c015274c>] page_add_file_rmap+0x2a/0x2c > [<c014d48d>] do_anonymous_page+0x122/0x22a > [<c014dabd>] __handle_mm_fault+0x138/0x326 > [<c03391e6>] sock_common_setsockopt+0x33/0x37 > [<c0336c88>] sys_setsockopt+0x6c/0xb2 > [<c033739a>] sys_socketcall+0x1f4/0x254 > [<c01160e5>] do_page_fault+0x0/0x630 > [<c0102c7f>] sysenter_past_esp+0x54/0x75 > Code: 24 8b bc 24 8c 00 00 00 8b 84 24 88 00 00 00 8b 54 24 64 8b 74 24 > 44 03 77 24 8b 78 20 c7 44 24 38 00 00 00 00 89 54 24 3c 31 d2 <8b> 4e > 6c 8b 5e 68 29 d9 89 4c 24 30 8b 06 85 c0 0f 84 14 02 00 > > > It seems to happen when flushing a user-defined ebtable, or removing a > rule -- but not every time. It leaves the ebtable userspace process in D > state on 2.6.19.1 but not on 2.6.16.36 (?). > > Considering I've never had these problems before, and that both stable > (2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to > guess that it's something that went into both of them very recently. Just a follow-up -- this doesn't happen with 2.6.19. -Chris |
From: Christopher S. A. <ca...@th...> - 2006-12-24 03:07:44
|
Patrick McHardy wrote: > I'm trying to reproduce this (without success so far), please send your > kernel config and your ebtables script. > > You could try if 2.6.19 works, there were some ebtables changes in > 2.6.19.1 that touched this code. We're hitting this too, on both 2.6.16.36 and 2.6.19.1. BUG: unable to handle kernel paging request at virtual address f8cec008 printing eip: c0462272 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: e1000 CPU: 1 EIP: 0060:[<c0462272>] Not tainted VLI EFLAGS: 00010286 (2.6.19.1-1-bigmem #1) EIP is at translate_table+0x2b3/0xddf eax: f8ce2000 ebx: 00000004 ecx: f6d53e90 edx: f8ce2000 esi: f8cebfa0 edi: 0000000e ebp: 00000000 esp: f6d53e08 ds: 007b es: 007b ss: 0068 Process ebtables (pid: 4788, ti=f6d52000 task=f6d51550 task.ti=f6d52000) Stack: f6d53e40 c0540440 00000007 f6d53ebc 00000001 00000028 00000000 00000000 00000004 00000fa0 00000fd0 f8d38000 f8ce2000 f6d53e90 00000000 80000000 00000000 00000000 00000000 00000004 00000014 00000000 00000014 00000600 Call Trace: [<c0462f5f>] do_replace+0x113/0x6da [<c0142267>] get_page_from_freelist+0x8c/0xa8 [<c0463f4c>] do_ebt_set_ctl+0x2d/0x2e [<c03efbc2>] nf_sockopt+0xfa/0xfc [<c03efbe7>] nf_setsockopt+0x23/0x2b [<c03fac35>] ip_setsockopt+0x86/0x91 [<c03d54ef>] sock_common_setsockopt+0x23/0x2f [<c03d2d69>] sys_setsockopt+0x61/0xac [<c03d33f3>] sys_socketcall+0x1e9/0x249 [<c0114348>] do_page_fault+0x0/0x664 [<c0102bc5>] sysenter_past_esp+0x56/0x79 [<c047007b>] svc_recv+0x9c/0x3f5 ======================= Code: 30 3b 28 0f 83 5c 02 00 00 8b 54 24 30 8b 74 24 24 8b 4c 24 34 8b 5c 24 4c 03 72 24 8b 79 20 89 5c 24 20 c7 44 24 1c 00 00 00 00 <8b> 56 68 8b 46 6c 29 d0 31 d2 89 44 24 14 8b 06 85 c0 0f 84 f7 EIP: [<c0462272>] translate_table+0x2b3/0xddf SS:ESP 0068:f6d53e08 Unable to handle kernel paging request at virtual address f8a3b00c printing eip: c03cce45 *pde = 00000000 Oops: 0000 [#13] SMP Modules linked in: e1000 CPU: 1 EIP: 0060:[<c03cce45>] Not tainted VLI EFLAGS: 00010246 (2.6.16.36-1-bigmem #1) EIP is at translate_table+0x47b/0xfc2 eax: d8fbbc3c ebx: 00000098 ecx: c049b780 edx: 00000000 esi: f8a3afa0 edi: 0000000e ebp: 00000001 esp: d8fbbb7c ds: 007b es: 007b ss: 0068 Process ebtables (pid: 7917, threadinfo=d8fba000 task=e7892550) Stack: <0>c049b75c f8a3af78 c04468f8 d8fbbbcc c049b740 00000007 d8fbbc68 d30f4260 000000d2 d8fba000 d30f4240 d8fba000 00000028 00000004 00000000 00000004 00000000 00000fa0 00000fd0 f8a8e000 00000000 f8a38000 00000000 00000000 Call Trace: [<c03cdbd0>] do_replace+0x16b/0x887 [<c03ced74>] copy_everything_to_user+0x21a/0x35c [<c03ceef6>] do_ebt_set_ctl+0x40/0x42 [<c0354ee0>] nf_sockopt+0x11f/0x121 [<c0354f19>] nf_setsockopt+0x37/0x3b [<c0360b14>] ip_setsockopt+0x3f9/0xb0e [<c0354e6e>] nf_sockopt+0xad/0x121 [<c0354f54>] nf_getsockopt+0x37/0x3b [<c03617e6>] ip_getsockopt+0x5bd/0x62b [<c012360e>] current_fs_time+0x5d/0x78 [<c0178813>] touch_atime+0x7d/0xcd [<c014b366>] zap_pte_range+0xf1/0x316 [<c014b68e>] unmap_page_range+0x103/0x174 [<c02228a7>] prio_tree_remove+0x77/0xe7 [<c014358c>] buffered_rmqueue+0x155/0x209 [<c014358c>] buffered_rmqueue+0x155/0x209 [<c014376e>] get_page_from_freelist+0x8c/0xa6 [<c014376e>] get_page_from_freelist+0x8c/0xa6 [<c01437de>] __alloc_pages+0x56/0x309 [<c015274c>] page_add_file_rmap+0x2a/0x2c [<c014d48d>] do_anonymous_page+0x122/0x22a [<c014dabd>] __handle_mm_fault+0x138/0x326 [<c03391e6>] sock_common_setsockopt+0x33/0x37 [<c0336c88>] sys_setsockopt+0x6c/0xb2 [<c033739a>] sys_socketcall+0x1f4/0x254 [<c01160e5>] do_page_fault+0x0/0x630 [<c0102c7f>] sysenter_past_esp+0x54/0x75 Code: 24 8b bc 24 8c 00 00 00 8b 84 24 88 00 00 00 8b 54 24 64 8b 74 24 44 03 77 24 8b 78 20 c7 44 24 38 00 00 00 00 89 54 24 3c 31 d2 <8b> 4e 6c 8b 5e 68 29 d9 89 4c 24 30 8b 06 85 c0 0f 84 14 02 00 It seems to happen when flushing a user-defined ebtable, or removing a rule -- but not every time. It leaves the ebtable userspace process in D state on 2.6.19.1 but not on 2.6.16.36 (?). Considering I've never had these problems before, and that both stable (2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to guess that it's something that went into both of them very recently. -Chris |
From: Patrick M. <ka...@tr...> - 2006-12-20 09:24:12
|
Santiago Garcia Mantinan wrote: > Hi! > > When trying to upgrade a machine from 2.6.18 to 2.6.19.1 I found that it > crashed when loading the ebtables rules on startup. > > This is an example of the crash I get: > > BUG: unable to handle kernel paging request at virtual address e081e004 > printing eip: > c0283da0 > *pde = 1fbcb067 > *pte = 00000000 > Oops: 0000 [#1] > CPU: 0 > EIP: 0060:[<c0283da0>] Not tainted VLI > EFLAGS: 00010282 (2.6.19.1 #1) > EIP is at translate_table+0x600/0xe90 > > [..] > > I've tried to find a subset of the rules that are causing this and I found > that to be very difficult as I have only got this to fail if I load the > ebtables rules at boot time, if I try to load them after the machine is > completely booted it works ok. 2.6.18 still works ok, both kernels have the > "same" config where posible and they are not SMP. At what point during boot time do you load your rules? Is networking already up? > The machine that was having the failure was a PIII 1GHz, I have copied the > filesystem to a PIV 1.6Ghz where it also fails and where I can do tests and > access the console via serial port. > > The machine is not being used as a brouter but only as a bridge firewall, it > has some ebtables rules to cut non IP stuff and then does all the work at > iptables level. > > I don't know what other info to add here, tell me if you need any other > stuff to diagnose this or any testing here. I'm trying to reproduce this (without success so far), please send your kernel config and your ebtables script. You could try if 2.6.19 works, there were some ebtables changes in 2.6.19.1 that touched this code. |
From: Carl-Daniel H. <c-d...@gm...> - 2006-12-18 03:29:10
|
Bart De Schuymer wrote: > Op wo, 13-12-2006 te 16:42 +0100, schreef Carl-Daniel Hailfinger: >> # ebtables-v2.0.8-rc2-static -t nat -A ebtables-experiment -p IPv4 --ip-proto tcp --ip-dport 7777:7778 -j DROP >> The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension. > > Is that executable static (make static)? If so, perhaps not using -fPIC > solves it. Probably not. The executable is static. The dynamic one shows the same problem. Enabling/disabling -fPIC has no effect on the runtime problems, it only affects compilability. > I can't debug this since I don't have access to such a platform. I'll try to dig up a qemu image with x86_64 inside so you can test it on any platform. > I'll apply the fPIC option. Thanks. Regards, Carl-Daniel -- http://www.hailfinger.org/ |
From: Bart De S. <bds...@pa...> - 2006-12-14 18:51:53
|
Op wo, 13-12-2006 te 16:42 +0100, schreef Carl-Daniel Hailfinger: > # ebtables-v2.0.8-rc2-static -t nat -A ebtables-experiment -p IPv4 --ip-proto tcp --ip-dport 7777:7778 -j DROP > The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension. Is that executable static (make static)? If so, perhaps not using -fPIC solves it. Probably not. I can't debug this since I don't have access to such a platform. I'll apply the fPIC option. cheers, Bart |
From: Carl-Daniel H. <c-d...@gm...> - 2006-12-13 15:41:52
|
Hi, ebtables 2.0.8-rc2 compilation fails on x86_64. # uname -a Linux switch 2.6.16.34-haisec07 #1 Fri Mar 24 11:32:37 CET 2006 x86_64 x86_64 x86_64 GNU/Linux # make gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o getethertype.o getethertype.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o communication.o communication.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o libebtc.o libebtc.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o useful_functions.o useful_functions.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o ebtables.o ebtables.c -Iinclude/ ebtables.c: In function `list_em': ebtables.c:324: warning: long long unsigned int format, uint64_t arg (arg 2) ebtables.c:324: warning: long long unsigned int format, uint64_t arg (arg 3) ebtables.c:326: warning: long long unsigned int format, uint64_t arg (arg 2) ebtables.c:326: warning: long long unsigned int format, uint64_t arg (arg 3) gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_802_3.o extensions/ebt_802_3.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_nat.o extensions/ebt_nat.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_arp.o extensions/ebt_arp.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_arpreply.o extensions/ebt_arpreply.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_ip.o extensions/ebt_ip.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_standard.o extensions/ebt_standard.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_log.o extensions/ebt_log.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_redirect.o extensions/ebt_redirect.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_vlan.o extensions/ebt_vlan.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_mark_m.o extensions/ebt_mark_m.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_mark.o extensions/ebt_mark.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_pkttype.o extensions/ebt_pkttype.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_stp.o extensions/ebt_stp.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_among.o extensions/ebt_among.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_limit.o extensions/ebt_limit.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebt_ulog.o extensions/ebt_ulog.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebtable_filter.o extensions/ebtable_filter.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebtable_nat.o extensions/ebtable_nat.c -Iinclude/ gcc -Wall -Wunused -DPROGVERSION=\"2.0.8-rc2\" -DPROGNAME=\"ebtables\" -DPROGDATE=\"March\ 2006\" -D_PATH_ETHERTYPES=\"/etc/ethertypes\" -DEBTD_ARGC_MAX=50 -DEBTD_CMDLINE_MAXLN=2048 -c -o extensions/ebtable_broute.o extensions/ebtable_broute.c -Iinclude/ ld -shared -o extensions/ebt_802_3.so -lc extensions/ebt_802_3.o ld: extensions/ebt_802_3.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC extensions/ebt_802_3.o: could not read symbols: Bad value make: *** [extensions/ebt_802_3.so] Error 1 This patch fixes it: --- a/Makefile 2006-12-13 16:00:38.000000000 +0100 +++ b/Makefile 2006-12-13 15:59:38.000000000 +0100 @@ -22,7 +22,7 @@ override SYSCONFIGDIR:=$(DESTDIR)$(SYSCONFIGDIR) -CFLAGS:=-Wall -Wunused +CFLAGS:=-Wall -Wunused -fPIC CC:=gcc LD:=ld After this, ebtables can be built, but it will segfault when trying to insert a rule. The segfault can be fixed with this patch (found in Fedora): --- ebtables-v2.0.8-rc2/libebtc.c.BAD 2006-09-14 13:53:38.000000000 -0500 +++ ebtables-v2.0.8-rc2/libebtc.c 2006-09-14 13:53:54.000000000 -0500 @@ -1033,7 +1033,7 @@ stack[sp].e = e; sp++; j = -1; - e = entries2->entries; + e = entries2->entries->next; chain_nr = verdict + NF_BR_NUMHOOKS; entries = entries2; continue; After this, ebtables can at least insert simple rules, but once I try the --ip-dport match, it fails again (ebtables-2.0.6 works fine): # ebtables-v2.0.8-rc2-static -t nat -A ebtables-experiment -p IPv4 --ip-proto tcp --ip-dport 7777:7778 -j DROP The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension. dmesg says this: kernel msg: ebtables bug: please report to author: entries_size too small What next? Regards, Carl-Daniel -- http://www.hailfinger.org/ |
From: Patrick M. <ka...@tr...> - 2006-12-04 10:42:11
|
Bart De Schuymer wrote: > Hi Patrick, > > The attached patch resolves an issue where a IP DNATed packet with a > martian source is forwarded while it's better to drop it. It also > resolves messages complaining about ip forwarding being disabled while > it's actually enabled. Thanks to lepton <yth...@gm...> for > reporting this problem. > This is probably a candidate for the -stable release. Applied, thanks Bart. I'll push it to stable. |
From: Bart De S. <bds...@pa...> - 2006-11-28 19:43:40
|
Hi Patrick, The attached patch resolves an issue where a IP DNATed packet with a martian source is forwarded while it's better to drop it. It also resolves messages complaining about ip forwarding being disabled while it's actually enabled. Thanks to lepton <yth...@gm...> for reporting this problem. This is probably a candidate for the -stable release. cheers, Bart Signed-off-by: Bart De Schuymer <bds...@pa...> |
From: Carl-Daniel H. <c-d...@gm...> - 2006-11-24 07:03:36
|
Hi, When I try to add or remove a rule with ebtables on x86_64, ebtables segfaults in libebtc.c:1014. Example rule follows: # ebtables -t nat -D foo -s 1:22:3:44:5:66 -j ipv4filter-blacklist e->t == NULL, i == 0, j == 0 in libebtc.c:1022. This did not happen with ebtables 2.0.6 on x86_64, but there the kernel spat out the following message: "kernel msg: ebtables bug: please report to author: entries_size too small" This happened only when I tried to add rules to from two chains early in the ruleset to chains a bit later in the ruleset. However, the destination rules/chains were created much later. Ebtables gave this error message: "The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension." The identical configuration does not have any problems on i386. Regards, Carl-Daniel -- http://www.hailfinger.org/ |
From: lepton <yth...@gm...> - 2006-11-03 04:20:27
|
In most case, redirected packets will not go here ( ip_route_input will return 0). I do some test: ifconfig br0 192.168.3.100 iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to 3128 Redirect is working without this patch. So what is the exactly case that redirected packets will get dropped? Thanks 2006/11/3, Bart De Schuymer <bds...@pa...>: > > Op do, 02-11-2006 te 20:46 +0800, schreef lepton: > > I found some times we can receive martian_source packet > > after dnat on bridge. > > > > After looking into some code, I found the problem is related > > a patch posted here before, why we added the check for > rt->rt_type==RTN_LOCAL > > here? what problem is this patch fixed for? > > > > With this patch, if redirect take place on a martin_source packet, the > > packet will not be dropped(because we ignore the result of route_input, > > then we call route_output_key with a zero source addr). > > The patch was to deal with the problem that ip_route_output_key > reportedly returns 0 for redirected packets, which would normally mean > the packet is dropped and the message "Performing cross-bridge DNAT > requires IP forwarding to be enabled" is printed. By checking for > RTN_LOCAL, these redirected packets aren't stopped. > > Are you saying that except for martian source packets and other > anomalies, redirected packets aren't dropped if this patch isn't used? > > cheers, > Bart > > > |
From: Bart De S. <bds...@pa...> - 2006-11-02 22:16:38
|
Op do, 02-11-2006 te 20:46 +0800, schreef lepton: > I found some times we can receive martian_source packet > after dnat on bridge. > > After looking into some code, I found the problem is related > a patch posted here before, why we added the check for rt->rt_type==RTN_LOCAL > here? what problem is this patch fixed for? > > With this patch, if redirect take place on a martin_source packet, the > packet will not be dropped(because we ignore the result of route_input, > then we call route_output_key with a zero source addr). The patch was to deal with the problem that ip_route_output_key reportedly returns 0 for redirected packets, which would normally mean the packet is dropped and the message "Performing cross-bridge DNAT requires IP forwarding to be enabled" is printed. By checking for RTN_LOCAL, these redirected packets aren't stopped. Are you saying that except for martian source packets and other anomalies, redirected packets aren't dropped if this patch isn't used? cheers, Bart |
From: lepton <yth...@gm...> - 2006-11-02 12:46:51
|
I found some times we can receive martian_source packet after dnat on bridge. After looking into some code, I found the problem is related a patch posted here before, why we added the check for rt->rt_type==RTN_LOCAL here? what problem is this patch fixed for? With this patch, if redirect take place on a martin_source packet, the packet will not be dropped(because we ignore the result of route_input, then we call route_output_key with a zero source addr). The following is the patch posted here before: Hi Dave, Here's a slightly altered patch, originally from Mark Glines who diagnosed and fixed the problem. Please apply, Bart Signed-off-by: Bart De Schuymer <bdschuym@pa...> --- linux-2.6.13/net/bridge/br_netfilter.c.old 2005-09-14 19:35:17.410164848 +0000 +++ linux-2.6.13/net/bridge/br_netfilter.c 2005-09-14 19:38:20.233371496 +0000 @@ -214,9 +214,11 @@ static int br_nf_pre_routing_finish(stru .tos = RT_TOS(iph->tos)} }, .proto = 0}; if (!ip_route_output_key(&rt, &fl)) { - /* Bridged-and-DNAT'ed traffic doesn't - * require ip_forwarding. */ - if (((struct dst_entry *)rt)->dev == dev) { + /* - Bridged-and-DNAT'ed traffic doesn't + * require ip_forwarding. + * - Deal with redirected traffic. */ + if (((struct dst_entry *)rt)->dev == dev || + rt->rt_type == RTN_LOCAL) { skb->dst = (struct dst_entry *)rt; goto bridged_dnat; } |
From: Bart De S. <bds...@pa...> - 2006-10-29 16:51:48
|
Op ma, 16-10-2006 te 19:03 +0200, schreef Daniele Gozzi: > I have developed a new match extension which matches every 'n'th > frame. This may be useful for research purposes or for load balancing > (e.g. we are using it to scatter frames to several IDS sensors using > DNAT in a round-robin fashion). Hi Daniele, I've been thinking it over and I'm going to postpone submitting your patch. General iptables filtering modules like limit, nth, random, ... shouldn't be recreated for ebtables. Instead, I'll think about a scheme in which it's possible to include iptables matches (and possibly targets) in ebtables rules. I'll make this my top priority concerning ebtables. cheers, Bart > _______________________________________________ Ebtables-devel mailing list Ebt...@li... https://lists.sourceforge.net/lists/listinfo/ebtables-devel |
From: Bart De S. <bds...@pa...> - 2006-10-28 15:08:02
|
Op di, 24-10-2006 te 14:50 +0000, schreef Marian Jancar: > Bart De Schuymer wrote: > > The problem with dynamic macnat is that the kernel sk_buff structure > > will have to be altered, which is something the network maintainers > > don't like. Apart from that there should be no big problems implementing > > it. > > I currently lack the time for any serious development, though. > > Anything new on this? The gains here IMHO fully justify the new field > (that can be ifdefed out when the feature not enabled in .config) in > the sk_buff. I've put it on the todo list and will have a look to it when time and energy level permit. cheers, Bart |
From: Marian J. <mj...@su...> - 2006-10-24 15:06:28
|
Bart De Schuymer wrote: > The problem with dynamic macnat is that the kernel sk_buff structure > will have to be altered, which is something the network maintainers > don't like. Apart from that there should be no big problems implementing > it. > I currently lack the time for any serious development, though. Anything new on this? The gains here IMHO fully justify the new field (that can be ifdefed out when the feature not enabled in .config) in the sk_buff. Marian |
From: Bart De S. <bds...@pa...> - 2006-10-17 17:36:16
|
Op ma, 16-10-2006 te 19:03 +0200, schreef Daniele Gozzi: > I have developed a new match extension which matches every 'n'th > frame. This may be useful for research purposes or for load balancing > (e.g. we are using it to scatter frames to several IDS sensors using > DNAT in a round-robin fashion). Thanks. Some remarks from a swift glance... Please make the code follow the same style as the other ebtables modules (e.g. a define named NTH_EVERY instead of ARG_EVERY). Options of extensions should start with the name of the extension followed by a minus sign: please change --every to --nth-every. Can you please send the adjusted files as attachments? cheers, Bart |
From: Daniele G. <dan...@gm...> - 2006-10-16 17:03:19
|
I have developed a new match extension which matches every 'n'th frame. This may be useful for research purposes or for load balancing (e.g. we are using it to scatter frames to several IDS sensors using DNAT in a round-robin fashion). $ diff -r ebtables-v2.0.8-rc2 ebtables-v2.0.8-rc2_DanieleGozzi Only in ebtables-v2.0.8-rc2_DanieleGozzi/extensions: ebt_nth.c diff -r ebtables-v2.0.8-rc2/extensions/Makefile ebtables-v2.0.8-rc2_DanieleGozzi/extensions/Makefile 4c4 < pkttype stp among limit ulog --- > pkttype stp among limit ulog nth Only in ebtables-v2.0.8-rc2_DanieleGozzi/include/linux/netfilter_bridge:ebt_nth.h The code of the two new files (following) should compile without warning against ebtables v2.0.8-rc2 (I'm using gcc v4.0.3). ---***--- ebt_nth.h ---***--- #ifndef __LINUX_BRIDGE_EBT_NTH_H #define __LINUX_BRIDGE_EBT_NTH_H #define EBT_NTH_MATCH "nth" struct ebt_nth_info { unsigned long int every; // match every /every/ frames. unsigned long int frame; // match phase shift. match on /frame-th/ frame every /every/ frames. /* Used internally by the kernel module*/ unsigned long int counter; }; #endif ---***---***---***--- ---***--- ebt_nth.c ---***--- /* Shared library add-on to ebtables to add "nth" match support. * Daniele Gozzi <dan...@gm...> * based on: * Shared library add-on to ebtables to add limit support. (part of ebtables package) * (Swipted from iptables' limit match.) */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <getopt.h> #include <netinet/ether.h> #include "../include/ebtables_u.h" #include <linux/netfilter_bridge/ebt_nth.h> /* from iptables.c */ #include <errno.h> int string_to_number_lu(const char *s, unsigned long int min, unsigned long int max, unsigned long int *ret) { unsigned long int number; char *end; /* Handle hex, octal, etc. */ errno = 0; number = strtoul(s, &end, 0); if (*end == '\0' && end != s) { /* we parsed a number, let's see if we want this */ if (errno != ERANGE && min <= number && number <= max) { *ret = number; return 0; } } return -1; } #define FLAG_EVERY 0x01 #define FLAG_FRAME 0x02 #define ARG_EVERY '1' #define ARG_FRAME '2' static struct option opts[] = { { "every", required_argument, 0, ARG_EVERY }, { "frame", required_argument, 0, ARG_FRAME }, { 0 } }; static void print_help(void) { printf( "limit options:\n" "--every number match rate\n" "--frame number frame number to match, 0 <= number < every_number" " (default = 0)\n" "\n"); } /* Initialize the match. */ static void init(struct ebt_entry_match *m) { struct ebt_nth_info *r = (struct ebt_nth_info *)m->data; r->counter = 0; r->frame = 0; // default r->every = 0; // default } static int parse(int c, char **argv, int argc, const struct ebt_u_entry *entry, unsigned int *flags, struct ebt_entry_match **match) { struct ebt_nth_info *r = (struct ebt_nth_info *)(*match)->data; switch(c) { case ARG_EVERY: ebt_check_option2(flags, FLAG_EVERY); if (ebt_check_inverse2(optarg)) ebt_print_error2("Unexpected `!' after --every"); if (string_to_number_lu(optarg, 1, ULONG_MAX,&r->every) == -1) ebt_print_error2("bad --every `%s' (must be between 1 and %u)", optarg, ULONG_MAX); break; case ARG_FRAME: ebt_check_option2(flags, FLAG_FRAME); if (ebt_check_inverse2(optarg)) ebt_print_error2("Unexpected `!' after --frame"); if (string_to_number_lu(optarg, 0, ULONG_MAX-1, &r->frame) == -1) ebt_print_error2("bad --frame `%s' (must be between 1 and %u)", optarg, ULONG_MAX-1); break; default: return 0; } return 1; } static void final_check(const struct ebt_u_entry *entry, const struct ebt_entry_match *match, const char *name, unsigned int hookmask, unsigned int time) { struct ebt_nth_info *r = (struct ebt_nth_info *)match->data; if (r->every==0 || r->frame >= r->every) ebt_print_error("--frame argument must be lower than --every"); } /* Prints out the matchinfo. */ static void print(const struct ebt_u_entry *entry, const struct ebt_entry_match *match) { struct ebt_nth_info *r = (struct ebt_nth_info *)match->data; printf("--every %lu ",r->every); printf("--frame %lu ",r->frame); } static int compare(const struct ebt_entry_match* m1, const struct ebt_entry_match *m2) { struct ebt_nth_info* li1 = (struct ebt_nth_info*)m1->data; struct ebt_nth_info* li2 = (struct ebt_nth_info*)m2->data; if (li1->every != li2->every) return 0; if (li1->frame != li2->frame) return 0; return 1; } static struct ebt_u_match nth_match = { .name = EBT_NTH_MATCH, .size = sizeof(struct ebt_nth_info), .help = print_help, .init = init, .parse = parse, .final_check = final_check, .print = print, .compare = compare, .extra_ops = opts, }; //static _init(void) __attribute((constructor)); void _init(void) { ebt_register_match(&nth_match); } ---***---***---***--- Of course a matching kernel module is needed. Module code follows (it uses the same ebt_nth.h header file as the previous ebtables code): ---***--- ebt_nth.c ---***--- /* * ebt_nth * * Authors: * Daniele Gozzi <dan...@gm...> * * Nth frame match module for ebtables / linux netfilter-bridge * Based on ebt_limit.c by Tom Marshall and bt_802_3.c by Chris Vitale */ #include <linux/module.h> /* Needed by all modules */ #include <linux/kernel.h> /* Needed for KERN_INFO */ #include <linux/init.h> /* Needed for the macros */ #include <linux/netfilter_bridge/ebtables.h> #include "ebt_nth.h" MODULE_AUTHOR("Daniele Gozzi"); static int ebt_nth_match(const struct sk_buff *skb, const struct net_device *in, const struct net_device *out, const void *data, unsigned int datalen) { struct ebt_nth_info *info = (struct ebt_nth_info *) data; /* update counter value (modulo /every/) */ info->counter = (info->counter + 1) % info->every; /* is this frame supposed to match? */ if (info->counter == info->frame) return EBT_MATCH; return EBT_NOMATCH; } static int ebt_nth_check(const char *tablename, unsigned int hookmask, const struct ebt_entry *e, void *data, unsigned int datalen) { struct ebt_nth_info *info = (struct ebt_nth_info *) data; if (datalen < sizeof(struct ebt_nth_info)) return -EINVAL; if (info->every == 0 || info->frame >= info->every) return -EINVAL; return 0; } static struct ebt_match ebt_nth_reg = { .name = EBT_NTH_MATCH, .match = ebt_nth_match, .check = ebt_nth_check, .me = THIS_MODULE, }; static int __init nth_match_init(void) { printk(KERN_INFO "Initializing nth match for ebtables\n"); return ebt_register_match(&ebt_nth_reg); } static void __exit nth_match_exit(void) { printk(KERN_INFO "Unloading nth match for ebtables\n"); ebt_unregister_match(&ebt_nth_reg); } module_init(nth_match_init); module_exit(nth_match_exit); ---***---***---***--- ---***--- Makefile ---***--- obj-m += ebt_nth.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean ---***---***---***--- Thank you for your consideration. Daniele Gozzi |
From: David M. <da...@da...> - 2006-09-19 19:37:07
|
From: Bart De Schuymer <bds...@pa...> Date: Thu, 05 Oct 2006 22:07:58 +0200 > The following patch adds or/and/xor functionality for the mark > target, while staying backwards compatible. Bart, please submit your changes through Patrick McHardy since he is the toplevel netfilter maintainer. He had some problems with your patch already, namely: 1) The comparison of info->target with EBT_RETURN is done without masking out the action. 2) The use of negative numbers makes the code needlessly unreadable compared to just using bitmasks. Thanks. |
From: <la...@gm...> - 2006-08-15 14:15:08
|
Hi, I just discovered a little bug in arptables: the short version for --h-length doesn't work, so here's a patch that corrects this. Cheers. diff -Naur arptables-v0.0.3-2.orig/arptables.c arptables-v0.0.3-2 /arptables.c --- arptables-v0.0.3-2.orig/arptables.c 2003-10-25 13:43:24.000000000 +0300 +++ arptables-v0.0.3-2/arptables.c 2006-08-15 16:58:37.000000000 +0300 @@ -134,7 +134,7 @@ { "destination-mac", 1, 0, 3}, { "src-mac", 1, 0, 2}, { "dst-mac", 1, 0, 3}, - { "h-length", 1, 0, 7 }, + { "h-length", 1, 0, 'l' }, { "p-length", 1, 0, 8 }, { "opcode", 1, 0, 4 }, { "h-type", 1, 0, 5 }, @@ -1988,7 +1988,7 @@ "destination mac"); break; - case 7:/* hardware length */ + case 'l':/* hardware length */ check_inverse(optarg, &invert, &optind, argc); set_option(&options, OPT_H_LENGTH, &fw.arp.invflags, invert); -- Laszlo Bako-Szabo Network Administrator |