search for: __br_fdb_get

.../net/bridge/br_device.c --- a/net/bridge/br_device.c 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_device.c 2004-07-28 15:30:04 -07:00 @@ -43,10 +43,9 @@ rcu_read_lock(); if (dest[0] & 1) br_flood_deliver(br, skb, 0); - else if ((dst = br_fdb_get(br, dest)) != NULL) { + else if ((dst = __br_fdb_get(br, dest)) != NULL) br_deliver(dst->dst, skb); - br_fdb_put(dst); - } else + else br_flood_deliver(br, skb, 0); rcu_read_unlock(); diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_fdb.c 2004-07-28 15:30:04 -...

...to box 2, lots of packages lost. Ping from box 2 to box 1 does not has this problem. After we tracing the code, we noticed that the box try to using wifi to send the packages which is in blocking mode. This happens because the ath0 is returned from the forwarding database. It's implemented in __br_fdb_get(br, dest). >From the etherreal, I noticed, that the STP package is broadcast from the box 2. From the function br_handle_frame(), if a stp package is received, it will update the forwarding database. Since the STP package is sent/received by both interfaces, the wifi (blocking) received the pa...

...c 2006-07-04 17:26:36.000000000 +0200 @@ -40,12 +40,16 @@ skb->mac.raw = skb->data; skb_pull(skb, ETH_HLEN); - if (dest[0] & 1) + + if (dest[0] & 1) { + skb_orphan(skb); br_flood_deliver(br, skb, 0); - else if ((dst = __br_fdb_get(br, dest)) != NULL) + } else if ((dst = __br_fdb_get(br, dest)) != NULL) { br_deliver(dst->dst, skb); - else + } else { + skb_orphan(skb); br_flood_deliver(br, skb, 0); + } return 0; }

...8 *newaddr) if (!pv) return; - for (vid = find_next_bit(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN, vid); - vid < BR_VLAN_BITMAP_LEN; - vid = find_next_bit(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN, vid+1)) { + for_each_set_bit_from(vid, pv->vlan_bitmap, BR_VLAN_BITMAP_LEN) { f = __br_fdb_get(br, br->dev->dev_addr, vid); if (f && f->is_local && !f->dst) fdb_delete(br, f);

...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.ko u32_classify 125089 af_packet...

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

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

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