Closed tcatm closed 6 years ago
Hinweis/Anregung:
site_name = 'Freifunk Entenhausen',
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 ;-)
ist ein screenshot o.ä. irgendwo online zum vorab anschauen? is there s screenshot available yet?
@FreifunkUFO http://metameute.de/~nils/statuspage7.png
Wird hier noch hilfe benötigt? Kann zwar kein C aber HTML / CSS / Javascript ist kein Problem
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
@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.
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
fix fuer batadv-in-VLAN-on-ibss: https://github.com/freifunk-gluon/gluon/pull/597
Two more ideas to make the connection to the status page more robust:
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?
@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?
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.
@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.
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.
I just tried NoScript. The option "Cascade top documents permission to 3rd party script" works nicely in this case.
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...
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).
see also #914
I'll track progress on the new statuspage in this issue.
Frontend
next release
General
Features not meant to be merged yet:
Backend
Endpoints should be
/api/2/foo?parameter
.PATH_INFO
andQUERY_STRING
to backend.