[PATCH] bridge: forwarding table information for >256 devices

The forwarding table binary interface (my bad choice), only exposes the
port number of the first 8 bits. The bridge code was limited to 256 ports
at the time, but now the kernel supports up 1024 ports, so the upper bits
are lost when doing:
   brctl showmacs

The fix is to squeeze the extra bits into small hole left in data structure,
to maintain binary compatiablity.

Signed-off-by: Stephen Hemminger <shemminger <at> vyatta.com>

--- a/include/linux/if_bridge.h	2008-04-28 15:27:05.000000000 -0700
+++ b/include/linux/if_bridge.h	2008-04-28 15:31:38.000000000 -0700
 <at>  <at>  -97,7 +97,9  <at>  <at>  struct __fdb_entry
 	__u8 port_no;
 	__u8 is_local;
 	__u32 ageing_timer_value;
-	__u32 unused;
+	__u8 port_hi;
+	__u8 pad0;
+	__u16 unused;
 };

 #ifdef __KERNEL__
--- a/net/bridge/br_fdb.c	2008-04-28 15:27:05.000000000 -0700
+++ b/net/bridge/br_fdb.c	2008-04-28 15:31:38.000000000 -0700
 <at>  <at>  -285,7 +285,11  <at>  <at>  int br_fdb_fillbuf(struct net_bridge *br

 			/* convert from internal format to API */
 			memcpy(fe->mac_addr, f->addr.addr, ETH_ALEN);

Re: [RFA, PATCH] enable transition to sysfs-only bridge manipulation

On Fri, 2 May 2008 11:01:38 +0200
Bernhard Fischer <rep.dot.nop <at> gmail.com> wrote:

> Hi,
> 
> It was rumored that the ioctl interface for bridges is deprecated.
> There is, however, one crucial gap when trying to implement brctl
> without using any ioctl: AFAICS it is impossible to create a bridge via
> sysfs.
> 
> The attached quick.. erm patch strives to fill this gap.
> Some further details are at the top of the patchlet which received only
> cursory testing, fwiw.
> 
> Thanks and cheers,
> Bernhard

Why bother. The old API has to live on because it part of the
kernel ABI.

[RFA, PATCH] enable transition to sysfs-only bridge manipulation

Hi,

It was rumored that the ioctl interface for bridges is deprecated.
There is, however, one crucial gap when trying to implement brctl
without using any ioctl: AFAICS it is impossible to create a bridge via
sysfs.

The attached quick.. erm patch strives to fill this gap.
Some further details are at the top of the patchlet which received only
cursory testing, fwiw.

Thanks and cheers,
Bernhard

_______________________________________________
Bridge mailing list
Bridge <at> lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bridge

Re: Ethernet+Wireless Bridge?

John W. Linville a écrit :
> 
> Spoofing the source MAC is actually forbidden by the 802.11 standard.

My two cents :

We all agree about the fact that most current wireless implementations 
do not permit spoofing the source MAC, probably for many good and 
several bad reasons.

But wouldn't it be possible, as a temporary and dirty fix, to simply 
send any outgoing frames with the wireless interface MAC as the source 
MAC when the bridge send on a wireless interface ?

Of course, this breaks the bridge transparency principle and might cause 
serious problem with BPDU, but on a simple (or simpler) configuration, 
without STP, this might work well for most level 3+ services. For 
example, an ARP answer can come for a different source MAC than the one 
stated in the ARP payload. So ARP should work well, even if the source 
MAC might look strange for someone having a close look at the frame.

Also, the bridge global MAC (of br0) might be forced to the MAC of the 
wireless interface if there is only a single wireless interface in the 
bridge, probably causing BPDU to work well too.

This is only theoretical and - I admit - a very dirty fix into the 
bridge code, but... better than noting. And by the way, may be this can 
be setup using ebtable, which is cleaner !

Any comments ?

Re: [RFA, PATCH] enable transition to sysfs-only bridge manipulation

On Fri, May 02, 2008 at 08:17:46AM -0700, Stephen Hemminger wrote:
>On Fri, 2 May 2008 11:01:38 +0200
>Bernhard Fischer <rep.dot.nop <at> gmail.com> wrote:
>
>> Hi,
>> 
>> It was rumored that the ioctl interface for bridges is deprecated.
>> There is, however, one crucial gap when trying to implement brctl
>> without using any ioctl: AFAICS it is impossible to create a bridge via
>> sysfs.
>> 
>> The attached quick.. erm patch strives to fill this gap.
>> Some further details are at the top of the patchlet which received only
>> cursory testing, fwiw.
>> 
>> Thanks and cheers,
>> Bernhard
>
>Why bother. The old API has to live on because it part of the
>kernel ABI.

I'm bothering since i either want the ioctl interface _or_ the sysfs
interface. I currently use the ioctl interface but as long as the sysfs
is incomplete i cannot switch to it even if i wanted.

Re: Ethernet+Wireless Bridge?

On Fri, May 02, 2008 at 02:04:27PM +0200, Nicolas wrote:
> John W. Linville a écrit :
> > 
> > Spoofing the source MAC is actually forbidden by the 802.11 standard.

> But wouldn't it be possible, as a temporary and dirty fix, to simply 
> send any outgoing frames with the wireless interface MAC as the source 
> MAC when the bridge send on a wireless interface ?

Having given this almost no thought, I suppose it might be possible to
make it 'work' (for some definition of 'work'), in combination with
routing and proxy ARP.  Of course if you are going to route anyway,
it is hard to see why you would need to bridge.

John
--

-- 
John W. Linville
linville <at> tuxdriver.com

Re: [PATCH] bridge: forwarding table information for >256 devices

From: Stephen Hemminger <shemminger <at> vyatta.com>
Date: Thu, 1 May 2008 13:42:09 -0700

> The forwarding table binary interface (my bad choice), only exposes the
> port number of the first 8 bits. The bridge code was limited to 256 ports
> at the time, but now the kernel supports up 1024 ports, so the upper bits
> are lost when doing:
>    brctl showmacs
> 
> The fix is to squeeze the extra bits into small hole left in data structure,
> to maintain binary compatiablity.
> 
> Signed-off-by: Stephen Hemminger <shemminger <at> vyatta.com>

At least you had somewhere to stick the high bits :)

