Hello there
Hallo (deutsche Version unten)
I have a simple batman setup that does behave odd:
Raspberry b+, jessie, batman-adv2015.2 witha single LOGILINK WL0084B USB wifi stick attached
I have 5 rasperries that can see each other via wifi (one of them is a gw(BASE2), one of them (SHELF_1) is not directly reachable by the gw, because they are in a line from one room to another and has to be reached via one single hop in between)
digraph {
{ "BASE_2" } "BASE_2" -> "SHELF_3 @ ra" [label="1.689"] "BASE_2" -> "SHELF_5 @ Bar" [label="1.689"] "BASE_2" -> "SHELF_2 @ CD Regal" [label="2.161"] "BASE_2" -> "SHELF_4 @ Toaster" [label="2.161"] "BASE_2" -> "SHELF_1 @ Chris" [label="2.040"] subgraph "cluster_SHELF_3 @ ra" { "SHELF_3 @ ra" } "SHELF_3 @ ra" -> "SHELF_5 @ Bar" [label="1.192"] "SHELF_3 @ ra" -> "SHELF_4 @ Toaster" [label="1.328"] "SHELF_3 @ ra" -> "BASE_2" [label="2.277"] subgraph "cluster_SHELF_4 @ Toaster" { "SHELF_4 @ Toaster" } "SHELF_4 @ Toaster" -> "SHELF_3 @ ra" [label="1.037"] "SHELF_4 @ Toaster" -> "SHELF_2 @ CD Regal" [label="1.483"] "SHELF_4 @ Toaster" -> "SHELF_5 @ Bar" [label="1.175"] "SHELF_4 @ Toaster" -> "SHELF_1 @ Chris" [label="1.371"] "SHELF_4 @ Toaster" -> "BASE_2" [label="3.446"] subgraph "cluster_SHELF_1 @ Chris" { "SHELF_1 @ Chris" } "SHELF_1 @ Chris" -> "SHELF_3 @ ra" [label="1.170"] "SHELF_1 @ Chris" -> "SHELF_5 @ Bar" [label="1.020"] subgraph "cluster_SHELF_5 @ Bar" { "SHELF_5 @ Bar" } "SHELF_5 @ Bar" -> "SHELF_3 @ ra" [label="1.045"] "SHELF_5 @ Bar" -> "SHELF_2 @ CD Regal" [label="1.393"] "SHELF_5 @ Bar" -> "SHELF_4 @ Toaster" [label="1.203"] "SHELF_5 @ Bar" -> "SHELF_1 @ Chris" [label="1.226"] "SHELF_5 @ Bar" -> "BASE_2" [label="2.898"]
}
The problem is, when pinging ANY of the clients from the base (or any client from any other client) I always have a package loss of roughly 50% with a ping reply time up to 10ms sometimes (BASE2 -> SHELF_1, the closer ones are faster). To make things worse, the connection is so weak, even a ssh login may bring it down.
I tried quite a few different settings and already updated to the new version and used multiple USB sticks - the result always stays the same. Now I am out of ideas and I would appreciate some new ideas.
GERMAN:
Ich habe hier 5 Raspberries die sich gegenseitig sehen können (einer ist eine BASIS (BASE2), einer davon (SHELF_1) kann von der Basis nicht direkt gesehen werden, weil sie von einem raum zum nächsten immer größere Distanzen überwinden müssen).
Das Problem ist nun, dass wenn ich irgend einen client von der Basis aus pinge, oder irgend einen client von einem anderen client pinge, dass ich rund 50% package loss mit bis zu 10ms antwortzeit habe. Die die sich näher sind funktionieren besser (2ms) die weiter weg sind schlechter. Ich kann nicht mal mit einer ssh konsole von BASE2 auf SHELF_1 so dass ich da sinnvoll was eingeben kann.
Ich habe schon einige verschiedene Optionen durchprobiert, wie Beispielsweise Update von 2015.0 auf 2015.2, sogar zwei USB Sticks pro Raspberry PI, aber das Problem bleibt. Nun würde ich um Input bitten, mir sind die Ideen ausgegangen.
Danke
Thanks a lot!
Richard
VDid you double-check for hardware-issues? Might be a compatibility issue with you wifi hardware.
What are you link values between each peers? (batctl o where row 1 is equal row 2)
Which wifi-mode do you use? Did you tried 802.11s instead of adhoc or vice versa?
Did you tried batman L2 pings instead of icmp-ones?
Best regards
Ruben
Am 17.12.2015 um 21:52 schrieb no name keinepostnurmuell@gmail.com:
Hello there
Hallo (deutsche Version unten)
I have a simple batman setup that does behave odd:
Raspberry b+, jessie, batman-adv2015.2 witha single LOGILINK WL0084B USB wifi stick attached
I have 5 rasperries that can see each other via wifi (one of them is a gw(BASE2), one of them (SHELF_1) is not directly reachable by the gw, because they are in a line from one room to another and has to be reached via one single hop in between)
digraph {
{ "BASE_2" } "BASE_2" -> "SHELF_3 @ ra" [label="1.689"] "BASE_2" -> "SHELF_5 @ Bar" [label="1.689"] "BASE_2" -> "SHELF_2 @ CD Regal" [label="2.161"] "BASE_2" -> "SHELF_4 @ Toaster" [label="2.161"] "BASE_2" -> "SHELF_1 @ Chris" [label="2.040"] subgraph "cluster_SHELF_3 @ ra" { "SHELF_3 @ ra" } "SHELF_3 @ ra" -> "SHELF_5 @ Bar" [label="1.192"] "SHELF_3 @ ra" -> "SHELF_4 @ Toaster" [label="1.328"] "SHELF_3 @ ra" -> "BASE_2" [label="2.277"] subgraph "cluster_SHELF_4 @ Toaster" { "SHELF_4 @ Toaster" } "SHELF_4 @ Toaster" -> "SHELF_3 @ ra" [label="1.037"] "SHELF_4 @ Toaster" -> "SHELF_2 @ CD Regal" [label="1.483"] "SHELF_4 @ Toaster" -> "SHELF_5 @ Bar" [label="1.175"] "SHELF_4 @ Toaster" -> "SHELF_1 @ Chris" [label="1.371"] "SHELF_4 @ Toaster" -> "BASE_2" [label="3.446"] subgraph "cluster_SHELF_1 @ Chris" { "SHELF_1 @ Chris" } "SHELF_1 @ Chris" -> "SHELF_3 @ ra" [label="1.170"] "SHELF_1 @ Chris" -> "SHELF_5 @ Bar" [label="1.020"] subgraph "cluster_SHELF_5 @ Bar" { "SHELF_5 @ Bar" } "SHELF_5 @ Bar" -> "SHELF_3 @ ra" [label="1.045"] "SHELF_5 @ Bar" -> "SHELF_2 @ CD Regal" [label="1.393"] "SHELF_5 @ Bar" -> "SHELF_4 @ Toaster" [label="1.203"] "SHELF_5 @ Bar" -> "SHELF_1 @ Chris" [label="1.226"] "SHELF_5 @ Bar" -> "BASE_2" [label="2.898"]
}
The problem is, when pinging ANY of the clients from the base (or any client from any other client) I always have a package loss of roughly 50% with a ping reply time up to 10ms sometimes (BASE2 -> SHELF_1, the closer ones are faster). To make things worse, the connection is so weak, even a ssh login may bring it down.
I tried quite a few different settings and already updated to the new version and used multiple USB sticks - the result always stays the same. Now I am out of ideas and I would appreciate some new ideas.
GERMAN:
Ich habe hier 5 Raspberries die sich gegenseitig sehen können (einer ist eine BASIS (BASE2), einer davon (SHELF_1) kann von der Basis nicht direkt gesehen werden, weil sie von einem raum zum nächsten immer größere Distanzen überwinden müssen).
Das Problem ist nun, dass wenn ich irgend einen client von der Basis aus pinge, oder irgend einen client von einem anderen client pinge, dass ich rund 50% package loss mit bis zu 10ms antwortzeit habe. Die die sich näher sind funktionieren besser (2ms) die weiter weg sind schlechter. Ich kann nicht mal mit einer ssh konsole von BASE2 auf SHELF_1 so dass ich da sinnvoll was eingeben kann.
Ich habe schon einige verschiedene Optionen durchprobiert, wie Beispielsweise Update von 2015.0 auf 2015.2, sogar zwei USB Sticks pro Raspberry PI, aber das Problem bleibt. Nun würde ich um Input bitten, mir sind die Ideen ausgegangen.
Danke
Thanks a lot!
Richard
Hello Ruben thanks for your help!
root@BASE2:~# batctl o [B.A.T.M.A.N. adv 2015.2, MainIF/MAC: wlan0/40:a5:ef:06:8d:74 (bat0 BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 7c:dd:90:79:e6:19 7.700s (107) 7c:dd:90:79:e6:19 [ wlan0]: 7c:dd:90:79:b5:f2 ( 33) 00:23:54:b4:c4:6f ( 27) 7c:dd:90:79:e6:19 (107) 7c:dd:90:79:b5:f2 6.840s (104) 7c:dd:90:79:b5:f2 [ wlan0]: 00:23:54:b4:c4:6f ( 15) 7c:dd:90:79:e6:19 ( 46) 7c:dd:90:79:b5:f2 (104) 00:23:54:b4:c4:6f 4.580s ( 66) 7c:dd:90:79:e6:19 [ wlan0]: 7c:dd:90:79:b5:f2 ( 31) 7c:dd:90:79:e6:19 ( 66) 00:23:54:b4:c4:6f ( 45)
This is the output from batctl o
I actually tried other USB sticks aswell, but did not get rid of the issue. I am using the Ad-Hoc modus to answer your question.
Thanks for your help so far, do you have other suggestions for me? Richard
On 18 December 2015 at 00:02, Ruben Kelevra ruben@vfn-nrw.de wrote:
VDid you double-check for hardware-issues? Might be a compatibility issue with you wifi hardware.
What are you link values between each peers? (batctl o where row 1 is equal row 2)
Which wifi-mode do you use? Did you tried 802.11s instead of adhoc or vice versa?
Did you tried batman L2 pings instead of icmp-ones?
Best regards
Ruben
Am 17.12.2015 um 21:52 schrieb no name keinepostnurmuell@gmail.com:
Hello there
Hallo (deutsche Version unten)
I have a simple batman setup that does behave odd:
Raspberry b+, jessie, batman-adv2015.2 witha single LOGILINK WL0084B USB wifi stick attached
I have 5 rasperries that can see each other via wifi (one of them is a gw(BASE2), one of them (SHELF_1) is not directly reachable by the gw, because they are in a line from one room to another and has to be reached via one single hop in between)
digraph {
{ "BASE_2" } "BASE_2" -> "SHELF_3 @ ra" [label="1.689"] "BASE_2" -> "SHELF_5 @ Bar" [label="1.689"] "BASE_2" -> "SHELF_2 @ CD Regal" [label="2.161"] "BASE_2" -> "SHELF_4 @ Toaster" [label="2.161"] "BASE_2" -> "SHELF_1 @ Chris" [label="2.040"] subgraph "cluster_SHELF_3 @ ra" { "SHELF_3 @ ra" } "SHELF_3 @ ra" -> "SHELF_5 @ Bar" [label="1.192"] "SHELF_3 @ ra" -> "SHELF_4 @ Toaster" [label="1.328"] "SHELF_3 @ ra" -> "BASE_2" [label="2.277"] subgraph "cluster_SHELF_4 @ Toaster" { "SHELF_4 @ Toaster" } "SHELF_4 @ Toaster" -> "SHELF_3 @ ra" [label="1.037"] "SHELF_4 @ Toaster" -> "SHELF_2 @ CD Regal" [label="1.483"] "SHELF_4 @ Toaster" -> "SHELF_5 @ Bar" [label="1.175"] "SHELF_4 @ Toaster" -> "SHELF_1 @ Chris" [label="1.371"] "SHELF_4 @ Toaster" -> "BASE_2" [label="3.446"] subgraph "cluster_SHELF_1 @ Chris" { "SHELF_1 @ Chris" } "SHELF_1 @ Chris" -> "SHELF_3 @ ra" [label="1.170"] "SHELF_1 @ Chris" -> "SHELF_5 @ Bar" [label="1.020"] subgraph "cluster_SHELF_5 @ Bar" { "SHELF_5 @ Bar" } "SHELF_5 @ Bar" -> "SHELF_3 @ ra" [label="1.045"] "SHELF_5 @ Bar" -> "SHELF_2 @ CD Regal" [label="1.393"] "SHELF_5 @ Bar" -> "SHELF_4 @ Toaster" [label="1.203"] "SHELF_5 @ Bar" -> "SHELF_1 @ Chris" [label="1.226"] "SHELF_5 @ Bar" -> "BASE_2" [label="2.898"]
}
The problem is, when pinging ANY of the clients from the base (or any client from any other client) I always have a package loss of roughly 50% with a ping reply time up to 10ms sometimes (BASE2 -> SHELF_1, the closer ones are faster). To make things worse, the connection is so weak, even a ssh login may bring it down.
I tried quite a few different settings and already updated to the new version and used multiple USB sticks - the result always stays the same. Now I am out of ideas and I would appreciate some new ideas.
GERMAN:
Ich habe hier 5 Raspberries die sich gegenseitig sehen können (einer ist eine BASIS (BASE2), einer davon (SHELF_1) kann von der Basis nicht direkt gesehen werden, weil sie von einem raum zum nächsten immer größere Distanzen überwinden müssen).
Das Problem ist nun, dass wenn ich irgend einen client von der Basis aus pinge, oder irgend einen client von einem anderen client pinge, dass ich rund 50% package loss mit bis zu 10ms antwortzeit habe. Die die sich näher sind funktionieren besser (2ms) die weiter weg sind schlechter. Ich kann nicht mal mit einer ssh konsole von BASE2 auf SHELF_1 so dass ich da sinnvoll was eingeben kann.
Ich habe schon einige verschiedene Optionen durchprobiert, wie Beispielsweise Update von 2015.0 auf 2015.2, sogar zwei USB Sticks pro Raspberry PI, aber das Problem bleibt. Nun würde ich um Input bitten, mir sind die Ideen ausgegangen.
Danke
Thanks a lot!
Richard
On Friday 18 December 2015 14:23:24 no name wrote:
Hello Ruben thanks for your help!
root@BASE2:~# batctl o [B.A.T.M.A.N. adv 2015.2, MainIF/MAC: wlan0/40:a5:ef:06:8d:74 (bat0 BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 7c:dd:90:79:e6:19 7.700s (107) 7c:dd:90:79:e6:19 [ wlan0]: 7c:dd:90:79:b5:f2 ( 33) 00:23:54:b4:c4:6f ( 27) 7c:dd:90:79:e6:19 (107) 7c:dd:90:79:b5:f2 6.840s (104) 7c:dd:90:79:b5:f2 [ wlan0]: 00:23:54:b4:c4:6f ( 15) 7c:dd:90:79:e6:19 ( 46) 7c:dd:90:79:b5:f2 (104) 00:23:54:b4:c4:6f 4.580s ( 66) 7c:dd:90:79:e6:19 [ wlan0]: 7c:dd:90:79:b5:f2 ( 31) 7c:dd:90:79:e6:19 ( 66) 00:23:54:b4:c4:6f ( 45)
This is the output from batctl o
These number look really bad. Looks like the wifi links between the nodes are basically not working. You can check the signal of the links via `iw dev wlan0 station dump` but there is (most likely) nothing which can be done from the batman-adv side. First you have to fix your wifi links.
I have no idea what these LOGILINK WL0084B are using or how good they are (they look rather crappy regarding the antennas but please correct me). If you want to try a different mode (in case Adhoc is broken in this driver) then you can try to use meshpoint (802.11s) without the routing enabled. I think this was done like this:
iw phy phy0 interface add $MESH_IFACE type mp iw dev $MESH_IFACE set mesh_param mesh_ttl 1 iw dev $MESH_IFACE set mesh_param mesh_fwding 0 iw dev $MESH_IFACE mesh join $MESH_ID
Kind regards, Sven
Hello Sven, thanks for the help.
I feel like the wifi adapters are not the problem: Even when placing two of them on the same table I get a packet loss of 50% with less than half a meter apart. That can't be an antenna problem, don't you think?
Thanks a lot Richard
On 18 December 2015 at 14:43, Sven Eckelmann sven@narfation.org wrote:
On Friday 18 December 2015 14:23:24 no name wrote:
Hello Ruben thanks for your help!
root@BASE2:~# batctl o [B.A.T.M.A.N. adv 2015.2, MainIF/MAC: wlan0/40:a5:ef:06:8d:74 (bat0 BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 7c:dd:90:79:e6:19 7.700s (107) 7c:dd:90:79:e6:19 [ wlan0]: 7c:dd:90:79:b5:f2 ( 33) 00:23:54:b4:c4:6f ( 27) 7c:dd:90:79:e6:19 (107) 7c:dd:90:79:b5:f2 6.840s (104) 7c:dd:90:79:b5:f2 [ wlan0]: 00:23:54:b4:c4:6f ( 15) 7c:dd:90:79:e6:19 ( 46) 7c:dd:90:79:b5:f2 (104) 00:23:54:b4:c4:6f 4.580s ( 66) 7c:dd:90:79:e6:19 [ wlan0]: 7c:dd:90:79:b5:f2 ( 31) 7c:dd:90:79:e6:19 ( 66) 00:23:54:b4:c4:6f ( 45)
This is the output from batctl o
These number look really bad. Looks like the wifi links between the nodes are basically not working. You can check the signal of the links via `iw dev wlan0 station dump` but there is (most likely) nothing which can be done from the batman-adv side. First you have to fix your wifi links.
I have no idea what these LOGILINK WL0084B are using or how good they are (they look rather crappy regarding the antennas but please correct me). If you want to try a different mode (in case Adhoc is broken in this driver) then you can try to use meshpoint (802.11s) without the routing enabled. I think this was done like this:
iw phy phy0 interface add $MESH_IFACE type mp iw dev $MESH_IFACE set mesh_param mesh_ttl 1 iw dev $MESH_IFACE set mesh_param mesh_fwding 0 iw dev $MESH_IFACE mesh join $MESH_IDKind regards, Sven
On Friday 18 December 2015 15:20:01 no name wrote:
Hello Sven, thanks for the help.
I feel like the wifi adapters are not the problem: Even when placing two of them on the same table I get a packet loss of 50% with less than half a meter apart. That can't be an antenna problem, don't you think?
Of course, the hardware and driver are never to blame. You have found the batman-adv packet conspiracy. The little bat eats your packets like xmas cookies...
Kind regards, Sven
I gave the the packet stealing little bat a thought ...
I dont think the antenna is an issue, because than I would have an increased packet loss over distance. But I did not have that. My Packet loss on the same table:
56% Packet loss if 20cm distance 50% if ~ 15m apart.
When having an antenna problem I would think that distance should matter more. Dont you think?
Richard
On 18 December 2015 at 15:42, Sven Eckelmann sven@narfation.org wrote:
On Friday 18 December 2015 15:20:01 no name wrote:
Hello Sven, thanks for the help.
I feel like the wifi adapters are not the problem: Even when placing two of them on the same table I get a packet loss of 50% with less than half a meter apart. That can't be an antenna problem, don't you think?
Of course, the hardware and driver are never to blame. You have found the batman-adv packet conspiracy. The little bat eats your packets like xmas cookies...
Kind regards, Sven
On Friday 18 December 2015 17:12:50 no name wrote:
I gave the the packet stealing little bat a thought ...
I dont think the antenna is an issue, because than I would have an increased packet loss over distance. But I did not have that. My Packet loss on the same table:
56% Packet loss if 20cm distance 50% if ~ 15m apart.
When having an antenna problem I would think that distance should matter more. Dont you think?
As said before, there is a lot more than the antenna which can be bad about a device. E.g. the PAs, driver, firmware, the open+running microwave oven next to it, ... Just because I mentioned the miniature antennas as one possible problem (because they are unreliable in things like the linino) doesn't mean that we now have to ignore everything else which was mentioned earlier (or at the same time).
And just looking at the batman-adv layer might now help here at all. First you have to determine what of the parts is broken before finding out how it can be fixed.
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
no name -
Ruben Kelevra -
Sven Eckelmann