Bug #367
closedShow TQ in batctl neighbors
Added by Martin Weinelt over 5 years ago. Updated about 4 years ago.
0%
Description
Currently batctl neighbors shows interface, mac and last-seen. It would be helpful if I could see the TQ towards the neighbor as well. This would reduce the need to grep the originators list for the chosen path.
Files
| neighbor_extend_dump.py (6.91 KB) neighbor_extend_dump.py | Sven Eckelmann, 12/18/2018 05:55 PM |
Updated by Sven Eckelmann over 5 years ago
This is currently a problem. The TQ (unlike the throughput from B.A.T.M.A.N. V) is a per batadv_neigh_ifinfo and not a per batadv_hardif_neigh_node. And the neighbor table dump prints the info from batadv_hardif_neigh_node and not batadv_neigh_ifinfo.
Getting the TQ for a hardif_neigh_node would require to:
- traverse all batadv_neigh_nodes to find the correct originator address of the neighbor
- traverse the batadv_neigh_node.ifinfo_list to find the correct interface
And I most likely missed something regarding the filtering of batadv_neigh_node in the first step. The splitted concept between originator and neighboring address was introduced with ELP - something which is not used by B.A.T.M.A.N. IV
Due to this problem, it seems to be more efficient to handle this mapping in userspace (over all entries) instead of doing it in the kernel and start a search for each entry.
Updated by Sven Eckelmann over 5 years ago
- File neighbor_extend_dump.py neighbor_extend_dump.py added
Here is an example implementation in python3 (with python3-pyroute2):
IF Neighbor last-seen TQ
vpn-pl be:02:25:d6:b4:af 4.604s 255
vpn-pl 36:fe:e7:cb:53:37 1.556s 255
vpn-pl 66:25:a7:48:37:ff 4.244s 255
vpn-pl 36:b8:c6:f6:09:f7 1.024s 255
vpn-pl be:ff:aa:b2:aa:bf 1.728s 255
vpn-pl 9e:d1:ef:18:b8:af 0.404s 254
vpn-pl 0e:68:8c:7c:0f:1f 4.464s 255
vpn-pl 3a:fe:63:02:7b:47 4.312s 255
vpn-pl 82:ab:f2:bf:67:0f 0.580s 255
vpn-pl a6:2e:81:c8:69:cf 2.028s 255
vpn-pl 62:d8:1e:4c:81:ef 4.800s 255
vpn-pl ee:dc:e8:f3:87:9f 3.716s 255
vpn-pl 26:d6:de:58:d8:bf 4.504s 247
vpn-pl e2:61:cd:1d:db:8f 4.200s 255
vpn-pl 0a:35:c3:ba:90:67 4.496s 255
vpn-pl de:d1:59:0f:12:07 2.192s 255
vpn-pl 9a:ff:32:44:c6:af 4.876s 255
vpn-pl 7a:9e:b4:9e:96:1f 0.728s 255
vpn-pl 32:ad:f4:8d:2f:27 2.140s 255
vpn-pl 42:ca:27:43:5f:ff 2.116s 255
vpn-pl 0e:a0:e5:a6:6e:ff 0.556s 254
vpn-pl b2:95:32:c5:78:b7 1.068s 255
vpn-pl 5a:47:22:b6:53:d7 3.092s 255
vpn-pl 2e:59:4a:d4:fa:6f 0.316s 253
vpn-pl e2:db:07:2a:d1:cf 3.032s 255
vpn-pl aa:9f:ae:79:f3:07 0.708s 255
vpn-pl 72:f6:a3:7c:06:77 4.484s 255
vpn-pl f2:01:9d:f4:42:af 2.552s 255
vpn-pl ee:11:2a:03:79:ef 0.644s 255
vpn-pl 6e:69:40:4d:8e:17 2.856s 255
vpn-pl 7e:6c:df:da:65:ff 2.676s 255
vpn-pl fe:2c:91:68:29:2f 0.320s 254
vpn-pl 46:89:c3:64:00:07 4.360s 255
vpn-pl 6e:ea:3f:81:86:9f 2.852s 255
vpn-pl 52:15:6a:a7:1c:37 0.900s 255
vpn-pl 0e:e3:7a:db:44:b7 5.032s 255
vpn-pl 3a:26:91:bd:44:af 2.460s 255
vxlan-pl 02:47:89:00:03:01 4.952s 251
vxlan-pl 02:47:89:00:06:01 3.536s 255
vxlan-pl 02:47:89:00:04:01 1.116s 255
vxlan-pl 02:47:89:00:05:01 1.656s 255
Updated by Marek Lindner about 4 years ago
- Status changed from New to Feedback
- Assignee changed from batman-adv developers to Martin Weinelt
Martin,
Sven's suggestion was probably meant for you. This ticket has been left unanswered for a while. Any objection to closing it ?
Thanks,
Marek
Updated by Marek Lindner about 4 years ago
- Status changed from Feedback to Closed
- Target version set to 2020.2
<hexa-> marec: no objection from me <hexa-> didn't notice the script until now
Updated by Sven Eckelmann about 4 years ago
- Status changed from Closed to Rejected
- Target version deleted (
2020.2)
There was no change in this for 2020.2. So please don't mark it as such. If you think it is invalid then mark it as rejected