3 Nov
2013
3 Nov
'13
11:12 a.m.
Hi,
in our Freifunk network we are experiencing some kind of strange behaviour if
two routers can see each other by wire and wireless at the same time. Then the
link quality in the originator table drops from normally >250 to somewhat
around 130 or less on both interfaces.
Because we have no idea why this happens but think this is kind of unwanted
behaviour I´m asking here if we did something wrong or if we missed some
configuration in this case.
We are using B.A.T.M.A.N. adv 2013.4.0.
Kind Regards
Clemens John
--
#Clemens John <clemens-john(a)gmx.de>
#GnuPG:
Identifier: 0xD92F6BA5
Fingerprint: 1D6D 3EC6 C80F C1D4 CE1F 1133 6607 476C 0DB6 96A3
4 Nov
4 Nov
10:28 a.m.
Hi,
Hi,
in our Freifunk network we are experiencing some kind of strange behaviour
if two routers can see each other by wire and wireless at the same time.
Then the link quality in the originator table drops from normally >250 to
somewhat around 130 or less on both interfaces.
Because we have no idea why this happens but think this is kind of unwanted
behaviour I´m asking here if we did something wrong or if we missed some
configuration in this case.
this is certainly not the expected behaviour. Are you building a bridge loop
by any chance? Please explain your configuration (batctl if, brctl show, ...)
and check if you have a high amount of broadcasts somehow.
Cheers,
Simon
7 Nov
7 Nov
11:25 p.m.
Am Montag, 4. November 2013, 11:28:20 schrieben Sie:
this is certainly not the expected behaviour. Are you
building a bridge loop
by any chance? Please explain your configuration (batctl if, brctl show,
...) and check if you have a high amount of broadcasts somehow.
Sorry for my late answer. I was busy during the week and didnt find the time to
look into out setup in detail till now.
We have two wireless interfaces wlan0 and wlan0-1. We also have two ethernet
interfaces eth0.1 and eth0.3 and one VPN interface ffolVPN.
The interfaces wlan0 and eth0.1 are the interfaces used for clients. They are
bridged together with bat0:
root@RosenplatzVPN:~# brctl show
bridge name bridge id STP enabled interfaces
br-mesh 8000.a0f3c15b54a6 no bat0
eth0.1
wlan0
The interfaces wlan0-1 and eth0.3 are the interfaces we use for meshing with
other routers in the same "mesh cloud". These are the interfaces both routers
are connected by each other. The vpn interface ffolVPN is used to connect with
outher "mesh clouds" but the two routers in this case are not connected by
this interface. On the interfaces wlan0-1, eth0.3 and ffolVPN runs Batman
advanced:
root@RosenplatzVPN:~# batctl if
eth0.3: active
wlan0-1: active
ffolVPN: active
To analyze the amount of broadcast traffic I did a tcpdump on the Batman
interfaces wlan0-1 and eth0.3. For me there seems to be a big amount of
broadcast traffic, but I don´t know the normal level of brodcasts so I can´t
compare which amount is right and which is wrong. But maybe you can so I
uploaded the files for you. You can analyze them using wireshark or some other
tool:
* https://dev.freifunk-ol.de/tcpdumps/eth0.3.dump
* https://dev.freifunk-ol.de/tcpdumps/wlan0-1.dump
If you need more data just ask and I will try to provide it.
Kind regards
Clemens
--
#Clemens John <clemens-john(a)gmx.de>
#GnuPG:
Identifier: 0xD92F6BA5
Fingerprint: 1D6D 3EC6 C80F C1D4 CE1F 1133 6607 476C 0DB6 96A3
Always encrypt your messages
8 Nov
8 Nov
9:51 a.m.
Hey Clemens,
Am Montag, 4. November 2013, 11:28:20 schrieben Sie:
Thanks for the explanation and the dumps! I had a look at your dumps, but it
doesn't look like a bridge loop - the number of broadcasts is normal. I don't
have a clue yet where this behaviour comes from. I'd like to make a few more
suggestions for debugging:
* can you please make a debug log of batman-adv on the two nodes at the same
time (batctl ll batman && batctl l > logfile.$hostname or something like this)
* what are the MAC addresses of these two nodes?
As far as I see in the debug output, on one node there is:
* Ethernet fa:d1:11:af:fd:15
* WLAN fa:d1:11:af:fd:16
However, a2:f3:c1:5b:54:a6 is used as Ethernet source address for sending in
both eth0.3 and wlan0-1 dumps. Is it possible that there is a mac address
conflict?
Cheers,
Simon
this is certainly not the expected behaviour. Are
you building a bridge
loop by any chance? Please explain your configuration (batctl if, brctl
show, ...) and check if you have a high amount of broadcasts somehow.
Sorry for my late answer. I was busy during the week and didnt find the
time to look into out setup in detail till now.
We have two wireless interfaces wlan0 and wlan0-1. We also have two
ethernet interfaces eth0.1 and eth0.3 and one VPN interface ffolVPN.
The interfaces wlan0 and eth0.1 are the interfaces used for clients. They
are bridged together with bat0:
root@RosenplatzVPN:~# brctl show
bridge name bridge id STP enabled interfaces
br-mesh 8000.a0f3c15b54a6 no bat0
eth0.1 wlan0
The interfaces wlan0-1 and eth0.3 are the interfaces we use for meshing
with other routers in the same "mesh cloud". These are the interfaces both
routers are connected by each other. The vpn interface ffolVPN is used to
connect with outher "mesh clouds" but the two routers in this case are not
connected by this interface. On the interfaces wlan0-1, eth0.3 and ffolVPN
runs Batman advanced:
root@RosenplatzVPN:~# batctl if
eth0.3: active
wlan0-1: active
ffolVPN: active
To analyze the amount of broadcast traffic I did a tcpdump on the Batman
interfaces wlan0-1 and eth0.3. For me there seems to be a big amount of
broadcast traffic, but I don´t know the normal level of brodcasts so I
can´t compare which amount is right and which is wrong. But maybe you can
so I uploaded the files for you. You can analyze them using wireshark or
some other tool:
* https://dev.freifunk-ol.de/tcpdumps/eth0.3.dump
* https://dev.freifunk-ol.de/tcpdumps/wlan0-1.dump
If you need more data just ask and I will try to provide it.
10:57 p.m.
Am Freitag, 8. November 2013, 10:51:26 schrieben Sie:
However, a2:f3:c1:5b:54:a6 is used as Ethernet source
address for sending in
both eth0.3 and wlan0-1 dumps. Is it possible that there is a mac address
conflict?
Hi Simon,
this seems to be the right hint. I checked this and we really had a mac
address conflict on the interfaces wlan0-1 and eth0.3 we used for meshing. This
was due to a fix for some mac adress problem in our firmware that seems to be
outdated now.
On my router the problem is fixed. We will check our other hardware also but I
think we have a good chance that solving the mac adress conflicts will also
solve this link quality problem. If not, I´ll ask again.
Thank you!
Clemens
--
#Clemens John <clemens-john(a)gmx.de>
#GnuPG:
Identifier: 0xD92F6BA5
Fingerprint: 1D6D 3EC6 C80F C1D4 CE1F 1133 6607 476C 0DB6 96A3
Always encrypt your messages
12 Nov
12 Nov
7:57 p.m.
Am Freitag, 8. November 2013, 10:51:26 schrieben Sie:
Would be nice to hear if the problem was resolved, also we can reference to
that later when somebody asks again for "my TQ dropped to half, why?" :)
Thanks,
Simon
However, a2:f3:c1:5b:54:a6 is used as Ethernet
source address for sending
in both eth0.3 and wlan0-1 dumps. Is it possible that there is a mac
address conflict?
Hi Simon,
this seems to be the right hint. I checked this and we really had a mac
address conflict on the interfaces wlan0-1 and eth0.3 we used for meshing.
This was due to a fix for some mac adress problem in our firmware that
seems to be outdated now.
On my router the problem is fixed. We will check our other hardware also
but I think we have a good chance that solving the mac adress conflicts
will also solve this link quality problem. If not, I´ll ask again.
13 Nov
13 Nov
12:14 p.m.
Am Dienstag, 12. November 2013, 20:57:16 schrieben Sie:
Would be nice to hear if the problem was resolved,
also we can reference to
that later when somebody asks again for "my TQ dropped to half, why?" :)
Yes resolving the conflict solves the problem.
Kind Regards
Clemens
--
#Clemens John <clemens-john(a)gmx.de>
#GnuPG:
Identifier: 0xD92F6BA5
Fingerprint: 1D6D 3EC6 C80F C1D4 CE1F 1133 6607 476C 0DB6 96A3
Always encrypt your messages
3483
days inactive
3493
days old
b.a.t.m.a.n@lists.open-mesh.org
6 comments
2 participants
participants (2)
-
Clemens John -
Simon Wunderlich