Open-Mesh » batman-adv

Btw. make sure that you've also applied the BATMAN_V fixes from batman-adv 2017.2 in your tests:

• https://git.open-mesh.org/batman-adv.git/patch/76ef29071b0050f972a626747d034a494a7195d7
• https://git.open-mesh.org/batman-adv.git/patch/1e26904b364ceffe9ca7d6da7412e70fb2a04178

1. A isn't the nearest . all the nodes are with great proximity to one another.
2. the problem is temporary, the ping gets better about 2 minutes after the issue occurs.
3. ping from the laptop provides same results as from the gateway.

What about the patches? Can the BATMAN_V developers please get the originator + neighbor table output from each device (beside the laptop) for

1. node A is on and ping is fine
2. node A is turned off and ping is bad
3. node A is turned off and ping is good again

The output of

iw dev XXXXX station dump

Good question would also be whether you see this problem with BATMAN_IV.

The nodeA (which goes down) doesn't seem to be the best next hop for anything but itself and there is only a single interface involved. Just to be sure, what is your build and runtime configuration for batman-adv? Do you see the packet loss with ipv4 and batctl ping? Or what kind of traffic are you using to detect the packet loss. Are you sure that you don't have additional traffic towards the removed node which causes airtime saturation due to the retries by the wifi hw/rate control? Did you do a capture on a wifi monitor interface and the mesh0 interface to detect where the traffic is routed and where it is dropped?

Did you check

iw dev mesh0 station dump

Has somebody else a good idea for what to look for? Here are the logs but with mac address replaced with human readable names.

start¶

nodeGW¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeC     0.120s (       24.0) nodeC  [     mesh0]: nodeA  (        9.4) nodeB  (        6.3) nodeC  (       24.0)
nodeB     0.480s (       24.0) nodeB  [     mesh0]: nodeA  (        8.8) nodeC  (        9.0) nodeB  (       24.0)
nodeA     0.360s (       20.4) nodeA  [     mesh0]: nodeB  (        8.7) nodeC  (        9.6) nodeA  (       20.4)

nodeA¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeC     0.470s (       23.9) nodeC  [     mesh0]: nodeGW (       15.0) nodeB  (        7.5) nodeC  (       23.9)
nodeB     0.910s (       17.4) nodeB  [     mesh0]: nodeC  (        9.4) nodeGW (       16.9) nodeB  (       17.4)
nodeGW    0.210s (       17.4) nodeGW [     mesh0]: nodeB  (       12.0) nodeC  (       12.0) nodeGW (       17.4)

nodeB¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeC     0.170s (       17.9) nodeGW [     mesh0]: nodeA  (        9.5) nodeGW (       17.9) nodeC  (       12.7)
nodeGW    0.840s (       24.0) nodeGW [     mesh0]: nodeA  (        9.2) nodeC  (       12.0) nodeGW (       24.0)
nodeA     0.320s (       17.3) nodeA  [     mesh0]: nodeC  (        9.7) nodeGW (       11.7) nodeA  (       17.3)

nodeC¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeB     0.360s (       18.1) nodeB  [     mesh0]: nodeA  (        8.7) nodeGW (       13.4) nodeB  (       18.1)
nodeGW    0.530s (       23.9) nodeGW [     mesh0]: nodeA  (        9.2) nodeB  (       12.0) nodeGW (       23.9)
nodeA     0.060s (       22.6) nodeA  [     mesh0]: nodeB  (        8.6) nodeGW (        9.5) nodeA  (       22.6)

node A turned off - high packet loss¶

nodeGW¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeC     0.350s (       27.3) nodeC  [     mesh0]: nodeA  (       11.8) nodeB  (        6.8) nodeC  (       27.3)
nodeB     0.900s (       24.0) nodeB  [     mesh0]: nodeA  (        8.7) nodeC  (       11.3) nodeB  (       24.0)
nodeA    11.490s (       18.6) nodeA  [     mesh0]: nodeB  (        8.6) nodeC  (       11.5) nodeA  (       18.6)

nodeA¶

This was the disconnected node.

