All of lore.kernel.org
 help / color / mirror / Atom feed
* [B.A.T.M.A.N.]  Super high package loss and weak connection
@ 2015-12-17 20:52 no name
  2015-12-17 23:02 ` Ruben Kelevra
  0 siblings, 1 reply; 12+ messages in thread
From: no name @ 2015-12-17 20:52 UTC (permalink / raw)
  To: b.a.t.m.a.n

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-17 20:52 [B.A.T.M.A.N.] Super high package loss and weak connection no name
@ 2015-12-17 23:02 ` Ruben Kelevra
  2015-12-18 13:23   ` no name
  0 siblings, 1 reply; 12+ messages in thread
From: Ruben Kelevra @ 2015-12-17 23:02 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-17 23:02 ` Ruben Kelevra
@ 2015-12-18 13:23   ` no name
  2015-12-18 13:43     ` Sven Eckelmann
  0 siblings, 1 reply; 12+ messages in thread
From: no name @ 2015-12-18 13:23 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-18 13:23   ` no name
@ 2015-12-18 13:43     ` Sven Eckelmann
  2015-12-18 14:20       ` no name
  0 siblings, 1 reply; 12+ messages in thread
From: Sven Eckelmann @ 2015-12-18 13:43 UTC (permalink / raw)
  To: b.a.t.m.a.n

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-18 13:43     ` Sven Eckelmann
@ 2015-12-18 14:20       ` no name
  2015-12-18 14:42         ` Sven Eckelmann
  0 siblings, 1 reply; 12+ messages in thread
From: no name @ 2015-12-18 14:20 UTC (permalink / raw)
  To: Sven Eckelmann,
	The list for a Better Approach To Mobile Ad-hoc Networking

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_ID
>
> Kind regards,
>         Sven

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-18 14:20       ` no name
@ 2015-12-18 14:42         ` Sven Eckelmann
  2015-12-18 16:12           ` no name
  0 siblings, 1 reply; 12+ messages in thread
From: Sven Eckelmann @ 2015-12-18 14:42 UTC (permalink / raw)
  To: no name; +Cc: The list for a Better Approach To Mobile Ad-hoc Networking

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-18 14:42         ` Sven Eckelmann
@ 2015-12-18 16:12           ` no name
  2015-12-18 16:40             ` Sven Eckelmann
  0 siblings, 1 reply; 12+ messages in thread
From: no name @ 2015-12-18 16:12 UTC (permalink / raw)
  To: Sven Eckelmann,
	The list for a Better Approach To Mobile Ad-hoc Networking

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-18 16:12           ` no name
@ 2015-12-18 16:40             ` Sven Eckelmann
       [not found]               ` <CAKrZ8yffDYcr6UCw2Yv7hqUFEBNZQ+nTU09dovL=PO3+Zqy7ig@mail.gmail.com>
  0 siblings, 1 reply; 12+ messages in thread
From: Sven Eckelmann @ 2015-12-18 16:40 UTC (permalink / raw)
  To: no name; +Cc: The list for a Better Approach To Mobile Ad-hoc Networking

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
       [not found]               ` <CAKrZ8yffDYcr6UCw2Yv7hqUFEBNZQ+nTU09dovL=PO3+Zqy7ig@mail.gmail.com>
@ 2015-12-18 17:30                 ` Sven Eckelmann
  2015-12-21 15:35                   ` no name
  0 siblings, 1 reply; 12+ messages in thread
From: Sven Eckelmann @ 2015-12-18 17:30 UTC (permalink / raw)
  To: no name; +Cc: The list for a Better Approach To Mobile Ad-hoc Networking

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

