search for: h_source

...ge.orig/net/bridge/br_input.c +++ bridge/net/bridge/br_input.c @@ -54,6 +54,9 @@ int br_handle_frame_finish(struct sk_buf struct net_bridge_fdb_entry *dst; int passedup = 0; + /* insert into forwarding database after filtering to avoid spoofing */ + br_fdb_update(p->br, p, eth_hdr(skb)->h_source); + if (br->dev->flags & IFF_PROMISC) { struct sk_buff *skb2; @@ -108,8 +111,7 @@ int br_handle_frame(struct net_bridge_po if (!is_valid_ether_addr(eth_hdr(skb)->h_source)) goto err; - if (p->state == BR_STATE_LEARNING || - p->state == BR_STATE_FORWARDING) + if...

Could the problem be that the e100 can do IP receive checksumming on the board, but the eepro driver doesn't enable it. When the board is doing checksum offload, then the csum field isn't set. Please try disabling receive checksumming on the e100 driver modprobe e100 XsumRX=0 If this is the problem, it exists both 2.4 and 2.6. On Wed, 27 Aug 2003 18:24:57 +0200 Hannes Schulz

...learning the mac-address on the wrong port. This is tested with kernel 2.6.11.12 and 2.6.13.2, and both exhibit this problem. The following fix solved it for me on 2.6.11.12: In net/bridge/br_stp_bpdu.c, in function br_stp_handle_bpdu i changed br_fdb_insert(p->br, p, eth_hdr(skb)->h_source,0); to if (!br->stp_enabled || p->state == BR_STATE_LEARNING || p->state == BR_STATE_FORWARDING) br_fdb_insert(p->br, p, eth_hdr(skb)->h_source, 0); /B

The following series adds 2 new flags to bridge. One flag allows the user to control whether mac learning is performed on the interface or not. By default mac learning is on. The other flag allows the user to control whether unicast traffic is flooded (send without an fdb) to a given unicast port. Default is on. Changes since v4: - Implemented Stephen's suggestions. Changes since v2: -

...-122,6 +122,7 @@ static inline int is_link_local(const unsigned char *dest) struct sk_buff *br_handle_frame(struct net_bridge_port *p, struct sk_buff *skb) { const unsigned char *dest = eth_hdr(skb)->h_dest; + typeof(br_should_route_hook) rhook; if (!is_valid_ether_addr(eth_hdr(skb)->h_source)) goto drop; @@ -147,9 +148,9 @@ struct sk_buff *br_handle_frame(struct net_bridge_port *p, struct sk_buff *skb) switch (p->state) { case BR_STATE_FORWARDING: - - if (br_should_route_hook) { - if (br_should_route_hook(skb)) + rhook = rcu_dereference(br_should_route_hook); + if (rho...

...struct net_bridge_port *p; struct net_bridge_port *prev; + struct net_bridge_port *sp = NULL; + + /* + * If we are a VEPA, then we do not want to send the frame + * to the port it came from originally. + */ + if (br->flags & BR_VEPA_MODE) + sp = br_vepa_find_src(br, eth_hdr(skb)->h_source); prev = NULL; list_for_each_entry_rcu(p, &br->port_list, list) { - if (should_deliver(p, skb)) { + if (should_deliver(p, skb) && p != sp) { if (prev != NULL) { struct sk_buff *skb2; diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c index 8a96672..22239ef 1006...

...struct net_bridge_port *p; struct net_bridge_port *prev; + struct net_bridge_port *sp = NULL; + + /* + * If we are a VEPA, then we do not want to send the frame + * to the port it came from originally. + */ + if (br->flags & BR_VEPA_MODE) + sp = br_vepa_find_src(br, eth_hdr(skb)->h_source); prev = NULL; list_for_each_entry_rcu(p, &br->port_list, list) { - if (should_deliver(p, skb)) { + if (should_deliver(p, skb) && p != sp) { if (prev != NULL) { struct sk_buff *skb2; diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c index 8a96672..22239ef 1006...

...struct net_bridge_port *p; struct net_bridge_port *prev; + struct net_bridge_port *sp = NULL; + + /* + * If we are a VEPA, then we do not want to send the frame + * to the port it came from originally. + */ + if (br->flags & BR_VEPA_MODE) + sp = br_vepa_find_src(br, eth_hdr(skb)->h_source); prev = NULL; list_for_each_entry_rcu(p, &br->port_list, list) { - if (should_deliver(p, skb)) { + if (should_deliver(p, skb) && p != sp) { if (prev != NULL) { struct sk_buff *skb2; diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c index 8a96672..22239ef 1006...

...uld_deliver(p, skb, NULL)) return prev; nbp_switchdev_frame_mark_tx_fwd_to_hwdom(p, skb); @@ -254,7 +281,7 @@ static void maybe_deliver_addr(struct net_bridge_port *p, struct sk_buff *skb, struct net_device *dev = BR_INPUT_SKB_CB(skb)->brdev; const unsigned char *src = eth_hdr(skb)->h_source; - if (!should_deliver(p, skb)) + if (!should_deliver(p, skb, NULL)) return; /* Even with hairpin, no soliloquies - prevent breaking IPv6 DAD */ -- 2.15.2

...d? */ return (skb->mac.raw >= skb->head - && skb->mac.raw < skb->head + skb->len - ETH_HLEN + && (skb->mac.raw + ETH_HLEN) <= skb->data /* If so, compare... */ && ((memcmp(skb->mac.ethernet->h_source, info->srcaddr, ETH_ALEN) == 0) ^ info->invert)); Harald Welte writes: > the patch has been submitted to David Miller just one minute ago. WORKAROUND ---------- The simplest, but least secure, workaround is to avoid matching by MAC address, but only match on IP address...

This series of patches provides an ability to add VLANs to the bridge ports. This is similar to what can be found in most switches. The bridge port may have any number of VLANs added to it including vlan 0 priority tagged traffic. When vlans are added to the port, only traffic tagged with particular vlan will forwarded over this port. Additionally, vlan ids are added to FDB entries and become

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Hi, We have a simple bridge setup but the ping (and other network traffic) does not work reliably. After tracing the code, it looks like a software bug. Since bridge software is been running by thousands of people. I guess I am wrong. Anyway, here is the problem. There are 2 boxes and each one has 2 interfaces, 1 ethernet and 1 wifi. STP is enabled for the bridge to avoid the loop. So the box 1

Changes since v9: * series re-ordering so make functionality more distinct. Basic vlan filtering is patches 1-4. Support for PVID/untagged vlans is patches 5 and 6. VLAN support for FDB/MDB is patches 7-11. Patch 12 is still additional egress policy. * Slight simplification to code that extracts the VID from skb. Since we now depend on the vlan module, at the time of input skb_tci is

This is based on an earlier patch from Eric Biederman adding forwarding between macvlans. I extended his approach to allow the administrator to choose the mode for each macvlan, and to implement a functional VEPA between macvlan. Still missing from this is support for communication between the lower device that the macvlans are based on. This would be extremely useful but as others have found out