nodeB¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeC     0.270s (       13.3) nodeGW [     mesh0]: nodeA  (       11.8) nodeGW (       13.3) nodeC  (       12.7)
nodeGW    0.010s (       25.5) nodeGW [     mesh0]: nodeA  (        9.5) nodeC  (       12.7) nodeGW (       25.5)
nodeA    12.370s (       17.3) nodeA  [     mesh0]: nodeC  (       11.5) nodeGW (        9.3) nodeA  (       17.3)

nodeC¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeB     0.670s (       20.7) nodeB  [     mesh0]: nodeA  (        8.7) nodeGW (       12.0) nodeB  (       20.7)
nodeGW    0.130s (       25.7) nodeGW [     mesh0]: nodeA  (        9.5) nodeB  (       12.5) nodeGW (       25.7)
nodeA    14.410s (       23.1) nodeA  [     mesh0]: nodeB  (        8.6) nodeGW (        9.3) nodeA  (       23.1)

node A turned off - ping good again¶

nodeGW¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeC     0.110s (       24.0) nodeC  [     mesh0]: nodeA  (       11.8) nodeB  (        6.3) nodeC  (       24.0)
nodeB     0.630s (       24.0) nodeB  [     mesh0]: nodeA  (        8.7) nodeC  (        9.5) nodeB  (       24.0)
nodeA   128.700s (       18.6) nodeA  [     mesh0]: nodeB  (        8.6) nodeC  (       11.5) nodeA  (       18.6)

nodeA¶

Not connected.

nodeB¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeC     0.930s (       12.7) nodeC  [     mesh0]: nodeA  (       11.8) nodeGW (       12.0) nodeC  (       12.7)
nodeGW    0.850s (       24.0) nodeGW [     mesh0]: nodeA  (        9.5) nodeC  (       12.0) nodeGW (       24.0)
nodeA   131.530s (       17.3) nodeA  [     mesh0]: nodeC  (       11.5) nodeGW (        9.3) nodeA  (       17.3)

nodeC¶

  Originator      last-seen ( throughput)           Nexthop [outgoingIF]:   Potential nexthops ...
nodeB     0.640s (       19.1) nodeB  [     mesh0]: nodeA  (        8.7) nodeGW (       12.1) nodeB  (       19.1)
nodeGW    0.080s (       24.0) nodeGW [     mesh0]: nodeA  (        9.5) nodeB  (       12.0) nodeGW (       24.0)
nodeA   177.920s (       23.1) nodeA  [     mesh0]: nodeB  (        8.6) nodeGW (        9.3) nodeA  (       23.1)

Hey, i work with Moshe on this problem i have some of the details that you requested .
Can you explain what you mean by "build and runtime configuration for batman-adv" ?

I meant with "build configuration" the the options which you've enabled during build time like:

• CONFIG_BATMAN_ADV_DEBUG
• CONFIG_BATMAN_ADV_DEBUGFS
• CONFIG_BATMAN_ADV_BLA
• CONFIG_BATMAN_ADV_DAT
• CONFIG_BATMAN_ADV_NC
• CONFIG_BATMAN_ADV_MCAST
• CONFIG_BATMAN_ADV_BATMAN_V

The network and wireless options are interesting - but you've missed /etc/config/batman-adv and anything which you change manually during runtime.

The output of iw dev mesh0 station dump which you gave us is unfortunately meaningless at the moment. It is not known when you've taken it. And it doesn't look like you've taken it during each of the previously suggested stages (all connected, nodeA turned off and packet loss, nodeA turned off and good packet loss)

What about the other questions:

• Are you sure that you don't have additional traffic towards the removed node which causes airtime saturation due to the retries by the wifi hw/rate control?
• Did you do a capture on a wifi monitor interface and the mesh0 interface to detect where the traffic is routed and where it is dropped?

