ffrgb / meshviewer Goto Github PK

Is your feature request related to a problem? Please describe.

It would be nice if we could track how many babeld and batman-adv nodes and later OLSR nodes are in use where and with which version in Gluon Census. Currently it seems that Yanic is exporting this information to its nodes.json, but Meshviewer does not export it to its meshviewer.json.

Is your feature request related to a problem? Please describe.

We've got a lot of different firmware versions, not necessarily built by our core team, but by other enthusiast as well.
It is easy to lose the overview, which firmware is based on which gluon-version.

Describe the solution you'd like

It would save me quite some time, if I could see which update paths are relevant for our community, by listing gluon versions similar to firmware versions in the statistics tab.

Describe alternatives you've considered

Another alternative would be to write a separate tool, that focuses on Firmware migration paths in detail. I hope that won't be necessary and that the overview of meshviewer suffices.

Additional context

Gluon allows for for an scm override, which affects the gluon version.
If used correctly, this allows for even finer control over the grouping of similar built firmwares.
But that's offtopic context, which just makes this request interesting for us.

So i just opened an issue, which was deleted by someone. I can't get the output of this repo to work. It fails using node:12.12.0-stretch.
It was pointed out to me to follow the old instructions using

Maybe the old documentation still works:

https://github.com/rubo77/meshviewer-doc/blob/master/build_install.md

However this is exactly what i did. Does someone else know what can be done about that? Also what is the process for you to host the app?
Also please don't directly delete an issue next time as I'm not really interested in writing the same issue over and over again.

Attached is the log:

root@98dcb72b09a0:/app# node app
/app/app.js:41
var requirejs,require,define;!function(f){function p(t,e){return n.call(t,e)}function s(t,e){var n,i,o,r,s,a,u,l,h,c,d,f=e&&e.split("/"),p=M.map,m=p&&p["*"]||{};if(t){for(s=(t=t.split("/")).length-1,M.nodeIdCompat&&k.test(t[s])&&(t[s]=t[s].replace(k,"")),"."===t[0].charAt(0)&&f&&(t=f.slice(0,f.length-1).concat(t)),h=0;h<t.length;h++)if("."===(d=t[h]))t.splice(h,1),h-=1;else if(".."===d){if(0===h||1===h&&".."===t[2]||".."===t[h-1])continue;0<h&&(t.splice(h-1,2),h-=2)}t=t.join("/")}if((f||m)&&p){for(h=(n=t.split("/")).length;0<h;h-=1){if(i=n.slice(0,h).join("/"),f)for(c=f.length;0<c;c-=1)if((o=p[f.slice(0,c).join("/")])&&(o=o[i])){r=o,a=h;break}if(r)break;!u&&m&&m[i]&&(u=m[i],l=h)}!r&&u&&(r=u,a=l),r&&(n.splice(0,a,r),t=n.join("/"))}return t}function m(e,n){return function(){var t=i.call(arguments,0);return"string"!=typeof t[0]&&1===t.length&&t.push(null),u.apply(f,t.concat([e,n]))}}function _(e){return function(t){x[e]=t}}function g(t){if(p(b,t)){var e=b[t];delete b[t],L[t]=!0,r.apply(f,e)}if(!

ReferenceError: window is not defined
    at /app/app.js:41:79584
    at define.get (/app/app.js:41:65857)
    at Object.<anonymous> (/app/app.js:41:65948)
    at Module._compile (internal/modules/cjs/loader.js:956:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:973:10)
    at Module.load (internal/modules/cjs/loader.js:812:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1025:10)
    at internal/main/run_main_module.js:17:11

Thanks in advance.

Is your feature request related to a problem? Please describe.

Some in our community dislike the bright red mesh links, that company the few green links that are relevant to batman-adv.
This goes far enough for some of them to switch channels in order to have a better rate of "good" mesh links.

This breaks the redundancy/failover feature of local meshes and is in my experience hard to communicate, and mostly ignored.

Describe the solution you'd like

Not sure how complicated it would be to aggregate a list of links, that are part of a nodes next hop towards gateways;
but I think it would be pretty interesting to see all other (currently unused) links slightly desaturated.

My goal is not to eliminate either red or green links but to effectively highlight those, that are currently used.

Describe alternatives you've considered

I thought about the thickness of lines as well, but think partly desaturated unused links would give a cleaner look and a better overview of the effective topology.

Additional context

On the statuspage of nodes is a "via" section in the middle row:
http://[2001:678:978:214:c66e:1fff:fe9e:3c8c]/cgi-bin/status

I think I saw that in the graph or nodes json as well.

Let me know whether that's clear enough, or if I should provide a picture or something.

Is your feature request related to a problem? Please describe.

Currently, when embedding the map in an iframe, deep linking is problematic. The Demo at https://regensburg.freifunk.net/netz/karte/ has a partial solution which could easily improved.
Meshviewer handles deep links via URL anchors (like #!/de/map/a42bb0c909aa). The Demo hosts meshviewer on the same domain as the embedding page and polls the iframe for URL changes. This allows to change the main page URL when the embedded URL is changed. This will not work, if meshviewer runs on a separate domain. Also there's no handling for deep links, so an URL like https://regensburg.freifunk.net/netz/karte/node/14cc2097d7d6/ will always show the full map with no node selected.

Describe the solution you'd like

Modify mapviewer to advertise url anchor changes via window.postMessage (https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage). This allows to cunsume these events on the embedding window without polling and works also on cross-domain setups.

Provide a javascript as part of meshviewer that handles and embedded meshviewer:

• looks for an iframe with a certain ID that contains the meshviewer
• on window load or anchor changes, modifies the anchor of the iframe URL
• subscribed to postMessage events on the iframe and changes the window anchor

With this, embedding a meshviewer with working deep-linking would be as easy as

<iframe id="meshviewer-embedded" src="https://meshviewer.freifunk-sonstwo.org/"/>
<script src="https://meshviewer.freifunk-sonstwo.org/embed.js"/>

Wo finde ich die Dokumentation zum sauberen aufsetzen einer Meshviewer-Instanz?

Hi, I stumbled upon https://regensburg.freifunk.net/meshviewer/nodelist.json but it seems it is no longer updated/maintained.
Is there currently a version online where I get a .json representation of the land.regensburg.freifunk network?

Thanks in advance

Peter

I've updated my node from gluon2016-* to gluon2021-fastd (hood: Umgebung)
After the update there are two nodes with that name in the map's node list, one is inactive (red), the other is active (green).
Both point to the old node's details page, where the status is "offline".

Expected Behavior

The existing entry for the node is updated. There is only one node in the list and the link directs to a working details page.

Current Behavior

There are two entries in the node list. Both point the same deprecated details page.

Steps to Reproduce

One could setup a node with gluon2016 and then update it to gluon2021, but I believe there might be an easier way.

Your Environment

• Version before: 2016.2-exp20180205 / gluon-v2016.2.7-2-g3d824bd2
• Version now: v2021.1.1-FastD
• Model: TP-Link TL-WR940N v4

It would be quite cool if you could also filter the deprecation status on the map under statistics to directly display the devices that are no longer supported.

It would be really nice if additional to the Pictures/Images for nodeInfos, linkInfos and globalInfos it would be possoble to use iFrames.

Is your feature request related to a problem? Please describe.

Since Grafana 7.0 with the new image renderer plugin (Read more about this plugin here) the time needed to display the image has increased quite a bit.

Describe the solution you'd like

Adding support for iframes as statistic widget. This would allow to offload rendering to the client and also use zooming etc.

Describe alternatives you've considered

Continue to wait for images to load, i don't know 🤔

It would be great to apply filters via URL, this would allow us to share links with filters or store them as bookmarks.

It would for example provide the possibility, to share a link with router that still need an update via social media.

It would be most convenient if the URL would change each time you click on a filter in the statistics tab.

Currently in our multidomainsetup supernodes exist 15 (domain amount) times in our setup.
This looks a little weird in gravity-view but furthermore becomes unusable in normal map mode.

Especially when a supernode is emitting a location, all 15 instances of the same machine are stacked above aech other and make it a random game which domain is on top and clickable.

This is no easy task imo, as the current representation lacks either something like a merged view of all domains (ffnord/mesh-announce#73),
or an identifier of the machine, that's the same across its announced domains.

This could be based on @genofires efforts regarding the machine-id (ffnord/mesh-announce#37), as this is primarily a supernode problem, which more than often come with systemd these days.

Is your feature request related to a problem?

The part, where supernodes are stacked on top of each other in the normal map is irritating.

Describe the solution you'd like

For now I only want to extend the discussion in hackint#gluon earlier this day.

Describe alternatives you've considered

An alternative could be to destack overlapping nodes on the normal map by something similar to the graph view, where nodes won't sit on top each other.

Additional context

14:02 <xaver_> aiyion: what is missing for multi domain?
14:04 xaver_: Either there's wrong documentation and gluon determines the primary domain in a different way;
14:05 or the documentation is on point, which would imply potentially wrong usage of luas tables;
14:06 which does work for gluon apparently, but does not necessarily for anything, that uses a different parser, that is standard conform.
14:06 <xaver_> there is no documentation (public)
14:07 ? I provided a link to said documentation?
14:07 or which one are you referring to?
14:07 <xaver_> meshviewer
14:08 ah, sorry, was talking about gluon.
14:08 the meshviewer part was just for hexa who oredered a related feature.
14:08 <xaver_> I think we use the current multi domain setup in ffrgb & processing the data is in yanic
14:08 <xaver_> ah ok
14:08 meshviewer is not lacking anything except tsys :D
14:09 <xaver_> tsys?
14:09 meshviewer master does not provide primary_domain_code yet.
14:09 fuck.
14:09 <xaver_> use develop
14:09 *mesh-announce.
14:09 <xaver_> master branch is more or (less) outdated
14:10 i did not intend to talk about meshviewer in the last thre hours;
14:11 imho meshviewer lacks support of supernodes as one entity,
14:11 though I'm not sure how I'd implement that yet.
14:11 <xaver_> i saw the highlight from 9 march
14:11 Yep, now I got you.
14:11 forget what I wrote before imho ;)
14:13 <xaver_> I open irc maybe once per month. i like irc, but most channels are dead and moved to other services.
14:13 furthermore I think supernodes should be shown with square on the normal map as well and not just in the gravity-view.
14:14 true; I don't have strong feelings about irc, its just another protocol I wrapped in weechat, and I like that #hackint does not canstantly try to sell my data :)
14:18 <xaver_> we have no super nodes and no gws on the map. In general map and structure view are 2 completely different techniques with different features. The reason links are only colored with both ends in mesh view.
14:22 --> nrb ([email protected]) has joined #gluon
14:29 mhm
14:30 I think it'd be rather nice for (other) communities to have their supernodes on the map to reduce their abstractness for users.