Forgot to also reply to the mailing list.
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
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.
>><[email protected]>
>> [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