[Fwd: Re: [Bluez-devel] PAN and bridge problem when bnep0 disconnects before bnep1]

[Christoph Scholz <scholz@cs.uni-bonn.de>]

[-- Attachment #1: Type: text/plain, Size: 42 bytes --]

Forgot to also reply to the mailing list.

[-- Attachment #2: Forwarded message - Re: [Bluez-devel] PAN and bridge problem when bnep0 disconnects before bnep1 --]
[-- Type: message/rfc822, Size: 2611 bytes --]

From: Christoph Scholz <scholz@cs.uni-bonn.de>
To: Matthias Thomae <bluez@thomae-privat.de>
Subject: Re: [Bluez-devel] PAN and bridge problem when bnep0 disconnects before bnep1
Date: Thu, 13 May 2004 17:21:43 +0200
Message-ID: <1084461703.2322.27.camel@willie.informatik.uni-bonn.de>

On Thu, 2004-05-13 at 16:09, Matthias Thomae wrote:
> Hi Christoph,
> 
> Christoph Scholz wrote:
> > I experienced the same problem as Matthias Thomae. I already posted this
> 
> Glad there's others with the same problem ;)
> 
> > to the mailing-list some time ago (see attached mail). It is actually a
> 
> Missed your mail although I searched the archives...
> 
> > problem with the Linux bridge code. It does not seem to be able to cope
> > with multiple interfaces using the same MAC-Address.
> 
> Aha. These MAC addresses seem to be used in the forwarding database. 
> Maybe setting the ageing time to 0 (man brctl) would help...

I don't think so. The problem is that the code assumes that MAC
addresses are unique. Even if there are multiple Bluetooth BNEP devices,
there will only be one entry in the forwarding database. When one of the
devices is removed, this entry in the forwarding database is also
removed.

> 
> > Unfortunately, I have no real solution to the problem.
> 
> What kernel version are you using (on the GN)? I noticed in the 
> changelog for 2.6.6 there were a number of bridge-related changes, e.g.:

I used 2.4.x   with x >=20 (don't know exactly any more)

> 
> <shemminger@osdl.org>
> 	[BRIDGE]: Forwarding database changes.
> 	
> 	Make forwarding database more robust.
> 	  + Don't insert invalid ether address,
> 	  + Report errors back so adding an interface to bridge can fail
> 	  + get rid of unneeded explicit pads in data structure
> 	  + replace bitfields with byte's for simple booleans.
> 
> Maybe that fixes our problem? I might be able to try 2.6.6 and the 
> ageing timer tonight...

I am not sure but I would guess that the problem is still there. The
same warning can be found in br_fdb.c in 2.6.6:

printk(KERN_INFO "%s: attempt to add" " interface with same source add
ress.\n", source->dev->name);

I have not written to to the bridge people. My personal opinion is that
BlueZ should do the forwarding (like Affix does). You can argue about
that of course.

Regards,


Christoph