On Wed, Jul 25, 2012 at 5:34 PM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hey Gui,
Funny thing is, the only workaround i found for the bug is to *include* the interface in a bridge, and add that bridge to bat0 as in: brctl delif br-lan eth0 batctl if add eth0 # doesn't work
brctl delif br-lan eth0 brctl addbr blah brctl addif blah eth0 batctl if add blah # works fine, OGMs pass through perfectly
OK, so you say that it doesn't work when you simply add eth0 batctl, but it works with the bridge?
Exactly. With a caveat: turns out adding plain eth0 (no vlans involved) works fine as expected, the problem arises when using vlans.
What is the minimal setup which is not working, two routers and one cable?
I just reproduced it minimally: two routers, one cable, no adhoc, no bla2, no gw_mode, identical setup in both routers. enabling bla2 makes no difference.
A=f8:d1:11:54:50:f9 B=f8:d1:11:3b:78:df
"A" batctl td shows incoming OGMs from neighbour "B", but batctl ll doesn't react.
viceversa for "B".
ping6 works fine over eth0.2 between A and B
adding a simple "option type 'bridge'" on both routers solves the OGM issue, like so:
config interface 'eth0_2' option type 'bridge' option ifname 'eth0.2' option proto 'none' option mtu '1528'
with this, eth0.2 is included in br-eth0_2, and bat0 manages br-eth0_2... OGMs do come through correctly, and "batctl o" shows neighbour on both sides.
all in all, workaround is not complicated (in fact a one-liner) but i find it curious that without the bridge thingy, batctl td catches the OGMs, yet batman doesn't recognize them. I haven't tinkered with vlans before, so i might be misunderstanding how they should work.
I'm sorry but you lost me somewhere, would be nice to get the smallest reproducable setup. :)
Sorry for the intrincate descriptions, HTH!