Wireguard missing statistics

[genofire]

@AiyionPrime maybe you have an fix for it

[AiyionPrime]

@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:

https://stats.ffh.zone/d/EGysRPsMz/router-fur-meshviewer?orgId=1&var-node=44d1fa59f87c&var-saveinterval=60&var-hostname=aiyion-JT-OR750i&var-model=Joy-IT%20JT-OR750i&var-domain=nordstadt&[email protected]&var-firmware_release=vH23&var-autoupdater=wireguard&viewPanel=24

May you elaborate what statistics are missing and what command one can use to verify your findings?

[genofire]

Thanks for that response - i believe we have to fix upstream the format first - it should be a consistent dataformat:

• false is an boolean and no object -> an object could be null

in next step we could discusse, how to make the data useable in metrics to a database

[genofire]

Boa, i hate lua:
https://github.com/freifunk-gluon/packages/blob/0a334b837f9e4bf6eec7a675c93dbc56c140afb3/net/wgpeerselector/files/usr/bin/wgpeerselector#L326-L328

i make a first suggestion:
freifunk-gluon/packages#250

[AiyionPrime]

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 :)

[genofire]

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

[AiyionPrime]

i make a first suggestion:
freifunk-gluon/packages#250

@genofire freifunk-gluon/gluon#250 is merged, where do we go from here?

[genofire]

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

[AiyionPrime]

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}}

[genofire]

hmm that does not look like that is running on the current version after freifunk-gluon/packages#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:

yanic/data/statistics.go

Lines 49 to 52 in aa9d94f

	// MeshVPN struct
	type MeshVPN struct {
	Groups map[string]*MeshVPNPeerGroup `json:"groups,omitempty"`
	}

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.

[maurerle]

Is this still an open issue? Yanic works well using wireguard on our domain?

[genofire]

Yes, we do not implement any parsing that values (or storing in database)

[maurerle]

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",
    ...
}