On Friday 18 December 2015 18:22:40 no name wrote:
> I made a little table were I tried wheezy against jessy and 802.11 as
> someone suggested earlier in the mailing list to me. I placed the
> raspberries next to each other on my table and tested through different
> settings:
> 
> ad-hoc+batman-2014.X@debian wheezy:          1m distance  .. 200 pings, 0%
> paket loss, reply time -> (min,avg,max,mdev 1.2ms, 1.8ms, 6.4ms, 0.8ms)
> ad-hoc+batman-2015.2@debian jessie:             1m distance  .. 200 pings,
> 6% paket loss, reply time -> (min,avg,max,mdev 1.1ms, 170ms, 1400ms, 370ms)
> 802.11s @debian jessie:                                  1m distance  ..
> 200 pings, 0% paket loss, reply time -> (min,avg,max,mdev 1.05ms, 1.8ms,
> 14ms, 1.5ms)

Your "table" is incomplete. adhoc without batman-adv and meshpoint (802.11s 
without fwding+ttl=1)+batman-adv are missing. You also mixed two different 
batman-adv versions. Either you use the same batman-adv version everywhere or 
make sure that the kernel+wifi driver doesn't change. Changing multiple 
variables between two tests tests make the results more or less useless for 
comparisons.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
  2015-12-18 17:30                 ` Sven Eckelmann
@ 2015-12-21 15:35                   ` no name
  0 siblings, 0 replies; 12+ messages in thread
From: no name @ 2015-12-21 15:35 UTC (permalink / raw)
  To: Sven Eckelmann,
	The list for a Better Approach To Mobile Ad-hoc Networking

Hello
I continued with testing:
Raspberry Pi b+ with a LOGILINK WL0084B USB Stick on Jessie with
Kernel 4.1.13+, batman2015-0

I tested:

Batman + Ad-Hoc
Batman + 802.11s
only 802.11s

against each other. This lead to the following results:

All of the above configurations show basically the same behaviour:
When pinging, the reply times from directly connected nodes are really
stable (1-4ms, depends on the range).
When pinging via one hop in between, the network seems to take some
breaks. A burst of pings (5-10) are replied pretty accurate, but
always followed by a really long break of about 2-3 seconds

