Open-Mesh » batman-adv

I'm having two batman-adv nodes here, they are both connected directly with each other over an ethernet cable. Doing a ping6 directly over the interfaces as well as 'batctl ping' look fine:

ping6 fe80::222:b0ff:fe44:9402%eth2
PING fe80::222:b0ff:fe44:9402%eth2(fe80::222:b0ff:fe44:9402) 56 data bytes
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=1 ttl=64 time=0.855 ms
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=2 ttl=64 time=0.876 ms
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=3 ttl=64 time=0.854 ms
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=4 ttl=64 time=1.27 ms
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=5 ttl=64 time=0.897 ms
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=6 ttl=64 time=0.856 ms
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=7 ttl=64 time=0.867 ms
64 bytes from fe80::222:b0ff:fe44:9402: icmp_seq=8 ttl=64 time=0.856 ms
^C
--- fe80::222:b0ff:fe44:9402%eth2 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7001ms
rtt min/avg/max/mdev = 0.854/0.916/1.273/0.140 ms

./batctl p 00:22:b0:44:94:02
PING 00:22:b0:44:94:02 (00:22:b0:44:94:02) 19(47) bytes of data
19 bytes from 00:22:b0:44:94:02 icmp_seq=1 ttl=50 time=0.51 ms
19 bytes from 00:22:b0:44:94:02 icmp_seq=2 ttl=50 time=0.55 ms
19 bytes from 00:22:b0:44:94:02 icmp_seq=3 ttl=50 time=0.49 ms
19 bytes from 00:22:b0:44:94:02 icmp_seq=4 ttl=50 time=0.68 ms
19 bytes from 00:22:b0:44:94:02 icmp_seq=5 ttl=50 time=1.42 ms
19 bytes from 00:22:b0:44:94:02 icmp_seq=6 ttl=50 time=0.50 ms
19 bytes from 00:22:b0:44:94:02 icmp_seq=7 ttl=50 time=0.48 ms
19 bytes from 00:22:b0:44:94:02 icmp_seq=8 ttl=50 time=0.53 ms
^C--- 00:22:b0:44:94:02 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss
rtt min/avg/max/mdev = 0.484/0.647/1.416/0.932 ms

(batctl even seems a little faster, maybe because it is layer 2 only?)

Now both routers have an IPv6-address from the same subnet and as there is physically just this one connection and as those nodes are neighbours, I'd expect a similar latency over the mesh (bat0). But instead the latency is much higher, about 2-10 times. To also being able to test TCP/UDP-pings despite ICMP-pings, I did the tests with traceroute instead:

ICMP:

traceroute -N 1 -q 10 -n -I fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401
traceroute to fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401 (fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401), 30 hops max, 80 byte packets
 1  fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401  4.664 ms  9.693 ms  8.159 ms  7.773 ms  8.113 ms  3.789 ms  2.220 ms  8.162 ms  6.172 ms  8.099 ms

TCP:

traceroute -N 1 -q 10 -n -T fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401
traceroute to fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401 (fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401), 30 hops max, 80 byte packets
 1  fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401  4.264 ms  5.868 ms  11.233 ms  9.532 ms  7.247 ms  9.261 ms  6.325 ms  9.233 ms  7.186 ms  3.743 ms

And with this one... there has to be something wrong, but I don't know what (tried it a couple of times, always a similar result):

UDP:

traceroute -N 1 -q 10 -n -U fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401
traceroute to fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401 (fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401), 30 hops max, 80 byte packets
 1  fdef:ffc0:3dd7:f231:222:b0ff:fe44:9401  64.652 ms  60.034 ms  67.315 ms  61.872 ms  57.888 ms  55.837 ms  68.168 ms  61.051 ms  61.146 ms  60.231 ms

Even udp-tracerouting/pinging to the own IPv6-address instead of the neighbour's one has such high latencies.