Closed ghost closed 8 years ago
More information: I noticed the assignment of the id and node_id in the graph.json is duplicate for all nodes. This could be one cause. @dereulenspiegel can you reproduce this? Or rather: Do you have a setup without this bug?
I can see this behaviour in the Dortmund Community too. I reverse engineered the specification for the graph.json, since I couldn't find a formal specification. Is there a good document on how to assemble the graph.json correctly?
As you can see the node 10feede6b0c2
has two entries in the nodes list, but each time with a different mac address. This is currently caused because this node has two interfaces on which batman is running and it is reporting neighbours for both:
{
"batadv": {
"12:01:ee:e6:b0:c2": {
"neighbours": {
"62:e6:28:9a:db:de": {
"lastseen": 138.12,
"tq": 11
},
"c6:71:20:bd:04:ca": {
"lastseen": 0,
"tq": 11
},
"ea:97:f7:4a:fa:5c": {
"lastseen": 3.48,
"tq": 196
},
"ea:97:f7:4a:fa:82": {
"lastseen": 1.86,
"tq": 206
}
}
},
"12:02:ed:e6:b0:c2": {
"neighbours": {
"04:be:4a:bc:0d:10": {
"lastseen": 0.4,
"tq": 255
},
"04:be:4a:bc:0d:40": {
"lastseen": 0.19,
"tq": 255
}
}
}
},
"node_id": "10feede6b0c2"
}
Currently I don't know how to handle this differently.
https://github.com/ffnord/ffmap-backend/issues/70 So unfortunately no docs.. I'll take a look at a nodes.json produced by ffmap-backend to figure out what's going on, but that won't be enough for a real documentation.
there isn't a node id for every mac it seems to me that only one mac of a node is linked with a node id and the others aren't
EDIT: I got it: They are linked by order. Every unlinked mac belongs to the last mentioned node id.
So a viable solution would to just include the first BATMAN mesh MAC in the node list?
That won't work I'll write more later
Please do. The whole meshviewer stuff is badly documented and needs to be retired as well (alongside ffmap-backend). So I would like to implement sufficient support for this as easy as possible and then put energy (together with others) into better solutions.
The best thing would also be to read the nodeinfo details once they are needed to reduce load times and datq
Exactly. The current approach won't work for larger communities or overview maps.
So this is the structure you need:
{
"node_id": "node1 id",
"id": "node1 mac1"
},
{
"id": "node1 mac2" //belongs to node1 because that was the last nodeid mentioned
},
{
"node_id": "node2 id",
"id": "node2 mac" //only has one
},
{
"node_id": "node3 id",
"id": "node3 mac1"
},
{
"id": "node3 mac2"
},
{
"id": "node3 mac3" //still belongs to node3 because that was the last nodeid mentioned
},
Is that sufficient for you to fix this?
I hope so, have to test it.
@plumpudding I hope that this issue is resolved now. I added an unit test, which tests for this structure now. But nothing better than a real world test :) Especially against for undocumented formats.
I give up.. It's better already. The nodes aren't duplicate, but MoL connections don't show up.
When I compared it to an original json, I noticed that my offloader has only one mac linked to it, but it (if my structure is right that is) and it still has a vpn and a MoL connection. On the gluon-collector json it has 3 macs, but not a single connection in the meshviewer.
New approach: There is always only one mac linked to one nodeid or one mac alone without any linked nodeid. If a nodeid has serveral macs only one is in the graph.json list. Any link to the node - no matter to which of the node's mac is connected to this (primary) mac.
If you don't mind I'll try to do this. It will result in some ugliness though.
Please do, I can review a pull request. But since the format meshviewer uses is much worse than initially thought and one of my goals is to move to more sane formats, I don't want to invest too much time in such legacy formats. Probably it also makes sense to attack this problem on the site of meshviewer since the format introduced there clearly is problematic. But since meshviewer has a rather tedious contribution process, unfortunately I decided to not contribute to this project.
EDIT: YAAY it's doin something:
http://gl.wupper.ffrl.de:8080/graph.json search for 10feede6b0c2
http://map.gl.wupper.ffrl.de/ go to the graph and click some nodes in a mesh sometimes you will click a node in a mesh and will be 'redirected' to a duplicate at the other end, which doesn't have any links