search for: br_dev_xmit

...t(skb->dev), br_dev_queue_push_xmit); + realoutdev, br_dev_queue_push_xmit); return NF_STOLEN; } @@ -535,8 +614,8 @@ static unsigned int ipv4_sabotage_in(uns const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *)) { - if (in->hard_start_xmit == br_dev_xmit && - okfn != br_nf_pre_routing_finish) { + if ((*pskb)->nf_bridge && + !((*pskb)->nf_bridge->mask & BRNF_NF_BRIDGE_PREROUTING)) { okfn(*pskb); return NF_STOLEN; } @@ -552,10 +631,15 @@ static unsigned int ipv4_sabotage_out(un const struct net_device...

...um when feature > is disabled. Disadvantage is that overhead is higher when feature is > enabled. > > WDYT? Looks good to me. I think you would only need to set/add the extension when l2_miss is true, right? (with no extension l2 hit is assumed). That will avoid unneeded overhead for br_dev_xmit(). All the others involved paths look like slow(er) one, so the occasional skb extension overhead should not be a problem. Cheers, Paolo

Hi, I have 2 servers which are connected to a gateway machine. The gateway and one server are running Linux 2.6.16.2, while the third machine is running 2.6.16.5. The two ethernet ports on the gateway which are connected to the servers are combined into a single ethernet bridge device. Ever since 2.6.16, I have noticed that I can no longer cross-mount the two servers' /home directories via

...-ENOMEM; } void __exit br_fdb_fini(void) Index: 2.6-mm/net/bridge/br_private.h =================================================================== --- 2.6-mm.orig/net/bridge/br_private.h +++ 2.6-mm/net/bridge/br_private.h @@ -133,7 +133,7 @@ extern void br_dev_setup(struct net_devi extern int br_dev_xmit(struct sk_buff *skb, struct net_device *dev); /* br_fdb.c */ -extern void br_fdb_init(void); +extern int br_fdb_init(void); extern void br_fdb_fini(void); extern void br_fdb_changeaddr(struct net_bridge_port *p, const unsigned char *newaddr);

...ot;br_private.h" @@ -44,7 +45,7 @@ struct net_bridge_port *p; struct net_bridge_port **pptr; - if ((p = dev->br_port) == NULL) + if ((p = dev->br_port) == NULL || p->br != br) return -EINVAL; br_stp_disable_port(p); @@ -231,6 +232,9 @@ if (dev->hard_start_xmit == br_dev_xmit) return -ELOOP; + + if (!is_valid_ether_addr(dev->dev_addr)) + return -EADDRNOTAVAIL; dev_hold(dev); write_lock_bh(&br->lock);

Using a Linux bridge I see that none of the interfaces is set to promiscuous mode but on the other hand I don't see any dev_unicast_xxx calls in the bridge code... for the case of one of the interfaces being a physical NIC (e.g eth1), what's the magic that makes the NIC RX filtering be willing to accept frames whos dest mac isn't the NIC "primary" unicast mac? Also is there

Tom Eastep wrote: > | Have you applied the ipsec+netfilter patches ? Without them, packets > are > | only seen encrypted in the OUTPUT chain. > | > Yes -- the ipsec+netfilter patches are applied. Here is the same test > with the bridge removed and the local ip address transfered to one of > the network cards: The problem is ipv4_sabotage_out in the briding code. It

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

...ly found. And additionally the wmem_alloc is available per socket, not per ether device, so that different protocols don't run into a cumulative traffic barrier. Fix. Should we agree that the observed behaviour should indeed be amended, i propose the following fix: in br_device.c, function br_dev_xmit() (or __br_dev_xmit() in 2.4): skb_orphan() the sk_buff to be delivered before handing it to the clone loop in br_flood_deliver(), calling br_flood(). skb_orphan() disassociates the sk_buff from its owning socket and runs the "destructor" attached to the sk_buff, which restores the wmem_...

...en you're bridging packets received in an interrupt while > you were deep in journalling code, and it's also been seen with a call > trace something like nfs->sunrpc->ip->bridge->br_netfilter. Sounds like an argument for interrupt stacks. > One option might be to make br_dev_xmit() just queue the packet rather > than trying to deliver it to all the slave devices immediately. Then the > actual retransmission can be handled from a context where we're _not_ > short of stack; perhaps from a dedicated kernel thread. Probably the solution would be to handle it in t...

...gs[3]); -} - static struct net_device_stats *br_dev_get_stats(struct net_device *dev) { struct net_bridge *br; @@ -115,7 +100,7 @@ ether_setup(dev); - dev->do_ioctl = br_dev_do_ioctl; + dev->do_ioctl = br_dev_ioctl; dev->get_stats = br_dev_get_stats; dev->hard_start_xmit = br_dev_xmit; dev->open = br_dev_open; diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c 2004-05-20 10:51:05 -07:00 +++ b/net/bridge/br_if.c 2004-05-20 10:51:05 -07:00 @@ -309,34 +309,6 @@ return 0; } -int br_get_bridge_ifindices(int *indices, int num) -{ - struct net_device...

On Fri, May 19, 2023 at 02:52:18PM -0700, Jakub Kicinski wrote: > On Fri, 19 May 2023 16:51:48 +0300 Ido Schimmel wrote: > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > > index fc17b9fd93e6..274e55455b15 100644 > > --- a/net/bridge/br_input.c > > +++ b/net/bridge/br_input.c > > @@ -46,6 +46,8 @@ static int br_pass_frame_up(struct sk_buff *skb) >

...forward packets according to their IEEE 802.1Q headers. + + If unsure, say N. + Index: wireless-dev/net/bridge/br_device.c =================================================================== --- wireless-dev.orig/net/bridge/br_device.c +++ wireless-dev/net/bridge/br_device.c @@ -34,6 +34,9 @@ int br_dev_xmit(struct sk_buff *skb, str const unsigned char *dest = skb->data; struct net_bridge_fdb_entry *dst; + if (br_vlan_input_frame(skb, &br->vlan)) + return 0; + br->statistics.tx_packets++; br->statistics.tx_bytes += skb->len;

...++++++++++++++---------- net/bridge/br_private.h | 47 +++++-- 5 files changed, 313 insertions(+), 90 deletions(-) diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c index 69363bd..89659d4 100644 --- a/net/bridge/br_device.c +++ b/net/bridge/br_device.c @@ -71,7 +71,7 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev) mdst = br_mdb_get(br, skb, vid); if ((mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) && - br_multicast_querier_exists(br)) + br_multicast_querier_exists(br, eth_hdr(skb))) br_multicast_deliver(mdst, skb); else br_flood_d...

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

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

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