respondd: transmit additional node data

[Adorfer]

i'd like to have transmitted via the respondd (gluon collector) more node static data, in order to monitor remotely the setup of more complex mesh networks without the need to ssh to nodes to check for data.

• radioX.wifichannel selected.
• radioX.HT-mode operating
• radioX.txpower running
• radioX.DFSevent(format)?
• radioX.ClientAP disabled
• radioX.wifimesh disabled
• current systemtime in node (perhaps timestamp the datagram)

perhaps

• meshvpn type (fastd, wireguard, l2tptunneldigger...)
• meshvpn status /disabled/disconnected/connected
• meshvpn simple-tc: limit_enabled, limit_ingress, limit_egress
• MoW enabled
• MoL enabled

nice to have

• either name of IFs per bridge/vswitch,
  in order to detect setup-foo like (MoL&(MeshVPn|Client)) akticvated on same phy)

ultimativly even, if info available from switch

• ethernetports up

[ghost]

we have meshvpn already
MoW and MoL can probably be extracted from the current data too (only if one of the two is active, not which)

[neocturne]

I think you mean respondd, not collectd, right? We don't support collectd.

[neocturne]

We already provide a list of mesh interfaces with type (wireless/tunnel/other, where other is usually wired).

I guess we could add:

• Channel of each wireless mesh interface
• List of wireless client interfaces (with channel)

I think we shouldn't add anything hardware-specific, like refering to specific radio devices or specific ethernet ports, or differentiating between LAN and WAN ports.

[ghost]

I think you mean respondd, not collectd, right? We don't support collectd.

He wants to collect this data with gluon-collector from ffdo/node-informant
So it has to be provided by respondd, yes.

Your suggestion sounds good. Would solve most things.

[Adorfer]

@NeoRaider

I think you mean respondd, not collectd, right? We don't support collectd.

Correct, my fault. I took the "gluon collector" for collectd... but i off course it's (c)-respondd

For the interfaces: For me the info is not only "available in the system", but "actual status" like "up", even if there is no batman link over it.
(Like "fastd is up, but not batman originators on the other side" or "eth1 for MoW is up on Nanostation, but no originator visible due to external switch issue" )
I know that the info is often not available, since an interface is systematcally flagged as "lower/up". But if the info is present, i'd like to have it reported.

[tcatm]

fastd is up, but not batman originators on the other side

The neighbour information provides just that. Please keep in mind that it is possible to have batman originators on an interface that you aren't made visible by the kernel module (due to lower TQ mostly).

[viisauksena]

you maybe should have a look at https://github.com/viisauksena/gluon-airtime
there - for now in progress - are channels spit into respondd and alfred for 2g and some more info (related to airtime)

[frennkie]

is there any progress on this?

[rotanid]

is there any progress on this?

the label "help appreciated" means, that someone has to step up and start working on it :)

[rotanid]

some (all?) of it has already been done. havin this 8 year old issue doesnt help with additional infos.