Applied, thanks.

Re: Preventing packet reassembly

In gmane.linux.network.bridge, you wrote:
> I have iptables rules on the management interface of the box, but not on
> any of the ports which participate in bridging.
> By removing iptables from my bootup, I get a properly functioning
> bridge.
>
> Why would iptables rules on one interface affect traffic bridged on
> other interfaces? I'm presuming it's some kind of interaction with the
> ip_conntrack module? Any way to stop it from loading?

You might find the iptables NOTRACK target helpful.

Jason

Re: Preventing packet reassembly

Leigh Sharpe wrote:
> I have iptables rules on the management interface of the box, but not on
> any of the ports which participate in bridging.
> By removing iptables from my bootup, I get a properly functioning
> bridge.

Connection tracking performs defragmentation for all packets,
independant of the ruleset. For briding the packets should get
re-fragmented when leaving the bridge device though.

Please try "iptables -t raw -I PREROUTING -i <br-dev> -j TRACE",

load the ipt_LOG module and post the output.

STP bug, loop not detetcted

Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
eth1.4, attached and the builtin STP enabled. eth1 is connected to
a "switch" with 4 real interfaces, each real interface maps to one of
the above mentioned VLANs.  

If I loop two or more interfaces by connecting each interface's output
to its own input, I get a loop that STP doesn't detect.
Looping by connecting an output from one interface to another interface
input works fine.

Bug or limitation in STP? If limitation, would RSTP help here?

Kernel 2.6.25

 Jocke