Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate nodes in meshviewer output #8

Closed
ghost opened this issue Dec 18, 2015 · 18 comments
Closed

Duplicate nodes in meshviewer output #8

ghost opened this issue Dec 18, 2015 · 18 comments
Labels

Comments

@ghost
Copy link

ghost commented Dec 18, 2015

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
Copy link
Author

ghost commented Dec 19, 2015

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
Copy link
Collaborator

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
Copy link
Author

ghost commented Dec 21, 2015

ffnord/ffmap-backend#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
Copy link
Author

ghost commented Dec 21, 2015

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
Copy link
Collaborator

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

@ghost
Copy link
Author

ghost commented Dec 22, 2015

That won't work
I'll write more later

@dereulenspiegel
Copy link
Collaborator

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
Copy link
Author

ghost commented Dec 22, 2015

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

@dereulenspiegel
Copy link
Collaborator

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

@ghost
Copy link
Author

ghost commented Dec 22, 2015

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
Copy link
Author

ghost commented Dec 22, 2015

Is that sufficient for you to fix this?

@dereulenspiegel
Copy link
Collaborator

I hope so, have to test it.

@dereulenspiegel
Copy link
Collaborator

@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
Copy link
Author

ghost commented Dec 23, 2015

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
Copy link
Author

ghost commented Dec 23, 2015

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
Copy link
Author

ghost commented Dec 24, 2015

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

@dereulenspiegel
Copy link
Collaborator

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
Copy link
Author

ghost commented Dec 24, 2015

EDIT: YAAY it's doin something:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant