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
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
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
Hey Clemens,
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 wlan0The 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:
If you need more data just ask and I will try to provide it.
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
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
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.
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Clemens John -
Simon Wunderlich