new statuspage

[tcatm]

I'll track progress on the new statuspage in this issue.

• [x] get API merged

  Frontend

• [x] remove dependency on promises
• [x] show MAC in addition to nodename
• [x] remove mgmtBus.log()
• [x] add fastd status https://github.com/freifunk-gluon/gluon/issues/98
• [x] check scrolling of dropdown menu on mobile devices
• [x] add timestamp to statistics (for calculating bandwidth)
• [x] show batadv TQ
• [x] fix mesh vpn status
• [x] linting
• [x] convert to mesh.interfaces
• [x] check for memory leaks
• [x] javascript minifizieren
• [x] css minifizieren
• [x] create PR: https://github.com/freifunk-gluon/gluon/compare/status-page

  next release

• [x] stream multiplexer
• [ ] node history: last seen, sort by last connect, then last seen
• [ ] nodeinfo/statistics an meshviewer angleichen
• [ ] browser history
• [ ] show site_name (from site.conf)

  General

• [x] remove old status page
• [x] package a minimal working version (i.e. no tabs or other fancy stuff)
• [ ] test on two nodes without any mesh or internet connection
• [ ] document API level

Features not meant to be merged yet:

• allow neighbours to be discovered only through neighbour-info
• log events (new neighbour, lost neighbour, new client, ...)
• update nodeinfo on goto
• check api level on goto / show only nodeinfo
• handle display of non-wifi neighbours
• graph/map of neighbours
  • node fixed at center
  • realtime traceroute with path highlighting

    Backend

Endpoints should be /api/2/foo?parameter.

• [ ] EventStream multiplexer / "gluon-web-api"
• [ ] lua "client" using unix sockets. Pass PATH_INFO and QUERY_STRING to backend.
• [ ] finalize API
• [ ] new respondd API

[eriu]

Hinweis/Anregung:

• Hilfreich wäre auch eine Nennung der jeweiligen Freifunk Gruppe, die bereits in der site.conf eingelesen wurde, also z.B.:

  site_name = 'Freifunk Entenhausen',

• außerdem wäre das Einbinden und Anzeigen der Homepage-URL via site.conf nützlich, dafür müsste man die site.conf um diesen Wert noch gergänzen / Alternativ Auslesen der URL aus der jeweiligen Gruppen Freifunk API Files

[Joachim-Wolff]

I've tested the new status page from v2015.1-70-ga581477 on WR-841-ND v8...

Node raised to a load of 20 before it reboot with OOM, just the page was in use... After changing the nanosleep's to 5sec it survives a little bit longer, but far away from stable. Additionally nearly no space on /overlay is left to install any additional package on 4MB Flash boxes.

Will highly suggest to have an option to use the old status page... Yes, I know it's experimental ;-)

[FreifunkUFO]

ist ein screenshot o.ä. irgendwo online zum vorab anschauen? is there s screenshot available yet?

[tcatm]

@FreifunkUFO http://metameute.de/~nils/statuspage7.png

[FabianCernota]

Wird hier noch hilfe benötigt? Kann zwar kein C aber HTML / CSS / Javascript ist kein Problem

[FreifunkUFO]

Es gibt ein Problem, wenn man die Statuspage indirekt aufruft: Nur die linke Statusspalten wird aufgerufen, weiter rechts ist nur noch ein Fehlersymbol zu sehen (siehe Screenshot) Nachzuvollziehen via

• per ssh-portweiterleitung (siehe screenshot): ssh -L 8080:127.0.0.1:80 root@ .. dann http://127.0.0.1:8080
• oder via http://192.168.178.x IP, wenn man den Freifunk-Router an eine Fritzbox anschliesst, die wan-firewall in /etc/config/firewall auf accept stellen und aus dem Fritzbox-Netz dann auf den FreifunkRouter via Webbrowser zugreift..

[tcatm]

@FreifunkUFO Der Zugriff auf die Statusseite ist nur über IPv6 (Gluon macht nur IPv6) möglich. Dabei müssen die im Mesh verwendeten IPv6 Adressen vom Browser erreichbar sein.

[FreifunkUFO]

Es gibt ein Anzeige-Problem, falls das VLAN-Feature verwendet wird. (unabhängig von meinem vorigen Kommentar) In der rechten Spalte werden keine Werte angezeigt.. (wahrscheinlich, weil die status-abfrage des WLAN-Interfaces MIT der vlan-Nummer geschieht und somit nicht funktioniert) Ticket bei Freifunk Leipzig https://plan.leipzig.freifunk.net/issues/122

[dangowrt]

fix fuer batadv-in-VLAN-on-ibss: https://github.com/freifunk-gluon/gluon/pull/597

[neocturne]

Two more ideas to make the connection to the status page more robust:

• On bootstrap, always use the same IP address for the API connection that the status page was loaded from (I often connect to a node's public address and the API uses the ULA, or vice-versa; using the same address would also allow connecting to the page on the IPv4 next-node address without IPv6 connectivity)
• When moving to another node with multiple IP addresses, always use the address with the longest common prefix with the current address (has the highest change of being reachable)

[tcatm]

The next node address is avoided because it can lead to mixed up information when roaming from one node to another. For the status page, a node's IP is its identity.

Though, on bootstrap whatever IP the status page was accessed at is actually used to do the initial request used for retrieving the nodes IPs. Then, all returned IPs are tried in parallel and the first one succeeding is used. Adding a bias in favour of the longest common prefix would be possible but I'm not sure how that could help other than introducing more delay when switching between nodes.

Can cases in which this fails be reproduced? If so, how?

[neocturne]

@tcatm, this fails at least if Noscript blocks the address. I often need to whitelist two addresses when opening the status page on a new node. Just using the bootstrap address again would avoid this.

Why not use the node ID as identity, and store the list of addresses for each node ID?

[tcatm]

For internal purposes the node ID is used. When accessing the API the IPs are used to identify a node.

Noscript should probably respect the CORS headers and see that these requests are legit and pose no security risk.

[neocturne]

@tcatm, the very idea of Noscript is that I don't leave my IP on hosts I have not whitelisted, so the whole request is blocked.

[tcatm]

In that case, you could probably whitelist the status page API for common freifunk prefixes. Gluon nodes don't log these requests so it should be fine.

[tcatm]

I just tried NoScript. The option "Cascade top documents permission to 3rd party script" works nicely in this case.

[neocturne]

That options kind of defeats the purpose of Noscript.

I'm wondering though what exactly happens when Noscript blocks a request, I'd expect the other requests to work if they are implemented the way you say...

[tcatm]

The very first request is relative to the status page's current URL to fetch the local node info object. a) When that works, the same document is retrieved using the IPs from the nodeinfo object. When this succeeds, bootstrapping is considered complete and further requests will use the first IP that answered. When switching to another node the nodeinfo object will is already known and bootstrappings restarts at a).

[J0WI]

see also #914