Right now it just looks like the latency increases by a lot when nodeA gets turned off. This could (but doesn't have to be) be related to some packets which gets retransmitted quite often by the wifi driver/hw when nodeA disappears (and therefore cannot ACK packets anymore). Would therefore be interesting to know whether this problem disappears when the wifi driver drops this station from its neighbor list. And it would of course be interesting what is actually be transmitted by the wifi device (hence the wifi monitor dumps).

My 2 cents:

It might be interesting to configure the adhoc interface with IP addresses and repeat the same test on that interface. Since this will bypass batman-adv (which is not needed in this simple scenario) it would tell us whether this is a problem created by batman-adv.

Assuming the adhoc-ping-test does not show the same timeout behavior, you could also play with batctl ping / batctl traceroute. The layer2 ping / traceroute might tell us if this is a layer 2 or layer 3 issue and can also show route changes (if any).

There is no monitor capture in the bz2.. Please refer to https://wireless.wiki.kernel.org/en/users/documentation/iw#modifying_monitor_interface_flags to see how to create a monitor interface. And please also create pcaps with "tcpdump -w /tmp/blabla.pcap ...."

The only thing which I saw in you captures is that there is traffic towards 04:18:d6:f6:49:f4 (which is the one which is offline). Most of it are ELP messages. But you told us that it also happens with BATMAN_IV and ELP doesn't exist in BATMAN_IV. So these should not be the culprit.

Did you try the test from #341#note-9? You can configure an ip manually on mesh0 using using

node1 $ ifconfig mesh0 192.168.25.1

node2 $ ifconfig mesh0 192.168.25.2
node2 $ ping -c 20 192.168.25.1

it's seems not better then the tests that we did before.

i meant to say that it seems better .

One more thing. i did the monitor only on mesh0. those are the interfaces that we have :

root@OpenWrt:/tmp# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
    link/ether 04:18:d6:cd:93:9b brd ff:ff:ff:ff:ff:ff
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 04:18:d6:cd:93:9b brd ff:ff:ff:ff:ff:ff
5: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc mq master bat0 state UP qlen 1000
    link/ether 04:18:d6:cc:93:9b brd ff:ff:ff:ff:ff:ff
6: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UNKNOWN qlen 1000
    link/ether 7e:1f:b4:f4:a5:cc brd ff:ff:ff:ff:ff:ff
7: fish0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 1000
    link/[803] 04:18:d6:cc:93:9b brd ff:ff:ff:ff:ff:ff

should i monitor any thing else ?

Sven Eckelmann wrote:

Did you try the test from #341#note-9? You can configure an ip manually on mesh0 using using

[...]

Hey,
does the test from #341#note-9 and the results that we got suggests that the issue is not with batman?

No, right now it still looks more like the queuing (fq codel + fair airtime?) and rate settings of your wifi stack/driver is to blame here.

And I told you about the monitor interface and dumps on it in #341#note-13 and #341#note-8. See #341#note-8 regarding you iw dev mesh0 station dump output. There are also other ideas in the ticket about things which can be tested to see whether batman-adv is to blame ("route changes", ...)

Sven Eckelmann wrote:

No, right now it still looks more like the queuing (fq codel + fair airtime?) and rate settings of your wifi stack/driver is to blame here.

I agree with Sven. The latency values in that test run might not be as high as during previous runs but generally, deactivating an unrelated WiFi neighbor should not increase latency anywhere. If anything, it should reduce latency.

Assuming the latency is created by the WiFi layer (Wifi driver, analog noise, queues, etc) you will always see that latency in batman-adv too. You could also start poking in the WiFi layer. For instance, check the driver you're using. Is it an old version with bugs ? Is it bleeding edge ? Are all test devices using Atheros AR934X ?

We heard about problems with the fair airtime implementation and appearing/disappearing clients (with and without batman-adv). So you could try to revert the changes from

• https://git.lede-project.org/?p=source.git;a=blob;f=package/kernel/mac80211/patches/320-ath9k-clean-up-and-fix-ath_tx_count_airtime.patch;h=a6a3bfca6d0be5c1541738ad3ef5e2e779781e39;hb=764cd09dd845864b0d45c6b1f914b81612a5dd28
• https://git.lede-project.org/?p=source.git;a=blob;f=package/kernel/mac80211/patches/344-ath9k-Introduce-airtime-fairness-scheduling-between-.patch;h=10c6573b8c1ff83196c19bdee4b2eafd1ff06e8e;hb=91fce81df6e99cec0876b9d4866bd86e7c49820f (or the upstream version https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63fefa050477b0974ab34f650e21a7cfc3b02d96 )

You should get in contact with Toke Høiland-Jørgensen <toke@toke.dk> and linux-wireless@vger.kernel.org when this is the reason for your problems.

Hey Sven,
Thank you for the pointers and help.
Before we reached out to Toke and linux-wireless@vger.kernel.org we wanted to redo the tests and make sure that we get the same results.
1. What we did last time was to ping through mesh0 interface as was suggested above. The test resulted in poor ping quality when one of the nodes was disconnected.
2. In the current test we configured an ad-hoc network on 3 nodes, With the configuration bellow:

root@OpenWrt:/# cat /etc/config/network                                         

config interface 'loopback'                                                     
        option ifname 'lo'                                                      
        option proto 'static'                                                   
        option ipaddr '127.0.0.1'                                               
        option netmask '255.0.0.0'                                              

config globals 'globals'                                                        
        option ula_prefix 'fdf8:4b2c:88b1::/48'                                 

config interface 'lan'                                                          
        option type 'bridge'                                                    
        option ifname 'eth0 wlan0'                                              
        option proto 'static'                                                   
        option ipaddr '192.168.1.12'                                            
        option netmask '255.255.255.0'                                          
        option ip6assign '60' 

root@OpenWrt:/# cat /etc/config/wireless                                        
config wifi-device  radio0                                                      
        option type     mac80211                                                
        option channel  36                                                      
        option hwmode   11a                                                     
        option path     'platform/ar934x_wmac'                                  
        option htmode   HT20                                                    

config wifi-iface                                                               
        option device   radio0                                                  
        option network  lan                                                     
        option mode     adhoc                                                   
        option ssid     OpenWrt                                                 
        option encryption none  

root@OpenWrt:/# ifconfig                                                        
br-lan    Link encap:Ethernet  HWaddr 04:18:D6:F7:49:E3                         
          inet addr:192.168.1.12  Bcast:192.168.1.255  Mask:255.255.255.0       
          inet6 addr: fdf8:4b2c:88b1::1/60 Scope:Global                         
          UP BROADCAST MULTICAST  MTU:1500  Metric:1                            
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0                    
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0                  
          collisions:0 txqueuelen:1000                                          
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)                                

