The below mentioned commit introduced a regression, that the "wifi"
section of the request type "neighbours" was empty:
~# gluon-neighbour-info -d ::1 -r neighbours | ffh_pretty_json
{
"wifi": [
],
...
}
After this commit, the section (correctly) looks like this:
root@UFU-FWH-A272-Tresckowstr-GemR-vorne:~# gluon-neighbour-info -d ::1 -r neighbours | ffh_pretty_json
{
"wifi": {
"ca:38:7e:42:5f:21": {
"neighbours": {
"fe:9f:4d:01:ea:e1": {
"noise": -102,
"inactive": 50,
"signal": -84
},
"fe:df:b9:84:37:51": {
"noise": -102,
"inactive": 20,
"signal": -73
}
}
}
},
...
}
The issue was due to the fact, that the iteration over the (mesh) wifi interfaces
was broken. The code was assuming, that the section
config interface 'mesh_radio0'
option proto 'gluon_mesh'
in /etc/config/network contains an option "ifname", which it does not.
The ifname property is only stored in the corresponding section in
/etc/config/wireless:
config wifi-iface 'mesh_radio0'
option ifname 'mesh0'
option network 'mesh_radio0'
option mode 'mesh'
...
Therefore, we now iterate over wifi-ifaces in /etc/config/wireless, that
have the mode 'mesh' instead. This resolves the issue.
Fixes 0f1fa243f7
This removes PKG_VERSION and PKG_RELEASE from most Makefiles, as the
value was never useful for Gluon packages; instead, PKG_VERSION is set
to 1 in gluon.mk.
It also removes two other weird definitions:
- gluon-iptables-clamp-mss-to-pmtu replicating the old PKG_VERSION logic
from gluon-core, but without the fixed PKG_BUILD_DIR to prevent
unnessary rebuilds
- gluon-hoodselector set GLUON_VERSION=3
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).
In addition this PR contains:
- split of gluon-respondd provider into multiple source files
- minor additional cleanups in gluon-mesh-babel respondd provider
(untested, as the babel respondd provider already doesn't compile prior
to these changes...)
This commit adds information about:
- how cpu time is spent since boot in jiffies (1/100*sek) (cpu)
- the value is summed for all cores, so in 10 seconds the
summed values will increase by 4000, if the cpu has
4 cores
- context switches since boot (ctxt)
- interrupt counters since boot (intr, softirq)
- forks since boot (processes)
{ "stat": {
"cpu": {
"user": 219403,
"nice": 1714,
"system": 75159,
"idle": 2727739,
"iowait": 2943,
"irq": 0,
"softirq": 571
},
"intr": 8426340,
"ctxt": 50992590,
"processes": 10549,
"softirq": 5161884
} }
* gluon-core, gluon-client-bridge: introduce new firewall zone: local_client
* gluon-core: put clients in local_client zone, introduce drop-zone,
set dns-rules and zones
* gluon-respondd: allow respondd on mesh
* gluon-status-page-api: allow http input on mesh and client
Because we unconditionally appended `-i br-client` to the command line of
respondd, it wasn't restarted when br-client changed state. Now, we use a
jsonfilter expression on the network.interface dump data, similar to how the
other interface names are generated, and only add the interface to the argument
list if it is up.
Most doubles that are delivered via respondd have limited input
precision, but are converted with up to 17 digits of precision. That can
cause ugly blowups like 0.2800000000000001 in the output, which is
avoided by specifying better format strings (like "%.2f" in most cases).
Instead of starting gluon-respondd from a hotplug handler, add a proper
init script. The new init script has a restart_if_running argument which
is now used by the hotplug handler.
