Open-Mesh » batman-adv

renaming the ticket and making it a feature wish

Here the IRC discussion about it:

<hexa-> # batctl ping 2a:a9:cb:dd:79:4e
<hexa-> PING 2a:a9:cb:dd:79:4e (56:a3:b3:8b:aa:e4) 20(48) bytes of data
<hexa-> 20 bytes from 2a:a9:cb:dd:79:4e icmp_seq=1 ttl=50 time=0.17 ms
<hexa-> # batctl tp 2a:a9:cb:dd:79:4e
<hexa-> Destination unreachable
<hexa-> how does that match up?
<hexa-> the two nodes are using 2017.3 and 2017.4
<neoraider> Hmm, I think tp is more picky about which of a node's addresses you use
<neoraider> Is 2a:a9:cb:dd:79:4e an originator address or a tg entry?
<hexa-> originator address
<hexa-> it works with the mac in `batctl n`
<hexa-> except sent/throughput is 0 :)
<neoraider> hexa-, hmm, if I interpret this correctly, the originator address should be 56:a3:b3:8b:aa:e4 (what batctl ping shows in the parens)
<neoraider> Have you tried tp'ing that?
<hexa-> 2a:a9:cb:dd:79:4e is the mac of the target batadv interface
<hexa->        br-wan  00:25:90:0e:66:41    0.730s
<hexa-> that's the mac on the slave link
<hexa-> tp'ing the slave link results in 10s of 0 sent/0  throughput
<neoraider> hexa-, so it is a translation table entry and not the orginator address after all
<hexa-> hm, the originator address is derived from what?
<hexa-> the first slave in batadv?
<hexa-> because the vpn has 56:a3:b3:8b:aa:e4
<neoraider> Address of primary member interface
<neoraider> Which is the interface added first
<hexa-> Sent 325156896 Bytes.
<hexa-> Throughput: 30.92 MB/s (259.35 Mbps)
<hexa-> fair
<hexa-> a bit weird, but I'll take it :)
<neoraider> batctl ping resolves through the tg by itself, for tp, you need to pass the originator address directly
<hexa-> Usage: batctl tp [parameters] <MAC>
<neoraider> So just look it up in the tg, or use what batctl ping shows
<hexa-> yup, good call
<hexa-> # batctl ping 7a:fc:d9:66:55:11
<hexa-> PING 7a:fc:d9:66:55:11 (7a:fc:d9:66:55:11) 20(48) bytes of data
<hexa-> 20 bytes from 7a:fc:d9:66:55:11 icmp_seq=1 ttl=50 time=2.27 ms
<hexa-> # batctl tp 7a:fc:d9:66:55:11
<hexa-> Test duration 10110ms.
<hexa-> Sent 0 Bytes.
<hexa-> Throughput: 0 Bytes/s (0 Bps)
<hexa-> both gluon master nodes with 2017.4
<hexa-> gluon firewalling issue?
<neoraider> Unlikely
<hexa-> the two nodes are 10m apart an have dualband mesh connectivity
<hexa-> neither direction works
<neoraider> 7a:fc:d9:66:55:11 is not the primary addres of a Gluon node, the address of primary0 always ends with 3 or b
<neoraider> Try 7a:fc:d9:66:55:13
<hexa-> Throughput: 7.23 MB/s (60.69 Mbps)
<hexa-> so the ping tg lookup was deceptive
<hexa-> misleading
<neoraider> I'm not sure if there is a good way to determine the primary address of a remote node then :/
<hexa-> hehe
<neoraider> Except on Gluon, where you can follow this schema: http://gluon.readthedocs.io/en/v2017.1.x/dev/mac_addresses.html
<hexa-> aye
<hexa-> basically the mac of primary0
<neoraider> Exactly
<neoraider> We basically introduced primary0 to get a stable primary address

As you can see, the introduction of the ping translation function in batctl (as shown in the attached patch RFC-batctl-tp_meter-Translate-client-mac-and-IPs-to-orig.patch) will not help here. You can create a test setup based on Emulation_Debug and use following script to prepare the system:

#! /bin/sh

set -e
set -v

MAC_PART="$(ip link show enp0s3 | awk '/ether/ {print $2}'| sed -e 's/.*://' -e 's/[\n\ ].*//'|awk '{print ("0x"$1)*1 }')" 
IP_PART="$(echo $MAC_PART|awk '{ print $1+50 }')" 

ip link add dummybat type dummy
ip link set up dev dummybat

rmmod batman-adv || true
insmod /host/batman-adv/build/net/batman-adv/batman-adv.ko
batctl if add dummybat
batctl if add enp0s3
batctl it 100
batctl gw server

ip link set up dev enp0s3
ip link set up dev bat0
ip -4 addr flush dev bat0
ip addr add 192.168.5.${IP_PART}/24 dev bat0

exit 0

As you can see, the ping will work from node1 to node2 but not the tp_meter run with the patch RFC-batctl-tp_meter-Translate-client-mac-and-IPs-to-orig.patch:

batctl p 192.168.5.52
PING 192.168.5.52 (42:ae:b7:fa:be:1d) 20(48) bytes of data
20 bytes from 192.168.5.52 icmp_seq=1 ttl=50 time=1.39 ms
20 bytes from 192.168.5.52 icmp_seq=2 ttl=50 time=1.39 ms
20 bytes from 192.168.5.52 icmp_seq=3 ttl=50 time=5.74 ms
^C--- 192.168.5.52 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
rtt min/avg/max/mdev = 1.388/2.838/5.738/2.051 ms

root@bentobox:~# batctl p batctl p 02:ba:de:af:fe:02
PING 02:ba:de:af:fe:02 (02:ba:de:af:fe:02) 20(48) bytes of data
20 bytes from 02:ba:de:af:fe:02 icmp_seq=1 ttl=50 time=1.44 ms
20 bytes from 02:ba:de:af:fe:02 icmp_seq=2 ttl=50 time=1.72 ms
^C--- 02:ba:de:af:fe:02 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
rtt min/avg/max/mdev = 1.444/1.582/1.720/0.138 ms

root@bentobox:~# batctl tp 192.168.5.52
Test duration 10040ms.
Sent 516737268 Bytes.
Throughput: 49.08 MB/s (411.74 Mbps)

root@bentobox:~# batctl tp 02:ba:de:af:fe:02
Test duration 10308ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)

root@bentobox:~# batctl t 192.168.5.52
42:ae:b7:fa:be:1d

root@bentobox:~# batctl t 02:ba:de:af:fe:02
02:ba:de:af:fe:02

Problem is here how the tp packets are handled in the kernel vs. the rest of the batadv "ICMP" code. A way has to be found which is ok for the end user but also allows to test single links (for B.A.T.M.A.N. V).