eth0      Link encap:Ethernet  HWaddr 04:18:D6:F7:49:E3                         
          UP BROADCAST MULTICAST  MTU:1500  Metric:1                            
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0                    
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0                  
          collisions:0 txqueuelen:1000                                          
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)                                
          Interrupt:4                                                           

lo        Link encap:Local Loopback                                             
          inet addr:127.0.0.1  Mask:255.0.0.0                                   
          inet6 addr: ::1/128 Scope:Host                                        
          UP LOOPBACK RUNNING  MTU:65536  Metric:1                              
          RX packets:124 errors:0 dropped:0 overruns:0 frame:0                  
          TX packets:124 errors:0 dropped:0 overruns:0 carrier:0                
          collisions:0 txqueuelen:1                                             
          RX bytes:8544 (8.3 KiB)  TX bytes:8544 (8.3 KiB)                      

wlan0     Link encap:Ethernet  HWaddr 04:18:D6:F6:49:E3                         
          inet addr:172.16.0.201  Bcast:172.16.255.255  Mask:255.255.0.0        
          inet6 addr: fe80::618:d6ff:fef6:49e3/64 Scope:Link                    
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                    
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0                    
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0                  
          collisions:0 txqueuelen:1000                                          
          RX bytes:0 (0.0 B)  TX bytes:864 (864.0 B)    

The ping test was done from node A to node B and C, node C was disconnected. The result of that ping test :

