similar to: [Bridge] Information needed about bridge c code

Hi, i am testing two bridges by sending to it random packets using hping2. First i create a random-length file, then i send it a lot of time on the wire using this command: for ($i=0; $i<50000; $i++) { hping2 -q -c 1 -d $data_len -E random.file 10.0.0.10 } My problem is that some packets are lost. Here is my setup: PC1 (10.0.0.1) ===== BR1 --------- BR2 ===== PC2 (10.0.0.10)

This hook is protected with the RCU, so simple if (br_should_route_hook) br_should_route_hook(...) is not enough on some architectures. Use the rcu_dereference/rcu_assign_pointer in this case. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c index 3cedd4e..b42b192 100644 --- a/net/bridge/br_input.c +++

On Thu, May 18, 2023 at 07:08:47PM +0300, Nikolay Aleksandrov wrote: > On 18/05/2023 14:33, Ido Schimmel wrote: > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > > index fc17b9fd93e6..d8ab5890cbe6 100644 > > --- a/net/bridge/br_input.c > > +++ b/net/bridge/br_input.c > > @@ -334,6 +334,7 @@ static rx_handler_result_t br_handle_frame(struct sk_buff

I have a bridge that has gigabit interfaces. The machine in question has the fun job of being a Bridge, Firewall and SMB server. Both of the Gigabit interfaces are connected to workstations directly via Xover cable (well MDI-X to be exact). My question is, if I enable jumbo frames on the gigabit interfaces will that make any difference in overall transfer rate of the bridge? I was thinking it

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

Hi, I believe ndas devices (http://www.ximeta.com/web/technology/) use raw Ethernet frames, as they require no tcp/ip configuration, the client finds and authenticates with a code that is different for each device sold, like a network mac address. My pc is on a different segment to the ndas devices that we have, the two segments are linked by a linux box that is doing routing and proxy arp, can

Hi, I had successfully setup my bridge (br0) but after few minutes the br0 interface seems not working. ifconfig eth0 0.0.0.0 ifconfig eth5 0.0.0.0 brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth5 brctl stp br0 on I check on my system's /var/log/syslog file. It shows something strange messages as below: - Jan 2 10:44:22 fw01 kernel: ipt_tcpmss_target: bad length (64 bytes)

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

Hi there, I'm currently experiencing a minor problem using the bridge module under kernel 2.4.27 part of the Devil Linux distribution (http://www.devil-linux.org). The problem I am having is that when the bridge is unloaded during a reboot I receive the following errors in /var/log/messages: Nov 14 13:22:13 src@Devil kernel: unregister_netdevice: waiting for br0 to become free. Usage count =

Hi, I am configuring some servers in a high availability setup. The servers are connected to two switches with two LAN cards in each server. The two switches are connected directly to each other. The servers are configured to bridge eth0 and eth1 with spanning tree. Usually this makes sure eth1 is disabled, unless something happens to eth0. This way I can have one IP address on each server. Now

Hello! I have the following setup: 1) a connection to my ISP with a public IP (1.2.3.4) with the gateway 1.2.3.1 2) an allocated IP class with 64 addresses (5.6.7.192/26) 3) two LANs connected through two NICs: a) 192.168.0.0/24 on eth1 (192.168.0.1) b) 10.0.0.0/24 on eth2 (10.0.0.1) The IPs from the allocated class are all assigned to eth0. The networks are SNATed to the external IP and

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

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 ------- Additional Comments From scrizt@ludd.ltu.se 2006-06-26 17:57 MET ------- Is this bug forgotten ? Anyhow, I ran into it when setting up this strange network of mine.. I dont think my setup is causing anything strange however.. It appears even if no machine is connected to the "inner" port of the bridge.. I

I have noticed a change in the linux bridge implementation between 2.1.15 and 2.1.17. Specifically, I do not think BPDU's (generated from another bridge) are passed across the bridge when STP is disabled. I think this relates to the LLC handling of BPDU's directly invoking br_bpdu_rcv. In 2.6.15, the br_handle_frame function would pass a BPDU to the br_handle_frame_finish function

I have used shorewall in the past and loved it. However, at the time it did not support brouting and because of that I had to remove it for a faster solution. Now that faster solution is failing and I want to go back to what I liked. I have never set up a brouter but I have been doing a lot of reading on it, both on your site and many others. I all cases what I see is a brouter/firewall

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, 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) >

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) > */ > br_switchdev_frame_unmark(skb); > > + skb->l2_miss

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