This may be me not understanding exactly how Wireless Sensors are supposed to work (reading from https://docs.librenms.org/Developing/os/Wireless-Sensors/, but there may be more around I haven’t found).I do have the very basics working … I can send a client (count) across, but …
As I have two bands (2.4GHz, 5.0 GHz), I really want to send two counts.
For items like rate, SNR, UL power (RSSI) … also here, I want to send several results, one per attached client - agreed?
So this is where I get stuck, to I just send an array of OID’s, and the data is somehow read from there? I admit, not quite clear on how to pass this accross, any pointers would be greatly appreciated.
Nothing at all, currently . My intention is to add a / some shell scripting on the client side, have it provided the needed info back (“agent” of sorts). But to do that, I need to know how to properly format it / put it in an “MIB” (i.e. set up the OID’s right). Make sense?
I have tried just with one parameter (Clients) … and it works - but I need to “build” the table on the client. To do that, I need to know how to structure if of course. And in the back of my mind, wondering if I need a line in the snmpd.conf file for every single one, or if I can somehow “batch” write to OID’s.
And BTW, this may be me, “over-reading” the capability here … LOL. What I mean is … for example, there is the item WirelessRssiDiscovery - this is really different for each associated station (i.e. wireless client), but it may be that LibreNMS only tracks a single value (saying this because of the comment in the documentation about an $aggregator may be a hint). If this is the case, NP - just trying to figure it out. And I don’t take hints well, hence the question .
Yes, somewhat … . Creating my own “custom” MIB, to feed into the Wireless engine. But you are spot on, I’m using an extend script to do this. And I just tell the Wireless Sensors the OID I “assigned”. I do have it working for discovery, and separated by (Wi-Fi) band, which is great.
And makes sense on the per-station data. NP at all, just wanted to understand before I tried to put all that data in. I’m also not sure it makes sense to try to track it all, could become a bit overwhelming.
And BTW, it seems that the Discovery routines are really to tell LibreNMS where to go get the particular data (i.e. OID to data mapping) … do I have that right? So Discovery “primes the pump” for the Poller, and it just goes and gets the data from the OID it has been told.
BTW, one thought on this - I agree that per-station data would be overwhelming (could be a long and messy list), but … given the variation in some of these metrics, would it make sense to support a min, avg and max value for each (at each “sample point”)?
Sorry, one more question. I won’t lie and say it’s the last … LMAO!
I am getting Discovery working, but I want to use the OID by name, not a hard-coded number (better / easier with extend). But … somewhere in LibreNMS code (I’m looking, haven’t found it!) - it’s pre-pending a dot (.) to the start of the name (assuming it’s a number), and that’s breaking Discovery for me. Any pointers where this may be?
Sort of . I say that because I lose the min, max, avg across stations when I store / poll the data => can’t recover it after. It’s not a huge issue, just asking.
On the OID (and dot) - that makes sense, no issue. It was just that snmp_get handled numeric or textual OID’s, but Wireless Sensor discovery did not seem to. I just did an snmp_translate first, so it works.
That’s a great point, thanks! This isn’t about clients, rather signal level or data rate - items that are per-station specific. But what you say makes sense … add 3 sensors (min, avg, max), and report data to those, aggregated across stations. Perfect!
Also, wireless sensors is a bit unique that it an poll multiple oids and aggregate them together. Perhaps you are talking about the aggregation method?
One downside is that the list of oids to poll is only updated during discovery, so if you have highly dynamic clients, the data might be not so useful.
Sorry, I likely wasn’t very clear in the way I worded it earlier, my fault. I meant to aggregate on the client side, just report to 3 sensors … min, max and average. That will work perfectly.
As for OID’s, that’s OK - they are static, no reason to update them … but in any case, discovery is run on some sort of recurring basis, right? I think once per day, but I could be wrong.
OK, that wasn’t too bad - have it working … the client works out the avg, min and max (so far for data rate, tx and rx), returns all three. Now one more dumb question, sorry!
I would like min, max and avg for a particular case (e.g. 2.4 GHz, tx) to be on a single (line) plot. Is there a way to configure this? Right now they are all independent plots.