Fixes the display of client counts, which are numbers and not strings
in the respondd data.
Fixes: 3a885a1b22 ("gluon-status-page: make "gateway nexthop" a link (#2278)")
Do not depend on the respondd-airtime module just to get the configured
channels. This removes the display of the frequency in addition to the
channel, as it is not readily available.
In addition, the translation string is improved to allow for text after
the channel number.
This code is usually running on an embedded CPU without FPU. In
addtition to its inefficience, the algorithm is also much harder to
understand.
Replace the logarithm formula with a simple loop.
It was found that a one second timeout for nodeinfo data may be too low,
so that when a node is otherwise occupied that timeout may be reached
too often.
The nodeinfo query response is also vital to the status-page base
template, so that when it times out, the site will be turned in a broken
state, that it cannot recover from.
Fixes: #2256
This renames the local_client zone to loc_client, as local_clint exceeds
the maximum zone length allowed for firewall3, which is 11 bytes.
This worked previously due to firewall3 using unsafe string operations.
Now creation of the chain fails (latest OpenWrt master).
This adds the wireless client count for 2.4GHz and 5 GHz radios to the
status page. Previously, only the total client count advertised by
the mesh protocol was visible.
This reverts commits
- caf2dd037b.
- 07ebac6a49
- 55eff45f96
I accidentally pushed these commits as I had them lying around on a
dirty checkout I did testing on.
Let gluon-respondd expose "MemAvailable" from /proc/meminfo to allow for
a more realistic memory-usage estimation.
Information on MemAvailable can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773
A downside of this behaviour is that the page does not work for IPv4-only
clients, as the redirect will always point at an IPv6 address.
Still, it seems like a good idea to enforce the redirect even from the IPv4
next-node address, as switching nodes while being connected to the status
page would lead to unexpected behaviour.