root@OpenWrt:/# ping 172.16.0.202
PING 172.16.0.202 (172.16.0.202): 56 data bytes
64 bytes from 172.16.0.202: seq=0 ttl=64 time=1.502 ms
64 bytes from 172.16.0.202: seq=1 ttl=64 time=1.399 ms
64 bytes from 172.16.0.202: seq=2 ttl=64 time=1.398 ms
64 bytes from 172.16.0.202: seq=3 ttl=64 time=1.442 ms
64 bytes from 172.16.0.202: seq=4 ttl=64 time=1.402 ms
64 bytes from 172.16.0.202: seq=5 ttl=64 time=1.143 ms
64 bytes from 172.16.0.202: seq=6 ttl=64 time=1.777 ms
64 bytes from 172.16.0.202: seq=7 ttl=64 time=1.459 ms
64 bytes from 172.16.0.202: seq=8 ttl=64 time=1.411 ms
64 bytes from 172.16.0.202: seq=9 ttl=64 time=1.421 ms
64 bytes from 172.16.0.202: seq=10 ttl=64 time=1.407 ms
64 bytes from 172.16.0.202: seq=11 ttl=64 time=1.399 ms
64 bytes from 172.16.0.202: seq=12 ttl=64 time=1.458 ms
64 bytes from 172.16.0.202: seq=13 ttl=64 time=1.407 ms
64 bytes from 172.16.0.202: seq=14 ttl=64 time=1.397 ms
64 bytes from 172.16.0.202: seq=15 ttl=64 time=1.392 ms
64 bytes from 172.16.0.202: seq=16 ttl=64 time=1.636 ms
64 bytes from 172.16.0.202: seq=17 ttl=64 time=1.428 ms
64 bytes from 172.16.0.202: seq=18 ttl=64 time=1.381 ms
64 bytes from 172.16.0.202: seq=19 ttl=64 time=1.406 ms
64 bytes from 172.16.0.202: seq=20 ttl=64 time=1.400 ms
64 bytes from 172.16.0.202: seq=21 ttl=64 time=1.403 ms
64 bytes from 172.16.0.202: seq=22 ttl=64 time=7.701 ms
64 bytes from 172.16.0.202: seq=23 ttl=64 time=1.417 ms
64 bytes from 172.16.0.202: seq=24 ttl=64 time=1.413 ms
64 bytes from 172.16.0.202: seq=25 ttl=64 time=1.407 ms
64 bytes from 172.16.0.202: seq=26 ttl=64 time=1.396 ms
64 bytes from 172.16.0.202: seq=27 ttl=64 time=5.830 ms
64 bytes from 172.16.0.202: seq=28 ttl=64 time=1.395 ms
64 bytes from 172.16.0.202: seq=29 ttl=64 time=1.397 ms
64 bytes from 172.16.0.202: seq=30 ttl=64 time=1.401 ms
64 bytes from 172.16.0.202: seq=31 ttl=64 time=6.423 ms
64 bytes from 172.16.0.202: seq=32 ttl=64 time=1.434 ms
64 bytes from 172.16.0.202: seq=33 ttl=64 time=1.406 ms
64 bytes from 172.16.0.202: seq=34 ttl=64 time=1.396 ms
64 bytes from 172.16.0.202: seq=35 ttl=64 time=1.408 ms
64 bytes from 172.16.0.202: seq=36 ttl=64 time=1.424 ms
64 bytes from 172.16.0.202: seq=37 ttl=64 time=1.456 ms
64 bytes from 172.16.0.202: seq=38 ttl=64 time=8.808 ms
64 bytes from 172.16.0.202: seq=39 ttl=64 time=1.409 ms
64 bytes from 172.16.0.202: seq=40 ttl=64 time=1.520 ms
64 bytes from 172.16.0.202: seq=41 ttl=64 time=1.458 ms
64 bytes from 172.16.0.202: seq=42 ttl=64 time=1.450 ms
64 bytes from 172.16.0.202: seq=43 ttl=64 time=1.393 ms
64 bytes from 172.16.0.202: seq=44 ttl=64 time=1.765 ms
64 bytes from 172.16.0.202: seq=45 ttl=64 time=1.436 ms
64 bytes from 172.16.0.202: seq=46 ttl=64 time=1.406 ms
64 bytes from 172.16.0.202: seq=47 ttl=64 time=1.408 ms
64 bytes from 172.16.0.202: seq=48 ttl=64 time=5.378 ms
64 bytes from 172.16.0.202: seq=49 ttl=64 time=1.416 ms
64 bytes from 172.16.0.202: seq=50 ttl=64 time=1.476 ms
64 bytes from 172.16.0.202: seq=51 ttl=64 time=1.403 ms
64 bytes from 172.16.0.202: seq=52 ttl=64 time=1.403 ms
64 bytes from 172.16.0.202: seq=53 ttl=64 time=1.464 ms
64 bytes from 172.16.0.202: seq=54 ttl=64 time=1.407 ms
64 bytes from 172.16.0.202: seq=55 ttl=64 time=1.412 ms
64 bytes from 172.16.0.202: seq=56 ttl=64 time=1.416 ms
64 bytes from 172.16.0.202: seq=57 ttl=64 time=2.249 ms
64 bytes from 172.16.0.202: seq=58 ttl=64 time=1.408 ms
64 bytes from 172.16.0.202: seq=59 ttl=64 time=1.407 ms
64 bytes from 172.16.0.202: seq=60 ttl=64 time=1.405 ms
64 bytes from 172.16.0.202: seq=61 ttl=64 time=1.422 ms
64 bytes from 172.16.0.202: seq=62 ttl=64 time=1.406 ms
64 bytes from 172.16.0.202: seq=63 ttl=64 time=1.433 ms
64 bytes from 172.16.0.202: seq=64 ttl=64 time=1.408 ms
64 bytes from 172.16.0.202: seq=65 ttl=64 time=1.400 ms
64 bytes from 172.16.0.202: seq=66 ttl=64 time=1.404 ms
64 bytes from 172.16.0.202: seq=67 ttl=64 time=1.430 ms
64 bytes from 172.16.0.202: seq=68 ttl=64 time=1.426 ms
64 bytes from 172.16.0.202: seq=69 ttl=64 time=1.407 ms
64 bytes from 172.16.0.202: seq=70 ttl=64 time=3.037 ms
64 bytes from 172.16.0.202: seq=71 ttl=64 time=1.448 ms
64 bytes from 172.16.0.202: seq=72 ttl=64 time=1.419 ms
64 bytes from 172.16.0.202: seq=73 ttl=64 time=1.414 ms
64 bytes from 172.16.0.202: seq=74 ttl=64 time=1.452 ms
64 bytes from 172.16.0.202: seq=75 ttl=64 time=1.422 ms
64 bytes from 172.16.0.202: seq=76 ttl=64 time=1.725 ms
64 bytes from 172.16.0.202: seq=77 ttl=64 time=1.416 ms
64 bytes from 172.16.0.202: seq=78 ttl=64 time=1.412 ms
64 bytes from 172.16.0.202: seq=79 ttl=64 time=1.453 ms
64 bytes from 172.16.0.202: seq=80 ttl=64 time=1.439 ms
64 bytes from 172.16.0.202: seq=81 ttl=64 time=1.413 ms
64 bytes from 172.16.0.202: seq=82 ttl=64 time=1.413 ms
64 bytes from 172.16.0.202: seq=83 ttl=64 time=1.411 ms
64 bytes from 172.16.0.202: seq=84 ttl=64 time=1.561 ms
64 bytes from 172.16.0.202: seq=85 ttl=64 time=1.411 ms
64 bytes from 172.16.0.202: seq=86 ttl=64 time=1.428 ms
64 bytes from 172.16.0.202: seq=87 ttl=64 time=2.627 ms
64 bytes from 172.16.0.202: seq=88 ttl=64 time=1.405 ms
64 bytes from 172.16.0.202: seq=89 ttl=64 time=1.404 ms
^C
--- 172.16.0.202 ping statistics ---
90 packets transmitted, 90 packets received, 0% packet loss
round-trip min/avg/max = 1.143/1.772/8.808 ms

