ffdo / node-informant

Small utility to collect node information in a Freifunk network via announced
7 stars 4 forks source link

Duplicate nodes in meshviewer output #8

Closed ghost closed 8 years ago

ghost commented 8 years ago

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

ghost commented 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?

dereulenspiegel commented 8 years ago

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.

ghost commented 8 years ago

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.

ghost commented 8 years ago

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.

dereulenspiegel commented 8 years ago

So a viable solution would to just include the first BATMAN mesh MAC in the node list?

ghost commented 8 years ago

That won't work I'll write more later

dereulenspiegel commented 8 years ago

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.

ghost commented 8 years ago

The best thing would also be to read the nodeinfo details once they are needed to reduce load times and datq

dereulenspiegel commented 8 years ago

Exactly. The current approach won't work for larger communities or overview maps.

ghost commented 8 years ago

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
  },
ghost commented 8 years ago

Is that sufficient for you to fix this?

dereulenspiegel commented 8 years ago

I hope so, have to test it.

dereulenspiegel commented 8 years ago

@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.

ghost commented 8 years ago

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.

ghost commented 8 years ago

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.

ghost commented 8 years ago

If you don't mind I'll try to do this. It will result in some ugliness though.

dereulenspiegel commented 8 years ago

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.

ghost commented 8 years ago

EDIT: YAAY it's doin something:

http://gl.wupper.ffrl.de/meshviewer/#!v:g