Hello again nice folks, I updated today another segment of the network with just 4 nodes, to batman-adv 2012.2 (the one i compiled yesterday with simon patches for blaII, marek stability fixes, and debug log enabled , yikes!) and i couldn't get batman to work over wired ethernet?? (?)
P -(50mts wlan)- D -----(ubnt transparent bridge) 2km -- C ----eth-------------------/
Node P and D connected by ethernet on eth0 but close enough that could also see each other through adhoc wlan, with bla enabled, correctly preferred ethernet connection to communicate between them (iperf yielded 92mbps), so far so good. now, node D and C, too far away from each other to communicate over wlan, but connected by a "loooong eth cable" (mediated by a wds transparent bridge) wouldn't find each other batman originator. C originator table was empty, and D only showed P. I thought the transparent bridge was misbehaving, so I tried in a simpler setup using P and D, with the wifi off: but after disabling wlan0 (batctl if del wlan0-2) and adding eth0 (batctl if add eth0) on both nodes, batman could not see each other anymore :( i thought i was doing something wrong, so i tried in different ways, but could not get it to work. batctl td eth0 shows both outgoing OGMs from local , and incoming OGMs from remote, but batctl l only reported outgoing OGMs.
diego is local node ("D"), palmeras is on the other side of the ethernet cable ("P") (and jure is further away, connected to palmeras by adhoc wlan, not illustrated in the previous ascii art)
i hope i'm overlooking something really obvious?
Have a nice weekend!
Gui
Hey Guido,
On Sat, Jul 07, 2012 at 12:37:24AM -0300, Guido Iribarren wrote:
Hello again nice folks, I updated today another segment of the network with just 4 nodes, to batman-adv 2012.2 (the one i compiled yesterday with simon patches for blaII, marek stability fixes, and debug log enabled , yikes!) and i couldn't get batman to work over wired ethernet?? (?)
P -(50mts wlan)- D -----(ubnt transparent bridge) 2km -- C ----eth-------------------/
Node P and D connected by ethernet on eth0 but close enough that could also see each other through adhoc wlan, with bla enabled, correctly preferred ethernet connection to communicate between them (iperf yielded 92mbps), so far so good.
As seen on the dump, you only use eth0 in batman? Is the Ad-Hoc connection still active (on wlan0 or wlan-1)?
now, node D and C, too far away from each other to communicate over wlan, but connected by a "loooong eth cable" (mediated by a wds transparent bridge) wouldn't find each other batman originator. C originator table was empty, and D only showed P. I thought the transparent bridge was misbehaving, so I tried in a simpler setup using P and D, with the wifi off: but after disabling wlan0 (batctl if del wlan0-2) and adding eth0 (batctl if add eth0) on both nodes, batman could not see each other anymore :( i thought i was doing something wrong, so i tried in different ways, but could not get it to work. batctl td eth0 shows both outgoing OGMs from local , and incoming OGMs from remote, but batctl l only reported outgoing OGMs.
Mhm, that's weird indeed. Is eth0 really not included in any other bridge? It looks like the incoming packets don't reach BATMAN for some reason.
Also have you checked that the WDS bridge works via IP? You could first set up some IP addresses and ping each other, confirm traffic with tcpdump, and then activate batman-adv to see if the OGMs go through. So far, it doesn't seem like anything from your C node comes through at all.
Cheers, Simon
On Sun, Jul 8, 2012 at 7:09 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hey Guido,
On Sat, Jul 07, 2012 at 12:37:24AM -0300, Guido Iribarren wrote:
Hello again nice folks, I updated today another segment of the network with just 4 nodes, to batman-adv 2012.2 (the one i compiled yesterday with simon patches for blaII, marek stability fixes, and debug log enabled , yikes!) and i couldn't get batman to work over wired ethernet?? (?)
P -(50mts wlan)- D -----(ubnt transparent bridge) 2km -- C ----eth-------------------/
Node P and D connected by ethernet on eth0 but close enough that could also see each other through adhoc wlan, with bla enabled, correctly preferred ethernet connection to communicate between them (iperf yielded 92mbps), so far so good.
As seen on the dump, you only use eth0 in batman? Is the Ad-Hoc connection still active (on wlan0 or wlan-1)?
For this initial setup, i didn't add eth0 to batman, only ad-hoc interfaces, classic setup. representation: http://www.open-mesh.org/attachments/download/131 works as expected.
When it doesn't work is when the ad-hoc connection is severed. which makes the thing look like http://www.open-mesh.org/attachments/download/128 that is, there are two gateways that can only talk to each other through ethernet (although it's not "batctl if add"ed) don't get each other OGMs after careful re-reading of BLAII docs in the wiki, and extensive chats with NicoEchaniz, i understood this is the planned behaviour (no OGMs on lan)
now, node D and C, too far away from each other to communicate over wlan, but connected by a "loooong eth cable" (mediated by a wds transparent bridge) wouldn't find each other batman originator. C originator table was empty, and D only showed P. I thought the transparent bridge was misbehaving, so I tried in a simpler setup using P and D, with the wifi off: but after disabling wlan0 (batctl if del wlan0-2) and adding eth0 (batctl if add eth0) on both nodes, batman could not see each other anymore :( i thought i was doing something wrong, so i tried in different ways, but could not get it to work. batctl td eth0 shows both outgoing OGMs from local , and incoming OGMs from remote, but batctl l only reported outgoing OGMs.
Mhm, that's weird indeed. Is eth0 really not included in any other bridge? It looks like the incoming packets don't reach BATMAN for some reason.
Definitely not included in any bridge. 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
Also have you checked that the WDS bridge works via IP?
As I wasn't confident about the WDS bridge, I simply tried with two routers connected by a single physical ethernet cable. So the results reported didn't include a WDS bridge at all.
You could first set up some IP addresses and ping each other, confirm traffic with tcpdump, and then activate batman-adv to see if the OGMs go through.
Confirmed.
Hey Gui,
On Mon, Jul 23, 2012 at 04:20:39AM -0300, Gui Iribarren wrote:
On Sun, Jul 8, 2012 at 7:09 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote: [..]
When it doesn't work is when the ad-hoc connection is severed. which makes the thing look like http://www.open-mesh.org/attachments/download/128 that is, there are two gateways that can only talk to each other through ethernet (although it's not "batctl if add"ed) don't get each other OGMs after careful re-reading of BLAII docs in the wiki, and extensive chats with NicoEchaniz, i understood this is the planned behaviour (no OGMs on lan)
Yes, that is expected behaviour. We don't want OGMs on the LAN, there were issues with some more "intelligent" switches which regarded OGMs as threat to the network. :)
OGMs are only sent on interfaces added with "batctl if add", and nowhere else.
now, node D and C, too far away from each other to communicate over wlan, but connected by a "loooong eth cable" (mediated by a wds transparent bridge) wouldn't find each other batman originator. C originator table was empty, and D only showed P. I thought the transparent bridge was misbehaving, so I tried in a simpler setup using P and D, with the wifi off: but after disabling wlan0 (batctl if del wlan0-2) and adding eth0 (batctl if add eth0) on both nodes, batman could not see each other anymore :( i thought i was doing something wrong, so i tried in different ways, but could not get it to work. batctl td eth0 shows both outgoing OGMs from local , and incoming OGMs from remote, but batctl l only reported outgoing OGMs.
Mhm, that's weird indeed. Is eth0 really not included in any other bridge? It looks like the incoming packets don't reach BATMAN for some reason.
Definitely not included in any bridge. 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? What is the minimal setup which is not working, two routers and one cable?
I'm sorry but you lost me somewhere, would be nice to get the smallest reproducable setup. :)
Cheers and thanks, Simon
I have not followed the whole thread but i got scared from this reply
I hope I misunderstood
if i do on newer version of batman
$batctl if add eth0
what happen batman will use this interface to do "mesh" or will simply ignore it because it is ethernet?
On 07/25/12 22:34, Simon Wunderlich wrote:
Hey Gui,
On Mon, Jul 23, 2012 at 04:20:39AM -0300, Gui Iribarren wrote:
On Sun, Jul 8, 2012 at 7:09 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote: [..]
When it doesn't work is when the ad-hoc connection is severed. which makes the thing look like http://www.open-mesh.org/attachments/download/128 that is, there are two gateways that can only talk to each other through ethernet (although it's not "batctl if add"ed) don't get each other OGMs after careful re-reading of BLAII docs in the wiki, and extensive chats with NicoEchaniz, i understood this is the planned behaviour (no OGMs on lan)
Yes, that is expected behaviour. We don't want OGMs on the LAN, there were issues with some more "intelligent" switches which regarded OGMs as threat to the network. :)
OGMs are only sent on interfaces added with "batctl if add", and nowhere else.
now, node D and C, too far away from each other to communicate over wlan, but connected by a "loooong eth cable" (mediated by a wds transparent bridge) wouldn't find each other batman originator. C originator table was empty, and D only showed P. I thought the transparent bridge was misbehaving, so I tried in a simpler setup using P and D, with the wifi off: but after disabling wlan0 (batctl if del wlan0-2) and adding eth0 (batctl if add eth0) on both nodes, batman could not see each other anymore :( i thought i was doing something wrong, so i tried in different ways, but could not get it to work. batctl td eth0 shows both outgoing OGMs from local , and incoming OGMs from remote, but batctl l only reported outgoing OGMs.
Mhm, that's weird indeed. Is eth0 really not included in any other bridge? It looks like the incoming packets don't reach BATMAN for some reason.
Definitely not included in any bridge. 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? What is the minimal setup which is not working, two routers and one cable?
I'm sorry but you lost me somewhere, would be nice to get the smallest reproducable setup. :)
Cheers and thanks, Simon
On Wed, Jul 25, 2012 at 11:11:30PM +0200, Gioacchino Mazzurco wrote:
I have not followed the whole thread but i got scared from this reply
I hope I misunderstood
if i do on newer version of batman
$batctl if add eth0
what happen batman will use this interface to do "mesh" or will simply ignore it because it is ethernet?
It will be used by batman-adv as mesh interface because you explicitly said that you want to use it. This is what Gui wrote. Simon only said that this is the expected behaviour.
Kind regards, Sven
thanks for reassuring
On 07/26/12 00:04, Sven Eckelmann wrote:
On Wed, Jul 25, 2012 at 11:11:30PM +0200, Gioacchino Mazzurco wrote:
I have not followed the whole thread but i got scared from this reply
I hope I misunderstood
if i do on newer version of batman
$batctl if add eth0
what happen batman will use this interface to do "mesh" or will simply ignore it because it is ethernet?
It will be used by batman-adv as mesh interface because you explicitly said that you want to use it. This is what Gui wrote. Simon only said that this is the expected behaviour.
Kind regards, Sven
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!
Hello Guido,
On Sat, Jul 28, 2012 at 03:34:29PM -0300, Gui Iribarren wrote:
On Wed, Jul 25, 2012 at 5:34 PM, Simon Wunderlich
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.
Thanks for working that out. I've just tried out VLANs on Ethernet with BATMAN myself, and it worked well here - so I can't reproduce it by simply using VLANs.
Another cause of the fault may be the VLAN stuff in OpenWRT, as this is not a "real" VLAN but just a way to address the ports on your box. I have not much experience with that, but I've heard funny things about it. ;) Have you tried changing the VLAN config? E.g. changing ports '0t 2t' for eth0.2 to '0t 2' (to remove tagging)?
Do you have the same problem on other types of devices? (Maybe the internal switch is acting weird)
Maybe some else has more experience on Switch/VLAN-config than me and can have a look at that config. :) http://pastebin.com/y1JwMaDM
As I said, Ethernet/VLANs work fine for me, and I know other people running batman over Ethernet-VLANs as well ...
Cheers Simon
On Mon, Jul 30, 2012 at 7:31 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hello Guido,
Thanks for working that out. I've just tried out VLANs on Ethernet with BATMAN myself, and it worked well here - so I can't reproduce it by simply using VLANs.
Another cause of the fault may be the VLAN stuff in OpenWRT, as this is not a "real" VLAN but just a way to address the ports on your box. I have not much experience with that, but I've heard funny things about it. ;) Have you tried changing the VLAN config? E.g. changing ports '0t 2t' for eth0.2 to '0t 2' (to remove tagging)?
Do you have the same problem on other types of devices? (Maybe the internal switch is acting weird)
Sorry for necrotizing the thread, but i just wanted to leave a quick note in case anyone else stumps on this.
you were right once again Simon, TP-Link TL-MR3220 (and MR3420) has, in fact, "true" VLAN capability in the hardware switch, but unfortunately that capability has limitations.
notably, it can't send tagged and untagged frames through the same port, and falling back to software tagging doesn't give meaningful results either (switch is broken: packets aren't forwarded between ports)
I just dumped the whole vlan thing altogether on this hardware.
Thanks as always!
Gui
b.a.t.m.a.n@lists.open-mesh.org
-
Gioacchino Mazzurco -
Gui Iribarren -
Guido Iribarren -
Simon Wunderlich -
Sven Eckelmann