search for: br_fdb_update

...=================================== --- bridge.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-...

...ete_by_addr_and_port <--- __br_fdb_delete ? +- br_fdb_external_learn_del ? - fdb_create <-+- fdb_add_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_add_local ? +- br_fdb_update ? +- fdb_add_entry <--- __br_fdb_add ? +- br_fdb_external_learn_add ? The flags that imply an entry does not come from learning (BR_FDB_NOT_LEARNED_MASK) are now only set or cleared under br->hash_lock as well, and when the boolean value of (fdb->flags &amp...

...++++++++++++++++++++++++++++++++++++++ net/bridge/br_sysfs_if.c | 17 +++++++++++ 7 files changed, 154 insertions(+), 2 deletions(-) diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index a48f5ef..7d0f6ed 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -394,6 +394,15 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source, fdb = fdb_find(head, addr); if (likely(fdb)) { + /* + * If we are a VEPA and the source port is the uplink, + * this could be a reflected packet, so don't learn any + * addresses that already are in the fdb but on other ports +...

...++++++++++++++++++++++++++++++++++++++ net/bridge/br_sysfs_if.c | 17 +++++++++++ 7 files changed, 154 insertions(+), 2 deletions(-) diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index a48f5ef..7d0f6ed 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -394,6 +394,15 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source, fdb = fdb_find(head, addr); if (likely(fdb)) { + /* + * If we are a VEPA and the source port is the uplink, + * this could be a reflected packet, so don't learn any + * addresses that already are in the fdb but on other ports +...

...++++++++++++++++++++++++++++++++++++++ net/bridge/br_sysfs_if.c | 17 +++++++++++ 7 files changed, 154 insertions(+), 2 deletions(-) diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index a48f5ef..7d0f6ed 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -394,6 +394,15 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source, fdb = fdb_find(head, addr); if (likely(fdb)) { + /* + * If we are a VEPA and the source port is the uplink, + * this could be a reflected packet, so don't learn any + * addresses that already are in the fdb but on other ports +...

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: -

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

...> + bool learned = !(f->flags & BR_FDB_NOT_LEARNED_MASK); > > *_bit I do not know a *_bit helper that would help me test the intersection of multiple bits on both sides. Do you have any in mind? > > + > > return fdb; > > } > > @@ -894,7 +940,7 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source, > > } > > if (unlikely(test_bit(BR_FDB_ADDED_BY_USER, &flags))) > > - set_bit(BR_FDB_ADDED_BY_USER, &fdb->flags); > > + fdb_set_flag_not_learned(br, fdb, BR_FDB_ADDED_BY_USER); > > Unacc...

...ete_by_addr_and_port <--- __br_fdb_delete ? +- br_fdb_external_learn_del ? - fdb_create <-+- fdb_add_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_add_local ? +- br_fdb_update ? +- fdb_add_entry <--- __br_fdb_add ? +- br_fdb_external_learn_add ? Signed-off-by: Johannes Nixdorf <jnixdorf-oss at avm.de> --- include/uapi/linux/if_link.h | 1 + net/bridge/br_device.c | 2 ++ net/bridge/br_fdb.c | 6 ++++++ net/bridge/...

...p; BR_FDB_NOT_LEARNED_MASK); >> >> *_bit > > I do not know a *_bit helper that would help me test the intersection > of multiple bits on both sides. Do you have any in mind? > >>> + >>> return fdb; >>> } >>> @@ -894,7 +940,7 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source, >>> } >>> if (unlikely(test_bit(BR_FDB_ADDED_BY_USER, &flags))) >>> - set_bit(BR_FDB_ADDED_BY_USER, &fdb->flags); >>> + fdb_set_flag_not_learned(br, fdb, BR_FDB_ADDED_BY_USER); >...

Introduce a limit on the amount of learned FDB entries on a bridge, configured by netlink with a build time default on bridge creation in the kernel config. For backwards compatibility the kernel config default is disabling the limit (0). Without any limit a malicious actor may OOM a kernel by spamming packets with changing MAC addresses on their bridge port, so allow the bridge creator to limit

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

...br_nf_pre_routing 7047 bridge.ko br_nf_post_routing 8158 sky2.ko sky2_xmit_frame 9519 sch_htb.ko htb_classify 9910 sch_htb.ko htb_dequeue 9916 ip_tables.ko ipt_do_table 9944 bridge.ko br_fdb_update 10094 bridge.ko __br_fdb_get 14446 sky2.ko sky2_intr 15323 sky2.ko sky2_tx_complete 17745 ebt_ip.ko ebt_filter_ip 55535 sky2.ko sky2_poll 82377 ebtables.ko ebt_do_table 84971 cls_u32.k...

...--- __br_fdb_delete ? > +- br_fdb_external_learn_del ? > - fdb_create <-+- fdb_add_local <-+- br_fdb_changeaddr ? > | +- br_fdb_change_mac_address ? > | +- br_fdb_add_local ? > +- br_fdb_update ? > +- fdb_add_entry <--- __br_fdb_add ? > +- br_fdb_external_learn_add ? > > Signed-off-by: Johannes Nixdorf <jnixdorf-oss at avm.de> > --- > include/uapi/linux/if_link.h | 1 + > net/bridge/br_device.c | 2 ++ > net/bridge/b...

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