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

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

[Christoph Scholz]

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

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

[Matthias Thomae]

Hi Christoph, Marcel, all,

Christoph Scholz wrote:
>>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.

You are right, setting ageing 0 doesn't help.

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

2.6.6 (-mh1) didn't help either...

> 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 also tried the patch that Diego Liziero mentioned in his post, but it 
didn't help either...

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

I don't have a competent opinion about that (except: it's not only the 
forwarding problem, but also DHCP, right?), and don't know what Affix does.

Marcel, what do you think? Is there any sense to contact the bridge people?

Regards.
Matthias

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

[David Woodhouse]

On Fri, 2004-05-14 at 10:18 +0200, Matthias Thomae wrote:
> > 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.
> 
> I don't have a competent opinion about that (except: it's not only the 
> forwarding problem, but also DHCP, right?), and don't know what Affix does.

I don't think it makes sense to do the bridging in our BNEP code. We
already _have_ bridging code in the kernel, and there's no sense in
duplicating it. Using the existing code allows us to do things like
bridging directly onto real Ethernet, too.

> Marcel, what do you think? Is there any sense to contact the bridge people?

The mail at http://lists.osdl.org/pipermail/bridge/2004-May/000321.html
to which Diego referred was from the 'bridge people', and says:

"The bridge code was being to picky. The bridge will still work fine
when there are two interfaces with the same local address, because it is
only used for setting the source address on the outgoing bridge
packets."

It seems that we can read 'should still work fine' instead of 'will
still work fine' in the above, given your report -- so yes, you should
report it as a bug in the bridging code if you still can't get it to
work on 2.6.6 + Stephen's patch.

-- 
dwmw2