Open-Mesh » batman-adv

I see various ping commands but I am left wondering what you think isn't working the way you think it should and more info what your test setups are. Would you mind adding that ? Thanks!

Hey Marek,

We got the following setup:

gateway (fastd) router A (adhoc wifi) router B

Client-Interfaces on Batman-adv have all mtu 1500. So batman-adv have to be able to transport packages with mtu 1500.

This was working on batman-adv 2014.2, but router a/b was upgraded today.

The transport via fastd have to be fragmented to mtu 1312 via batman-adv, this seem to work, since this command work:

ping6 fda0:747e:ab29:2144::c02 -s 1800

The IPv6 fda0:747e:ab29:2144::c02 is the gateway.

On the second router, with normal setting, the adhoc-wifi transmit the package without any fragmentation, because the mtu on client-interface is 1500, the package would be fragmented for this mtu via ip-fragmentation. After this, is it transmitted via batman-adv without fragmentation, because of the mtu 1532 of the adhoc-wifi.

If this packages now reach router A, router A need to fragment this packages, because the next mtu is 1312, so now should batman-adv fragment it. This seem to not work.

But further, I changed the adhoc-wifi to mtu 1312, so router B's batman-adv need to fragment the packages locally. Which means, Router A just have to retransmit the fragmented packages, this doesn't work either.

I'm sorry but I have to confirm this problem for 2014.3 too.

Gateway over Tunnel, and one Wifi-Hop (over a 2014.3 Node) to an 2014.3 Node:

[ruben@rig ~]$ ping6 fda0:747e:ab29:2144:ffff:10fe:ed40:a81e -s 1500
PING fda0:747e:ab29:2144:ffff:10fe:ed40:a81e(fda0:747e:ab29:2144:ffff:10fe:ed40:a81e) 1500 data bytes
^C
--- fda0:747e:ab29:2144:ffff:10fe:ed40:a81e ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms

Gateway over Tunnel, and one Wifi-Hop (over a 2014.2 Node) to an 2014.2 Node:

[ruben@rig ~]$ ping6 fda0:747e:ab29:2196:ffff:c04a:000b:6cc6 -s 1500
PING fda0:747e:ab29:2196:ffff:c04a:000b:6cc6(fda0:747e:ab29:2196:ffff:c04a:b:6cc6) 1500 data bytes
1508 bytes from fda0:747e:ab29:2196:ffff:c04a:b:6cc6: icmp_seq=1 ttl=64 time=88.7 ms
1508 bytes from fda0:747e:ab29:2196:ffff:c04a:b:6cc6: icmp_seq=3 ttl=64 time=75.4 ms
1508 bytes from fda0:747e:ab29:2196:ffff:c04a:b:6cc6: icmp_seq=4 ttl=64 time=141 ms
1508 bytes from fda0:747e:ab29:2196:ffff:c04a:b:6cc6: icmp_seq=5 ttl=64 time=244 ms
1508 bytes from fda0:747e:ab29:2196:ffff:c04a:b:6cc6: icmp_seq=6 ttl=64 time=75.1 ms
^C
--- fda0:747e:ab29:2196:ffff:c04a:000b:6cc6 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5004ms
rtt min/avg/max/mdev = 75.159/125.077/244.183/64.404 ms

I'm sorry, I have to admit that I haven't confirmed that the right version was build, my last post still referrer to batman-adv 2014.4, just building a new firmware with 2014.3 to test if it's introduced with 2014.4.

Thanks for the info. Let me try to describe the setup with my own words based on what I understood. Feel free to correct me.

We have a chain of batman-adv nodes using different MTUs (whether they are running fastd or not isn't all that relevant).

nodeA -- 1312 -- nodeB -- 1532 -- nodeC -- 1532 -- nodeD

Note that I am referring to the MTUs configured on the hard-interfaces to avoid confusion. That MTU on the bat0 interface is based on the lowest MTU of all configured hard interfaces. If packets are forwarded from one hard-iface to another the bat0 MTU does not matter.

In this setup, nodeB is the only batman-adv node with 2 different hard-iface MTUs.

• When pinging from nodeA towards nodeD which node can you successfully ping with a standard MTU of 1500 bytes ?
• Why do test with an packet size of 1800 bytes ? To enforce fragmentation ? Is that relevant for a real use case or is there another reason for that magic number ?
• Did you manage to verify whether or not the MTU problem is a regression ? Or is that yet to come ?

Hey Marek,

you got one thing wrong: there is no nodeD.

We got:

nodeA -- 1312 -- nodeB -- 1532 -- nodeC

Else I just tested the same Setup with Batman-adv 2014.3. The same result as 2014.4.

• When pinging from nodeA towards nodeD nodeC which node can you successfully ping with a standard MTU of 1500 bytes ?
  Batman-adv 2014.4: nodeB
  Batman-adv 2014.3: nodeB
  Batman-adv 2014.2: nodeB and nodeC

*Why do test with an packet size of 1800 bytes ? To enforce fragmentation ? Is that relevant for a real use case or is there another reason for that magic number ?
1800 Bytes are large enouth to get two nearly same size packets ...

*Did you manage to verify whether or not the MTU problem is a regression ? Or is that yet to come ?
Next I gonna build the same OpenWRT with batman-adv 2014.2 which works before, to be sure this is a bug in batman-adv itself.

Best regards

Ruben

After checking the 2014.3 changelog / patches I still don't see how an MTU behavior change could be introduced. But it may still be there. Let me know how your test goes.

If you feel confident enough that I can observe the same problem without running fastd I can also try to replicate it.

Coming back to my questions:

• Have you confirmed 2014.2 does indeed not exhibit the problem ? It would be immensely helpful to know if this is a regression or not.

• Can we replicate the fragmentation issue without running fastd ? Or: What is the easiest setup to replicate the matter ?

Please close this bug as invalid, with an older version of OpenWRT-trunk this issue does not appear. So it's located there.

Lastest version I tested, which works is r43777.

Thanks for all your help, and sorry for the waisted time, I try to find this bug now in the openwrt-repo.