The problem is less intense when using the batman configurations
(->actually does rout better (: ).

Facing this results I think I might be staring at a driver's issue,
but still wanted to see if anyone here can help me with ideas.

Thanks everyone for the time and help!

Richard

On 18 December 2015 at 18:30, Sven Eckelmann <sven@narfation.org> wrote:
> On Friday 18 December 2015 18:22:40 no name wrote:
>> I made a little table were I tried wheezy against jessy and 802.11 as
>> someone suggested earlier in the mailing list to me. I placed the
>> raspberries next to each other on my table and tested through different
>> settings:
>>
>> ad-hoc+batman-2014.X@debian wheezy:          1m distance  .. 200 pings, 0%
>> paket loss, reply time -> (min,avg,max,mdev 1.2ms, 1.8ms, 6.4ms, 0.8ms)
>> ad-hoc+batman-2015.2@debian jessie:             1m distance  .. 200 pings,
>> 6% paket loss, reply time -> (min,avg,max,mdev 1.1ms, 170ms, 1400ms, 370ms)
>> 802.11s @debian jessie:                                  1m distance  ..
>> 200 pings, 0% paket loss, reply time -> (min,avg,max,mdev 1.05ms, 1.8ms,
>> 14ms, 1.5ms)
>
> Your "table" is incomplete. adhoc without batman-adv and meshpoint (802.11s
> without fwding+ttl=1)+batman-adv are missing. You also mixed two different
> batman-adv versions. Either you use the same batman-adv version everywhere or
> make sure that the kernel+wifi driver doesn't change. Changing multiple
> variables between two tests tests make the results more or less useless for
> comparisons.
>
> Kind regards,
>         Sven

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
       [not found]   ` <CAO9R-ZZ=NT2Mh-OYtUpsZOYV=FHVjZjta+W1KeJU-v+HRgKaKg@mail.gmail.com>
@ 2015-12-30 19:14     ` no name
  0 siblings, 0 replies; 12+ messages in thread
From: no name @ 2015-12-30 19:14 UTC (permalink / raw)
  To: Simon Müller,
	The list for a Better Approach To Mobile Ad-hoc Networking

Hello Simon

Thanks for your input! I did not try that, but I have a Logilink
WL0084B adapter which has 150Mps only thus, I could never have a HT40
connection. Don't you agree?

Thanks
Richard

On 29 December 2015 at 15:36, Simon Müller <simon.f.mueller@gmail.com> wrote:
> Hi Richard,
>
> have you tried to set all devices to HT20?
>
> Regards, Simon
>
> 2015-12-29 13:42 GMT+01:00 no name <keinepostnurmuell@gmail.com>:
>>
>> I once again tried some settings and I want to use this message as a
>> bump. I am close to certain, that the RT5370 (rt2800usb) drivers are
>> to blame, but I hope some of you guys have some input for me:
>>
>> Here is the output from batctl td -x 1 bat0 when my client is being
>> pinged with a hop node in between:
>>
>> 21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 5, length 64
>> 21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 5, length 64
>> 21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>> Request from b2:d5:c7:9e:49:96, length 331
>> 21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b >
>> fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has
>> fe80::b0d5:c7ff:fe9e:4996, length 72
>> 21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 >
>> fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is
>> fe80::b0d5:c7ff:fe9e:4996, length 64
>> 21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1
>> (b2:d5:c7:9e:49:96), length 28
>> 21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length
>> 28
>> 21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 6, length 64
>> 21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 6, length 64
>> 21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 7, length 64
>> 21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 7, length 64
>> 21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 8, length 64
>> 21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 8, length 64
>> 21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 9, length 64
>> 21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 9, length 64
>> 21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 10, length 64
>> 21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 10, length 64
>> 21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996
>> ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length
>> 72
>> 21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
>> UDP, length 4
>> 21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
>> 21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
>> 21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> (c6:89:38:52:b8:4b), length 28
>> 21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> (c6:89:38:52:b8:4b), length 28
>> 21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 12, length 64
>> 21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 12, length 64
>> 21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> (c6:89:38:52:b8:4b), length 28
>> 21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>> Request from c6:89:38:52:b8:4b, length 332
>> 21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
>> (1e:bf:71:42:cc:98), length 28
>> 21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
>> (1e:bf:71:42:cc:98), length 28
>> 21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
>> UDP, length 4
>> 21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
>> 21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
>> 21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> (c6:89:38:52:b8:4b), length 28
>> 21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length 28
>> 21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP,
>> Flags [...PA.], length 2
>> 21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 24, length 64
>> 21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 24, length 64
>> 21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 25, length 64
>> 21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 25, length 64
>> 21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 26, length 64
>> 21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 26, length 64
>> 21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 27, length 64
>> 21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 27, length 64
>> 21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> 1326, seq 28, length 64
>> 21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> 1326, seq 28, length 64
>>
>> As you can see, I get a lot of ARP requests, indicating, that my
>> clients are loosing the connection farily often, resulting exactly in
>> the observed behavior. I really would appreciate some help, or even a
>> hinch in some direction what could lead further ...
>>
>> Has ever someone tried to use 20+ raspberries in a meshed network as
>> nodes and hops?
>>
>> Thanks
>> Richard
>>
>> On 28 December 2015 at 23:43, no name <keinepostnurmuell@gmail.com> wrote:
>> > I once again tried some settings and I want to use this message as a
>> > bump. I am close to certain, that the RT5370 (rt2800usb) drivers are
>> > to blame, but I hope some of you guys have some input for me:
>> >
>> > Here is the output from batctl td -x 1 bat0 when my client is being
>> > pinged with a hop node in between:
>> >
>> > 21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 5, length 64
>> > 21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 5, length 64
>> > 21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>> > Request from b2:d5:c7:9e:49:96, length 331
>> > 21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b >
>> > fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has
>> > fe80::b0d5:c7ff:fe9e:4996, length 72
>> > 21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 >
>> > fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is
>> > fe80::b0d5:c7ff:fe9e:4996, length 64
>> > 21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1
>> > (b2:d5:c7:9e:49:96), length 28
>> > 21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length
>> > 28
>> > 21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 6, length 64
>> > 21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 6, length 64
>> > 21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 7, length 64
>> > 21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 7, length 64
>> > 21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 8, length 64
>> > 21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 8, length 64
>> > 21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 9, length 64
>> > 21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 9, length 64
>> > 21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 10, length 64
>> > 21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 10, length 64
>> > 21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996
>> > ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length
>> > 72
>> > 21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
>> > UDP, length 4
>> > 21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
>> > 21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
>> > 21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> > (c6:89:38:52:b8:4b), length 28
>> > 21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> > (c6:89:38:52:b8:4b), length 28
>> > 21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 12, length 64
>> > 21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 12, length 64
>> > 21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> > (c6:89:38:52:b8:4b), length 28
>> > 21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
>> > Request from c6:89:38:52:b8:4b, length 332
>> > 21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
>> > (1e:bf:71:42:cc:98), length 28
>> > 21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
>> > (1e:bf:71:42:cc:98), length 28
>> > 21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
>> > UDP, length 4
>> > 21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
>> > 21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 >
>> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
>> > 21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
>> > (c6:89:38:52:b8:4b), length 28
>> > 21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length
>> > 28
>> > 21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP,
>> > Flags [...PA.], length 2
>> > 21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 24, length 64
>> > 21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 24, length 64
>> > 21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 25, length 64
>> > 21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 25, length 64
>> > 21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 26, length 64
>> > 21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 26, length 64
>> > 21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 27, length 64
>> > 21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 27, length 64
>> > 21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
>> > 1326, seq 28, length 64
>> > 21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
>> > 1326, seq 28, length 64
>> >
>> > As you can see, I get a lot of ARP requests, indicating, that my
>> > clients are loosing the connection farily often, resulting exactly in
>> > the observed behavior. I really would appreciate some help, or even a
>> > hinch in some direction what could lead further ...
>> >
>> > Has ever someone tried to use 20+ raspberries in a meshed network as
>> > nodes and hops?
>> >
>> > Thanks
>> > Richard
>> >
>> > On 21 December 2015 at 16:32,  <b.a.t.m.a.n-owner@lists.open-mesh.org>
>> > wrote:
>> >> Message rejected by filter rule match
>> >>
>> >>
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: no name <keinepostnurmuell@gmail.com>
>> >> To: The list for a Better Approach To Mobile Ad-hoc Networking
>> >> <b.a.t.m.a.n@lists.open-mesh.org>
>> >> Cc:
>> >> Date: Mon, 21 Dec 2015 16:32:36 +0100
>> >> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak connection
>> >> Right now I am working on a new set of measurements with the basis as
>> >> follows:
>> >>
>> >> Raspberry Pi b+ with a LOGILINK WL0084B USB Stick on Jessie with Kernel
>> >> 4.1.13+, batman2015-0
>> >>
>> >> I tested:
>> >>
>> >> Batman + Ad-Hoc
>> >> Batman + 802.11s
>> >> only 802.11s
>> >>
>> >> against each other. This lead to the following results:
>> >>
>> >> All of the above configurations show basically the same behaviour:
>> >> When pinging, the reply times from directly connected nodes are really
>> >> stable (1-4ms, depends on the range).
>> >> When pinging via one hop in between, the network seems to take some
>> >> breaks. A burst of pings (5-10) are replied pretty accurate, but always
>> >> followed by a really long break of about 2-3 seconds
>> >>
>> >> The problem is less intense when using the batman configurations
>> >> (->actually does rout better (: ).
>> >>
>> >> Facing this results I think I might be staring at a driver's issue, but
>> >> still wanted to see if anyone here can help me with ideas.
>> >>
>> >> Thanks everyone for the time and help!
>> >>
>> >> Richard
>> >>
>> >>
>> >>> ---------- Forwarded message ----------
>> >>> From: Sven Eckelmann <sven@narfation.org>
>> >>> Date: 18 December 2015 at 18:30
>> >>> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak
>> >>> connection
>> >>> To: no name <keinepostnurmuell@gmail.com>
>> >>> Cc: The list for a Better Approach To Mobile Ad-hoc Networking
>> >>> <b.a.t.m.a.n@lists.open-mesh.org>
>> >>>
>> >>>
>> >>> On Friday 18 December 2015 18:22:40 no name wrote:
>> >>> > I made a little table were I tried wheezy against jessy and 802.11
>> >>> > as
>> >>> > someone suggested earlier in the mailing list to me. I placed the
>> >>> > raspberries next to each other on my table and tested through
>> >>> > different
>> >>> > settings:
>> >>> >
>> >>> > ad-hoc+batman-2014.X@debian wheezy:          1m distance  .. 200
>> >>> > pings, 0%
>> >>> > paket loss, reply time -> (min,avg,max,mdev 1.2ms, 1.8ms, 6.4ms,
>> >>> > 0.8ms)
>> >>> > ad-hoc+batman-2015.2@debian jessie:             1m distance  .. 200
>> >>> > pings,
>> >>> > 6% paket loss, reply time -> (min,avg,max,mdev 1.1ms, 170ms, 1400ms,
>> >>> > 370ms)
>> >>> > 802.11s @debian jessie:                                  1m distance
>> >>> > ..
>> >>> > 200 pings, 0% paket loss, reply time -> (min,avg,max,mdev 1.05ms,
>> >>> > 1.8ms,
>> >>> > 14ms, 1.5ms)
>> >>>
>> >>> Your "table" is incomplete. adhoc without batman-adv and meshpoint
>> >>> (802.11s
>> >>> without fwding+ttl=1)+batman-adv are missing. You also mixed two
>> >>> different
>> >>> batman-adv versions. Either you use the same batman-adv version
>> >>> everywhere or
>> >>> make sure that the kernel+wifi driver doesn't change. Changing
>> >>> multiple
>> >>> variables between two tests tests make the results more or less
>> >>> useless for
>> >>> comparisons.
>> >>>
>> >>> Kind regards,
>> >>>         Sven
>> >>>
>> >>
>> >>
>
>
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [B.A.T.M.A.N.] Super high package loss and weak connection
@ 2015-12-29 12:42 no name
       [not found] ` <CAO9R-ZajkZRq-4==N3Y9aXkRCc3AhmPQiB_P4gSfKtu0X9W5tg@mail.gmail.com>
  0 siblings, 1 reply; 12+ messages in thread
From: no name @ 2015-12-29 12:42 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

I once again tried some settings and I want to use this message as a
bump. I am close to certain, that the RT5370 (rt2800usb) drivers are
to blame, but I hope some of you guys have some input for me:

Here is the output from batctl td -x 1 bat0 when my client is being
pinged with a hop node in between:

21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 5, length 64
21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 5, length 64
21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from b2:d5:c7:9e:49:96, length 331
21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b >
fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has
fe80::b0d5:c7ff:fe9e:4996, length 72
21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 >
fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is
fe80::b0d5:c7ff:fe9e:4996, length 64
21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1
(b2:d5:c7:9e:49:96), length 28
21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length 28
21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 6, length 64
21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 6, length 64
21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 7, length 64
21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 7, length 64
21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 8, length 64
21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 8, length 64
21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 9, length 64
21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 9, length 64
21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 10, length 64
21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 10, length 64
21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996
ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length
72
21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
UDP, length 4
21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 >
fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 >
fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
(c6:89:38:52:b8:4b), length 28
21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
(c6:89:38:52:b8:4b), length 28
21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 12, length 64
21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 12, length 64
21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
(c6:89:38:52:b8:4b), length 28
21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from c6:89:38:52:b8:4b, length 332
21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
(1e:bf:71:42:cc:98), length 28
21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
(1e:bf:71:42:cc:98), length 28
21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
UDP, length 4
21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 >
fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 >
fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
(c6:89:38:52:b8:4b), length 28
21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length 28
21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP,
Flags [...PA.], length 2
21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 24, length 64
21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 24, length 64
21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 25, length 64
21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 25, length 64
21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 26, length 64
21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 26, length 64
21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 27, length 64
21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 27, length 64
21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
1326, seq 28, length 64
21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
1326, seq 28, length 64

As you can see, I get a lot of ARP requests, indicating, that my
clients are loosing the connection farily often, resulting exactly in
the observed behavior. I really would appreciate some help, or even a
hinch in some direction what could lead further ...

Has ever someone tried to use 20+ raspberries in a meshed network as
nodes and hops?

Thanks
Richard

On 28 December 2015 at 23:43, no name <keinepostnurmuell@gmail.com> wrote:
> I once again tried some settings and I want to use this message as a
> bump. I am close to certain, that the RT5370 (rt2800usb) drivers are
> to blame, but I hope some of you guys have some input for me:
>
> Here is the output from batctl td -x 1 bat0 when my client is being
> pinged with a hop node in between:
>
> 21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 5, length 64
> 21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 5, length 64
> 21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from b2:d5:c7:9e:49:96, length 331
> 21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b >
> fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has
> fe80::b0d5:c7ff:fe9e:4996, length 72
> 21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 >
> fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is
> fe80::b0d5:c7ff:fe9e:4996, length 64
> 21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1
> (b2:d5:c7:9e:49:96), length 28
> 21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length 28
> 21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 6, length 64
> 21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 6, length 64
> 21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 7, length 64
> 21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 7, length 64
> 21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 8, length 64
> 21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 8, length 64
> 21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 9, length 64
> 21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 9, length 64
> 21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 10, length 64
> 21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 10, length 64
> 21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996
> ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length
> 72
> 21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
> UDP, length 4
> 21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 >
> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
> 21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 >
> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
> 21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
> (c6:89:38:52:b8:4b), length 28
> 21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
> (c6:89:38:52:b8:4b), length 28
> 21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 12, length 64
> 21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 12, length 64
> 21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
> (c6:89:38:52:b8:4b), length 28
> 21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
> Request from c6:89:38:52:b8:4b, length 332
> 21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
> (1e:bf:71:42:cc:98), length 28
> 21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212
> (1e:bf:71:42:cc:98), length 28
> 21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962:
> UDP, length 4
> 21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 >
> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64
> 21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 >
> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8
> 21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213
> (c6:89:38:52:b8:4b), length 28
> 21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length 28
> 21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP,
> Flags [...PA.], length 2
> 21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 24, length 64
> 21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 24, length 64
> 21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 25, length 64
> 21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 25, length 64
> 21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 26, length 64
> 21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 26, length 64
> 21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 27, length 64
> 21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 27, length 64
> 21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id
> 1326, seq 28, length 64
> 21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id
> 1326, seq 28, length 64
>
> As you can see, I get a lot of ARP requests, indicating, that my
> clients are loosing the connection farily often, resulting exactly in
> the observed behavior. I really would appreciate some help, or even a
> hinch in some direction what could lead further ...
>
> Has ever someone tried to use 20+ raspberries in a meshed network as
> nodes and hops?
>
> Thanks
> Richard
>
> On 21 December 2015 at 16:32,  <b.a.t.m.a.n-owner@lists.open-mesh.org> wrote:
>> Message rejected by filter rule match
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: no name <keinepostnurmuell@gmail.com>
>> To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n@lists.open-mesh.org>
>> Cc:
>> Date: Mon, 21 Dec 2015 16:32:36 +0100
>> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak connection
>> Right now I am working on a new set of measurements with the basis as follows:
>>
>> Raspberry Pi b+ with a LOGILINK WL0084B USB Stick on Jessie with Kernel 4.1.13+, batman2015-0
>>
>> I tested:
>>
>> Batman + Ad-Hoc
>> Batman + 802.11s
>> only 802.11s
>>
>> against each other. This lead to the following results:
>>
>> All of the above configurations show basically the same behaviour:
>> When pinging, the reply times from directly connected nodes are really stable (1-4ms, depends on the range).
>> When pinging via one hop in between, the network seems to take some breaks. A burst of pings (5-10) are replied pretty accurate, but always followed by a really long break of about 2-3 seconds
>>
>> The problem is less intense when using the batman configurations (->actually does rout better (: ).
>>
>> Facing this results I think I might be staring at a driver's issue, but still wanted to see if anyone here can help me with ideas.
>>
>> Thanks everyone for the time and help!
>>
>> Richard
>>
>>
>>> ---------- Forwarded message ----------
>>> From: Sven Eckelmann <sven@narfation.org>
>>> Date: 18 December 2015 at 18:30
>>> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak connection
>>> To: no name <keinepostnurmuell@gmail.com>
>>> Cc: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n@lists.open-mesh.org>
>>>
>>>
>>> On Friday 18 December 2015 18:22:40 no name wrote:
>>> > I made a little table were I tried wheezy against jessy and 802.11 as
>>> > someone suggested earlier in the mailing list to me. I placed the
>>> > raspberries next to each other on my table and tested through different
>>> > settings:
>>> >
>>> > ad-hoc+batman-2014.X@debian wheezy:          1m distance  .. 200 pings, 0%
>>> > paket loss, reply time -> (min,avg,max,mdev 1.2ms, 1.8ms, 6.4ms, 0.8ms)
>>> > ad-hoc+batman-2015.2@debian jessie:             1m distance  .. 200 pings,
>>> > 6% paket loss, reply time -> (min,avg,max,mdev 1.1ms, 170ms, 1400ms, 370ms)
>>> > 802.11s @debian jessie:                                  1m distance  ..
>>> > 200 pings, 0% paket loss, reply time -> (min,avg,max,mdev 1.05ms, 1.8ms,
>>> > 14ms, 1.5ms)
>>>
>>> Your "table" is incomplete. adhoc without batman-adv and meshpoint (802.11s
>>> without fwding+ttl=1)+batman-adv are missing. You also mixed two different
>>> batman-adv versions. Either you use the same batman-adv version everywhere or
>>> make sure that the kernel+wifi driver doesn't change. Changing multiple
>>> variables between two tests tests make the results more or less useless for
>>> comparisons.
>>>
>>> Kind regards,
>>>         Sven
>>>
>>
>>

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2015-12-30 19:14 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-17 20:52 [B.A.T.M.A.N.] Super high package loss and weak connection no name
2015-12-17 23:02 ` Ruben Kelevra
2015-12-18 13:23   ` no name
2015-12-18 13:43     ` Sven Eckelmann
2015-12-18 14:20       ` no name
2015-12-18 14:42         ` Sven Eckelmann
2015-12-18 16:12           ` no name
2015-12-18 16:40             ` Sven Eckelmann
     [not found]               ` <CAKrZ8yffDYcr6UCw2Yv7hqUFEBNZQ+nTU09dovL=PO3+Zqy7ig@mail.gmail.com>
2015-12-18 17:30                 ` Sven Eckelmann
2015-12-21 15:35                   ` no name
2015-12-29 12:42 no name
     [not found] ` <CAO9R-ZajkZRq-4==N3Y9aXkRCc3AhmPQiB_P4gSfKtu0X9W5tg@mail.gmail.com>
     [not found]   ` <CAO9R-ZZ=NT2Mh-OYtUpsZOYV=FHVjZjta+W1KeJU-v+HRgKaKg@mail.gmail.com>
2015-12-30 19:14     ` no name

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.