3. With Batman setup we also did arping test, the results dont show any delay while disconnecting one of the nodes :

root@OpenWrt:/# arping -I br-lan 192.168.1.12
ARPING 192.168.1.12 from 192.168.1.13 br-lan
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.737ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.679ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.683ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.687ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.684ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.682ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.679ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.687ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.684ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.687ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.684ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.689ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.687ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.688ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.681ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.686ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.689ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.691ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.684ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.689ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.691ms
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.687ms                    
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.690ms                    
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.680ms                    
Unicast reply from 192.168.1.12 [80:2A:A8:B9:3E:14]  0.686ms                    
Unicast reply fr^CSent 26 probes (1 broadcast(s))                               
Received 26 response(s)                       

How can we further investigate the issue ?

Thanks !

Sorry, but I will not provide any help here anymore because you do everything - but not what I've asked for.

Hi Sven,

Sorry, we forgot to mention that as we use OpenWrt, we don't have the fair airtime implementation in our code at all.

so there is nothing to revert.

david lichterov wrote:

How can we further investigate the issue ?

You're basically telling us everything works as it should and ask us why it works ? I hope you understand the irony ? :-)

From an engineering perspective I'd say: If the problem disappeared something changed in your setup. What that something is we obviously don't know. We only have the information you provided. Could be anything from the Openwrt toolchain, driver versions, etc up to the WiFi environment.

