https://www.open-mesh.org/https://www.open-mesh.org/favicon.ico?16699090422016-11-04T14:56:10ZOpen Meshbatman-adv - Feature #310: tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/310?journal_id=9572016-11-04T14:56:10ZSven Eckelmann
<ul></ul><p>Just as info for Antonio: I can see tpmeter packets in the dump (in both directions) when using the filter</p>
<pre>(batadv.batman.packet_type == 0x43) && (batadv.icmp.msg_type == 15)</pre>
<p>Martin: "Sent 0 Bytes." is about the acked packets. So packets may have been sent but the sender thinks that no packets were acked.</p> batman-adv - Feature #310: tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/310?journal_id=13572018-02-27T17:29:12ZSven Eckelmann
<ul></ul><p>Was da:ff:61:00:05:03 really the primaryif address of the remote?</p> batman-adv - Feature #310: tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/310?journal_id=13582018-02-27T20:43:52ZMartin Weineltmartin@darmstadt.freifunk.net
<ul></ul><p>Our infrastructure has massively changed so I can't say that for sure.</p>
<p>However the actual issue seems to be that the primaryif address is unnecessarily hard to determine for a remote node that I don't have access to. Consider this:</p>
<p>What are my neighbours?<br /><pre><code class="text syntaxhl" data-language="text"># batctl n
[B.A.T.M.A.N. adv 2017.4, MainIF/MAC: primary0/42:f7:31:6f:6c:cb (bat0/e8:94:f6:69:4d:86 BATMAN_IV)]
IF Neighbor last-seen
br-wan 00:25:90:0e:66:41 0.520s
mesh0 3e:df:5f:8e:b3:41 1.900s
mesh0 96:8d:78:23:af:1c 3.620s
mesh0 7a:fc:d9:66:55:15 0.750s
mesh0 72:f2:91:1d:c9:f9 4.530s
</code></pre></p>
<p>Let's ping … that one!<br /><pre><code class="text syntaxhl" data-language="text"># batctl ping 96:8d:78:23:af:1c
PING 96:8d:78:23:af:1c (96:8d:78:23:af:1c) 20(48) bytes of data
20 bytes from 96:8d:78:23:af:1c icmp_seq=1 ttl=50 time=3.41 ms
20 bytes from 96:8d:78:23:af:1c icmp_seq=2 ttl=50 time=0.47 ms
20 bytes from 96:8d:78:23:af:1c icmp_seq=3 ttl=50 time=0.48 ms
20 bytes from 96:8d:78:23:af:1c icmp_seq=4 ttl=50 time=0.45 ms
^C--- 96:8d:78:23:af:1c ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 0.452/1.203/3.412/1.275 ms
</code></pre></p>
<p>And what's the throughput?<br /><pre><code class="text syntaxhl" data-language="text"># batctl tp 96:8d:78:23:af:1c
Test duration 10110ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)
</code></pre></p>
<p>Turn's out … that is not the primary address of the node, but it is enough for ping, why not tp? Feels a bit like unexpected behaviour.</p> batman-adv - Feature #310: tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/310?journal_id=13622018-02-28T01:07:28ZAntonio Quartulli
<ul></ul><p>Martin Weinelt wrote:</p>
<blockquote>
<p>Turn's out … that is not the primary address of the node, but it is enough for ping, why not tp? Feels a bit like unexpected behaviour.</p>
</blockquote>
<p>the address you feed to ping/tr goes through a conversion routine which will extract the proper address to use for you. You can even use an IP and this routine will make the command work anyway.</p>
<p>tp_meter does not use the same routine yet, so you need to specify the correct originator address when performing a test. Some ideas about adapting tp_meter to use this routine have been fluctuating around, but nothing has been implemented yet.</p> batman-adv - Feature #310: tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/310?journal_id=13642018-02-28T01:15:01ZMartin Weineltmartin@darmstadt.freifunk.net
<ul></ul><p>tp_meter works just fine when using the primary address for the remote node.</p> batman-adv - Feature #310: tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/310?journal_id=13652018-02-28T01:16:55ZAntonio Quartulli
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li><li><strong>Subject</strong> changed from <i>tpmeter: nothing sent, zero throughput</i> to <i>tpmeter: convert any provided address to proper originator address</i></li></ul><p>renaming the ticket and making it a feature wish</p> batman-adv - Feature #310: tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/310?journal_id=13682018-02-28T09:18:31ZSven Eckelmann
<ul><li><strong>File</strong> <a href="/attachments/842">RFC-batctl-tp_meter-Translate-client-mac-and-IPs-to-orig.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/842/RFC-batctl-tp_meter-Translate-client-mac-and-IPs-to-orig.patch">RFC-batctl-tp_meter-Translate-client-mac-and-IPs-to-orig.patch</a> added</li></ul><p>Here the IRC discussion about it:</p>
<pre>
<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
</pre>
<p>As you can see, the introduction of the ping translation function in batctl (as shown in the attached patch <a class="attachment" href="https://www.open-mesh.org/attachments/842">RFC-batctl-tp_meter-Translate-client-mac-and-IPs-to-orig.patch</a>) will not help here. You can create a test setup based on <a class="wiki-page new" href="https://www.open-mesh.org/projects/open-mesh/wiki/Emulation_Debug">Emulation_Debug</a> and use following script to prepare the system:</p>
<pre>
#! /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
</pre>
<p>As you can see, the ping will work from node1 to node2 but not the tp_meter run with the patch <a class="attachment" href="https://www.open-mesh.org/attachments/842">RFC-batctl-tp_meter-Translate-client-mac-and-IPs-to-orig.patch</a>:</p>
<pre>
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
</pre>
<p>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).</p>