7 Jul
2012
7 Jul
'12
3:37 a.m.
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.
http://pastebin.com/7DDUaXu1
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
8 Jul
8 Jul
10:09 a.m.
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.
http://pastebin.com/7DDUaXu1
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
23 Jul
23 Jul
7:20 a.m.
On Sun, Jul 8, 2012 at 7:09 AM, Simon Wunderlich
<simon.wunderlich(a)s2003.tu-chemnitz.de> wrote:
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
Hey Guido,
On Sat, Jul 07, 2012 at 12:37:24AM -0300, Guido Iribarren wrote:
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)
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.
http://pastebin.com/7DDUaXu1
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?
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.
25 Jul
25 Jul
8:34 p.m.
Hey Gui,
On Mon, Jul 23, 2012 at 04:20:39AM -0300, Gui Iribarren wrote:
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 Sun, Jul 8, 2012 at 7:09 AM, Simon Wunderlich
<simon.wunderlich(a)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.
http://pastebin.com/7DDUaXu1
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. 
9:11 p.m.
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:
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 Sun, Jul 8, 2012 at 7:09 AM, Simon Wunderlich
<simon.wunderlich(a)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.
http://pastebin.com/7DDUaXu1
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. 
10:04 p.m.
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
10:16 p.m.
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
28 Jul
28 Jul
6:34 p.m.
On Wed, Jul 25, 2012 at 5:34 PM, Simon Wunderlich
<simon.wunderlich(a)s2003.tu-chemnitz.de> wrote:
Hey Gui,
Exactly.
With a caveat: turns out adding plain eth0 (no vlans involved) works
fine as expected, the problem arises when using vlans.
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 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.
http://pastebin.com/y1JwMaDM
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!
30 Jul
30 Jul
10:31 a.m.
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
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
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.
http://pastebin.com/y1JwMaDM
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.
13 Sep
13 Sep
4:10 p.m.
On Mon, Jul 30, 2012 at 7:31 AM, Simon Wunderlich
<simon.wunderlich(a)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
3847
days inactive
3915
days old
b.a.t.m.a.n@lists.open-mesh.org
9 comments
5 participants
participants (5)
-
Gioacchino Mazzurco -
Gui Iribarren -
Guido Iribarren -
Simon Wunderlich -
Sven Eckelmann