Assuming the issue is gone, why don't you go ahead with whatever you set out to do before you opened this ticket ? In case the problem shows up again, you can always re-open the ticket or create a new one or visit our IRC channel. It is really hard to make suggestions remotely what to do to trigger some problem only you have seen.

Hi Marek,

1. Using BATMAN on Rocketm5 with OpenWrt:
   • PING quality is bad after node disconnection (as mentioned in the initial post).
   • ARPING quality is good after node disconnection .
   • PING via mash0 as in post #12 quality is good after node disconnection .
2. Using ADHOC connections on Rocketm5 with OpenWrt:
   • PING+ARPING quality is good after node disconnection
3. Using BATMAN on RPI3 with Debain:
   • PING+ARPING quality is good after node disconnection .

We still see the issue on BATMAN + OpenWrt.

Thanks for the summary.

Let me sum up what we know so far:

1. Using BATMAN on Rocketm5 with OpenWrt:
   • PING quality is bad after node disconnection (as mentioned in the initial post).
   • ARPING quality is good after node disconnection .
   • PING via mash0 as in post #12 quality is good after node disconnection .

Can you also help me understand how you come to the 'quality is good' conclusion for the pure adhoc mode test ? Doesn't ticket update 13 show the latency go up on disconnect ?

1. Using ADHOC connections on Rocketm5 with OpenWrt:
   • PING+ARPING quality is good after node disconnection

Is this test case different from the previous 'good' or the same ? Mesh0 simply is pure adhoc mode, right ?

1. Using BATMAN on RPI3 with Debain:
   • PING+ARPING quality is good after node disconnection .

Is the batman-adv version in all test scenarios the same ?

Marek Lindner wrote:

Thanks for the summary.

Let me sum up what we know so far:

1. Using BATMAN on Rocketm5 with OpenWrt:
   • PING quality is bad after node disconnection (as mentioned in the initial post).
   • ARPING quality is good after node disconnection .
   • PING via mash0 as in post #12 quality is good after node disconnection .

Can you also help me understand how you come to the 'quality is good' conclusion for the pure adhoc mode test ? Doesn't ticket update 13 show the latency go up on disconnect ?

you are right, I got confused. the ping test results in that case were not good.

1. Using ADHOC connections on Rocketm5 with OpenWrt:
   • PING+ARPING quality is good after node disconnection

Is this test case different from the previous 'good' or the same ? Mesh0 simply is pure adhoc mode, right ?

The results were good please see post 20. I don't know if Mesh0 is simply adhoc mode. just followed Sven's orders on ticket 12.

1. Using BATMAN on RPI3 with Debain:
   • PING+ARPING quality is good after node disconnection .

Is the batman-adv version in all test scenarios the same ?

yes.

Moshe Hoori wrote:

Is this test case different from the previous 'good' or the same ? Mesh0 simply is pure adhoc mode, right ?

The results were good please see post 20.

To be honest, ticket update 20 confuses me because I don't understand which output is linked to what test and what is different from the expected. At first read, I thought all quoted text (config & tests) were coming from Openwrt and show no issue. In the end, the update states also no issue with Debian. Hence my conclusion in update 23: Everything is good ? In the following update you state that Openwrt still does not work ..

I don't know if Mesh0 is simply adhoc mode.

