Bug #367
closedShow TQ in batctl neighbors
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
Updated by Sven Eckelmann about 6 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 about 6 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 over 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 over 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 over 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