similar to: [Bridge] [PATCH 2.6] clear hw checksum flags when bridging

The hardware checksumming flags need to be cleared when forwarding packets. Bridging just needs to forward what ever checksum is in the existing skbuff, it doesn't want or need the packet to be resummed. Without this fix, forwarding between smart/dumb interfaces causes an oops. diff -Nru a/net/bridge/br_forward.c b/net/bridge/br_forward.c --- a/net/bridge/br_forward.c Mon Sep 8 09:29:44

Hi all, The patch below does four trivial changes and one big change Trivial changes, these are all in br_netfilter.c: - check ar_pln==4 when giving bridged ARP packets to arptables - delete unnecessary if in br_nf_local_in - add more logging for the "Argh" message - add some brag-comments in the file head comment Big change: let {ip,arp}tables see VLAN tagged {I,AR}P packets. This

Hi, This is a second try to fix the long chain call lengths in netfilter. The difference with the previous patch is that I got rid of the extra argument. I somehow didn't see it could be done without using the 'int *ret2' argument. A comment on the number of arguments to nf_hook_slow: I don't think the number of arguments should be decreased. For the bridge-nf code, f.e., the

hi i have gone through the achieves but still could not get my bridge to suvive a reboot . please can anyone help me am using fedora core 2 -----Original message----- From: bridge-request@lists.osdl.org Date: Fri, 28 Jan 2005 03:08:06 +0100 To: bridge@lists.osdl.org Subject: Bridge Digest, Vol 17, Issue 25 > Send Bridge mailing list submissions to > bridge@lists.osdl.org > >

Hi, The attached patches enables the bridge to filter and forward packets according to their IEEE 802.1q headers. The goals behind this change include : - Enable running STP on 802.1q tagged networks. STP packets must be untagged. It isn't obvious how else to enable STP with the current bridge and vlan code. - Add native support for an untagged vlan. Currently an untagged vlan can

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

Convert the bridge forwarding database over to using RCU. This avoids a read_lock and atomic_inc/dec in the fast path of output. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> diff -Nru a/include/linux/list.h b/include/linux/list.h --- a/include/linux/list.h 2004-07-28 15:30:04 -07:00 +++ b/include/linux/list.h 2004-07-28 15:30:04 -07:00 @@ -678,6 +678,24 @@ pos &&

br_nf_forward_ip() { parent = bridge_parent(out); NF_HOOK(pf, NF_INET_FORWARD, skb, brnf_get_logical_dev(skb, in), parent, br_nf_forward_finish); } here, let us suppose pf = NFPROTO_IPV4, i think the return value of brnf_get_logical_dev(skb, in) equals parent ? its comment 'This is the 'purely bridged' case. For IP, we pass the packet to * netfilter with indev and outdev set to the

br_nf_forward_ip() { parent = bridge_parent(out); NF_HOOK(pf, NF_INET_FORWARD, skb, brnf_get_logical_dev(skb, in), parent, br_nf_forward_finish); } here, let us suppose pf = NFPROTO_IPV4, i think the return value of brnf_get_logical_dev(skb, in) equals parent ? its comment 'This is the 'purely bridged' case. For IP, we pass the packet to * netfilter with indev and outdev set to the

br_nf_forward_ip() { parent = bridge_parent(out); NF_HOOK(pf, NF_INET_FORWARD, skb, brnf_get_logical_dev(skb, in), parent, br_nf_forward_finish); } here, let us suppose pf = NFPROTO_IPV4, i think the return value of brnf_get_logical_dev(skb, in) equals parent ? its comment 'This is the 'purely bridged' case. For IP, we pass the packet to * netfilter with indev and outdev set to the

tl;dr ===== This patchset adds a single bit to the skb to indicate that a packet encountered a layer 2 miss in the bridge and extends flower to match on this metadata. This is required for non-DF (Designated Forwarder) filtering in EVPN multi-homing which prevents decapsulated BUM packets from being forwarded multiple times to the same multi-homed host. Background ========== In a typical EVPN

tl;dr ===== This patchset adds a single bit to the skb to indicate that a packet encountered a layer 2 miss in the bridge and extends flower to match on this metadata. This is required for non-DF (Designated Forwarder) filtering in EVPN multi-homing which prevents decapsulated BUM packets from being forwarded multiple times to the same multi-homed host. Background ========== In a typical EVPN

On Fri, 07 Jan 2005 17:05:59 +0000 David Woodhouse <dwmw2@infradead.org> wrote: > On Sat, 2004-12-18 at 08:50 +0100, Andi Kleen wrote: > > It's not really an oops, just a warning that stack space got quiet > > tight. > > > > The problem seems to be that the br netfilter code is nesting far too > > deeply and recursing several times. Looks like a design

(please keep me on Cc when replying) I have a server running Xen that regularly spews the following. The box seems to survive fine regardless - just thought I''d let everyone know. Dec 8 12:19:26 server kernel: 0x47/0x7a Dec 8 12:19:26 server kernel: [alloc_skb_from_cache+70/243] alloc_skb_from_cache+0x46/0xf3 Dec 8 12:19:26 server kernel: [__dev_alloc_skb+70/92]

Hi stef and all I want measure the policy perfomance for video traffic on mpls diffserv network. there are two different polices for video packet 1. Video packets that are marked that are over the limit are to be rejected at the edge router. 2. Video packets that are marked that are over the limit are to be downgraded as best effort and are sent through. Before video enter my mpls

From: xu xin <xu.xin16 at zte.com.cn> This creates six drop reasons as follows, which will help users know the specific reason why bridge drops the packets when forwarding. 1) SKB_DROP_REASON_BRIDGE_FWD_NO_BACKUP_PORT: failed to get a backup port link when the destination port is down. 2) SKB_DROP_REASON_BRIDGE_FWD_SAME_PORT: destination port is the same with originating port when

Hi, I found this block of code in br_dev_queue_xmit() @ br_forward.c, after applying 'netfilter' patch for 2.4.21 kernel Can someone explain what this block of code is doin? #ifdef CONFIG_NETFILTER if (skb->nf_bridge) memcpy(skb->data - 16, skb->nf_bridge->hh, 16); #endif 1. What is 16 bytes here...? Ethernet hdr is just 14 bytes 2. Why the ethernet