The second quote part of update 20 shows it: wifi-iface => radio0, mode => adhoc. The interface name can be chosen, it is the mode that matters.

Let me try to summarize what I understand so far while (partially) ignoring update 20 for now due to confusion on my end:

• Debian on RPI with or without batman-adv does not exhibt any spikes in latency when a nearby WiFi node is turned off.

• Openwrt with or without batman-adv exhibits spikes in latency when a nearby WiFi node is turned off.

The same batman-adv versions were deployed in all tests.

Please correct me if I got it wrong.

Based on the above, wouldn't it be safe to assume the problem lies somewhere in Openwrt (Wifi or Kernel or ...) ? There still might be a problem with batman-adv but until the underlying latency spikes haven't been resolved, it makes little sense to poke in batman-adv. Because batman-adv relies on the WiFi layer for the actual packet transmission we can not tackle a problem in batman-adv while the WiFi layer is misbehaving.

Marek Lindner wrote:

Moshe Hoori wrote:

Is this test case different from the previous 'good' or the same ? Mesh0 simply is pure adhoc mode, right ?

The results were good please see post 20.

To be honest, ticket update 20 confuses me because I don't understand which output is linked to what test and what is different from the expected. At first read, I thought all quoted text (config & tests) were coming from Openwrt and show no issue. In the end, the update states also no issue with Debian. Hence my conclusion in update 23: Everything is good ? In the following update you state that Openwrt still does not work ..

I don't know if Mesh0 is simply adhoc mode.

The second quote part of update 20 shows it: wifi-iface => radio0, mode => adhoc. The interface name can be chosen, it is the mode that matters.

Let me try to summarize what I understand so far while (partially) ignoring update 20 for now due to confusion on my end:

• Debian on RPI with or without batman-adv does not exhibt any spikes in latency when a nearby WiFi node is turned off.

that's right

• Openwrt with or without batman-adv exhibits spikes in latency when a nearby WiFi node is turned off.

using batman-adv, pinging as in ticket 12 results bad ping quality (this is what I referred to as pinging mesh0).
without batman-adv, using adhoc network configuration, results good ping quality.

The same batman-adv versions were deployed in all tests.

Please correct me if I got it wrong.

Based on the above, wouldn't it be safe to assume the problem lies somewhere in Openwrt (Wifi or Kernel or ...) ? There still might be a problem with batman-adv but until the underlying latency spikes haven't been resolved, it makes little sense to poke in batman-adv. Because batman-adv relies on the WiFi layer for the actual packet transmission we can not tackle a problem in batman-adv while the WiFi layer is misbehaving.

Moshe Hoori wrote:

using batman-adv, pinging as in ticket 12 results bad ping quality (this is what I referred to as pinging mesh0).
without batman-adv, using adhoc network configuration, results good ping quality.

Sorry, there seems to be some misconception here. Pinging as described in ticket update 12 is without batman-adv. Ticket 12 even references my suggestion to test the pure WiFi layer without batman-adv which I suggested in ticket update 9. Ticket update 13 then shows the test results of pure WiFi without batman-adv and depicts a spike in latency. No ?

Hi Marek,
sorry for being unclear about that.

1. what we did in the test from post 12, is testing while BATMAN-ADV is installed, and bat0 is up.
2. what we did in the test from post 20, is testing while BATMAN-ADV is not installed at all.

today we tested (1) again. and it seems the the issue reoccurs only if bat0 interface is up.

Moshe Hoori wrote:

Hi Marek,
sorry for being unclear about that.

1. what we did in the test from post 12, is testing while BATMAN-ADV is installed, and bat0 is up.
2. what we did in the test from post 20, is testing while BATMAN-ADV is not installed at all.

today we tested (1) again. and it seems the the issue reoccurs only if bat0 interface is up.

Sorry, I don't want to continue this discussion here. The information you provide appears contradicting and unclear which makes it hard to help you. Just now, you throw in another aspect that wasn't discussed before: What is installed and what is not.

I recommend you either join our IRC channel for a more real-time discussion with questions & answers or you provide a comprehensive overview about what is working and what is not. Right now I can't tell.