search

FreifunkBremen / yanic

Yet another node info collector - for respondd to be used with meshviewer to Grafana (with influxdb or graphite)
https://freifunkbremen.github.io/yanic/
GNU Affero General Public License v3.0
20 stars 40 forks source link

Broken graph.json? #69

Closed joerg-d closed 7 years ago

joerg-d commented 7 years ago

We use Yanic. Our Meshviewer doesn't show the map but an error message (Cannot read property 'forEach' of undefined). It seems the graph.json or nodes.json is broken. Is there any tool to validate this? I could not find the error.

genofire commented 7 years ago

Normally not, there are a few communties which run it without Problem.

(I am not with a computer this weekend, are you on irc next week? the files look really strange - there are no graphs/neighbours and there are no mesh_interfaces in the nodes.json with which commit you have build? Is there anything on the logs?)

xf- commented 7 years ago

@joerg-d do you use latest meshviewer version? This shouldn't be a yanic issue more a ffrgb/meshviewer issue. We added a gateway filter and select all different gateways form nodes.

Problem: hostname "Gera-GreizerStr-001-Gateway" node_id "gwl1" -> d.nodeinfo.network.mesh.$network.interfaces.tunnel gibt es nicht, alle anderen haben tunnel.

If this is a normal case, then we need to add a condition.

genofire commented 7 years ago

Oh you are right @xf-: I mixed in graph.json graph and links.

joerg-d commented 7 years ago

I'm using the FFRGB Meshviewer from May, 18 (develop branch). It was working perfectly for some days. I think the problem occurs after adding or changing one node in our network that is sending wrong data. But I was unable to find the source. Thanks for the hint. I will look at "Gera-GreizerStr-001-Gateway" and report the result.

joerg-d commented 7 years ago

This shouldn't be a yanic issue more a ffrgb/meshviewer issue.

Yes. Should i move this to ffrgb/meshviewer?

If this is a normal case, then we need to add a condition.

The error occurs if "vpn" is true and there is no or an empty tunnel entry. This occurs because the gateway sends "l2tp" instead of "tunnel" (we also use hopglass, this makes sense there). Yanic filters the "l2tp" entry. What entry do you think the gateway should send? Generally Meshviever should be more relaxed if such a condition orrurs.

As a workaround we publish an additional dummy tunnel address for this gateway. Meshviewer is working again. But I cannot open the details of our gateways (we allow node_ids <> 12).

genofire commented 7 years ago

Why it announce l2tp instatt of tunnel? Is l2tp not a tunnel?

joerg-d commented 7 years ago

It shall show different things in hopglass: have a look at issue #50 I don't need this differentiation, but it would be nice if Yanic handles also "fastd", "l2tp" and "other" as "tunnel".

genofire commented 7 years ago

l2tp did not announce information over respondd -> (Or is there any package for this? - fastd found here)

l2tp should work and announce at the same way - the only different should be at nodeinfo.software.X where X ist a vpn software like the value fastd. On this way we could handle it and maybe will announce it like in PR https://github.com/FreifunkBremen/yanic/issues/45#issuecomment-305240741 discussed.

I do not think to support a extra fourth version of interface type l2tp - because it should be in tunnel. (and look like a break of design)

joerg-d commented 7 years ago

ext-respondd did announce "l2tp". Your proposal makes sense. In the meantime the admin of the gateway will send both entries: "tunnel" for yanic/meshviewer and "l2tp" for hopglass. I think we can close this issue. The remaining bug is in meshviewer. It is possible that a gateway has no tunnel, e.g. during an error condition. The map should still running without error message.