Open genofire opened 3 years ago
@genofire What exactly is missing? Maybe I'm looking in the wrong place.
Upstream statistics is implemented like this: https://github.com/freifunk-gluon/gluon/blob/4684f42173bea54c6626ce16fe14397692047775/package/gluon-mesh-vpn-wireguard/src/respondd.c#L204
And returns the result of the ubus-call a few lines below.
That can be reproduced on the commandline of such a node:
ubus call wgpeerselector.wg_mesh status
Which returns something like this:
{
"peers": {
"sn03": false,
"sn02": false,
"sn01": false,
"sn10": false,
"sn04": false,
"sn09": {
"established": 232847
},
"sn06": false,
"sn07": false,
"sn08": false,
"sn05": false
}
}
I'm not familiar enough with yanic, but our grafana (which displays yanics collected data) appears to extract connected supernodes just fine:
May you elaborate what statistics are missing and what command one can use to verify your findings?
Thanks for that response - i believe we have to fix upstream the format first - it should be a consistent dataformat:
in next step we could discusse, how to make the data useable in metrics to a database
Can't you marshal an enum in go? Like this is either an object or false? That would at least be what my rust code would do :)
We could Start to Marshall to interface{}
(and map[string]interface{}
) - but then we have to validate so much values afterward. An consisdent structure would be to prefered way, for performance and developer mistaks
i make a first suggestion: freifunk-gluon/packages#250
@genofire freifunk-gluon/gluon#250 is merged, where do we go from here?
could anybody send us an result of an gluon-neighbour-info -r statistics -d ::1 -p 1001
on a node with running wgpeerselector?
As test-value it would be nice xD
This device has wgpeerselector installed: vH24 / gluon-v2021.1-148-g9e3cf00e https://hannover.freifunk.net/karte/#/en/map/44d1fa59f87c
root@aiyion-JT-OR750i:~# gluon-neighbour-info -r statistics -d ::1 -p 1001
{"wireless":[{"frequency":2412,"noise":-95,"active":1937787945,"busy":778744730,"rx":741737625,"tx":13222527,"phy":1},{"frequency":5220,"noise":-108,"active":1862970236,"busy":71421804,"rx":6954205,"tx":28865174,"phy":0}],"clients":{"total":0,"wifi":1,"wifi24":0,"wifi5":1,"owe":0,"owe24":0,"owe5":0},"traffic":{"rx":{"packets":30025133,"bytes":4327653255},"tx":{"packets":3137092,"bytes":710568769,"dropped":36117},"forward":{"packets":24006613,"bytes":5881189489},"mgmt_rx":{"packets":41489641,"bytes":7503332966},"mgmt_tx":{"packets":101091317,"bytes":19591416982}},"gateway":"88:e6:40:20:70:14","gateway_nexthop":"02:a1:71:04:07:14","mesh_vpn":{"peers":{"sn03":false,"sn02":false,"sn01":false,"sn10":false,"sn04":false,"sn09":false,"sn06":false,"sn07":{"established":1412632.0},"sn08":false,"sn05":false}},"gateway6":"88:e6:40:ba:90:14","node_id":"44d1fa59f87c","time":1649917837,"rootfs_usage":0.0419,"memory":{"total":122968,"free":64612,"available":45456,"buffers":2948,"cached":6024},"stat":{"cpu":{"user":11998840,"nice":0,"system":6876199,"idle":164485852,"iowait":0,"irq":0,"softirq":10882573},"intr":1454479620,"ctxt":1442502889,"processes":2446787,"softirq":1757994235},"uptime":1942448.58,"idletime":1644858.52,"loadavg":0.03,"processes":{"running":1,"total":58}}
hmm that does not look like that is running on the current version after https://github.com/freifunk-gluon/packages/pull/250 was merged:
"mesh_vpn": {
"peers": {
"sn03": false,
"sn02": false,
"sn01": false,
"sn10": false,
"sn04": false,
"sn09": false,
"sn06": false,
"sn07": {
"established": 1412632
},
"sn08": false,
"sn05": false
}
},
in the past (on fastd?) we got an extra level: https://github.com/FreifunkBremen/yanic/blob/aa9d94f97f81dd8f3a78feadbb9cdf17103005a6/data/statistics.go#L49-L52
if i reconstruct it, the data was something like:
"mesh_vpn": {
"groups": {
"fastd0": {
"peers": {
"sn03": null,
"sn02": null,
"sn01": null,
"sn04": {
"established": 1412632
}
}
}
}
},
maybe we should clearify the structure on gluon side - so that it become the same way.
Is this still an open issue? Yanic works well using wireguard on our domain?
Yes, we do not implement any parsing that values (or storing in database)
In that case - the requested output of gluon-neighbour-info -r statistics -d ::1 -p 1001
of a node running gluon v2023.1.0 with an active wireguard vpn connection is:
{
...
"gateway": "02:a2:ff:ac:02:12",
"gateway_tq": 255,
"gateway_nexthop": "02:a1:ff:ac:02:12",
"mesh_vpn": {
"peers": {
"sn112": [],
"sn220": [],
"sn214": [],
"sn113": [],
"sn111": [],
"sn119": [],
"sn213": [],
"sn215": [],
"sn118": [],
"sn216": [],
"sn117": [],
"sn211": [],
"sn218": [],
"sn219": [],
"sn115": [],
"sn212": {
"established": 193973.0
},
"sn116": [],
"sn217": [],
"sn114": [],
"sn120": []
}
},
"gateway6": "88:e6:ff:ac:20:12",
...
}
@AiyionPrime maybe you have an fix for it