Starting from zero with SNMP.
October 14, 2021 2:32 AM Subscribe
I'm planing my winter project, it seems that I'll need to use SNMP. My ignorance is total.
I want to build two hardware gauges to show CPU % speed and internet data speed, like an auto dashboard. From the beginning research I've done, it seems that others who have done this used SNMP to get this data. I know I'll have to build some sort of dongle that grabs network data, does something, and converts that data to an analog voltage to drive the meters.
So, first question: does my router support SNMP? It's an Archer AX3000 (it also has AX-50 on the back panel.) I read through the manual, it doesn't mention SNMP. Do I have to install something on my computer do implement SNMP? Is there a "best textbook or site" for me to learn this?
I want to build two hardware gauges to show CPU % speed and internet data speed, like an auto dashboard. From the beginning research I've done, it seems that others who have done this used SNMP to get this data. I know I'll have to build some sort of dongle that grabs network data, does something, and converts that data to an analog voltage to drive the meters.
So, first question: does my router support SNMP? It's an Archer AX3000 (it also has AX-50 on the back panel.) I read through the manual, it doesn't mention SNMP. Do I have to install something on my computer do implement SNMP? Is there a "best textbook or site" for me to learn this?
Best answer: I don’t see a MIB file on the AX3000 download site, which suggests no SNMP.
posted by zamboni at 5:21 AM on October 14, 2021
posted by zamboni at 5:21 AM on October 14, 2021
Best answer: SNMP might or might not be the right mechanism for this.
All network speed monitoring is over a given period of time. At its heart, you can think of a network as being a single-bit high speed channel, which is either on or off, and from an instantaneous point of view it is either "in-use" or "isn't". The question is what percentage of the time is it busy, or, how much data is being sent, and what the timeframe is.
If I measure on a per-second basis, for example, it is easy to see usage spike rapidly immediately after the point I hit ENTER to start an action such as retrieving a webpage.
# netstat 1
input (Total) output
packets errs idrops bytes packets errs bytes colls
1 0 0 126 0 0 0 0
0 0 0 0 0 0 0 0
9 0 0 1544 11 0 1127 0
5 0 0 903 6 0 792 0
519 0 0 668870 497 0 34046 0
396 0 0 514064 378 0 24979 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
^C
That lags by fractions of a second behind the actual traffic, which is pretty good, but it would be really difficult to get this sort of nearly-instantaneous information with SNMP, unless you were polling every second, and if you don't even have SNMP on the device, then that's a bit of a puzzle.
If you want to try the SNMP route, you could install a small ethernet switch such as the Netgear GS108Tv3, configure its management on your home network, create a VLAN on two ports, and use one of those ports to connect your "router"'s WAN port, and the other to your cable/DSL modem. This gives you a way to monitor traffic levels between the NAT and modem via SNMP, even if neither of them supports it directly.
That feels a bit messy to me, though.
You could also use a different device such as an OPNsense host as your "router", and use the Archer strictly as an access point. Depending on how responsive you want your meter to be, this is probably the best practical way to get sub-second response times. You can have an on-host daemon monitoring interface traffic levels at tenth-second intervals and passing it to your gauge using whatever method you find convenient (probably not SNMP). If you are using a small networked CPU like an ESP8266 or Arduino to drive the meter, this would allow you to do the hard work of sampling the traffic rate and computing the appropriate meter reading on the router host itself, which would make the meter's complexity requirements very low.
If you can find something you like such as OPNsense to act as your NAT gateway, it becomes very easy to do this sort of interesting and fun hacking. Building an Arduino or ESP8266 that simply listens on the network and drives a meter depending on values sent to it in a UDP packet is a great starter project for embedded network devices, and gathering traffic stats on an OPNsense host is not that hard.
posted by jgreco at 6:06 AM on October 14, 2021 [1 favorite]
All network speed monitoring is over a given period of time. At its heart, you can think of a network as being a single-bit high speed channel, which is either on or off, and from an instantaneous point of view it is either "in-use" or "isn't". The question is what percentage of the time is it busy, or, how much data is being sent, and what the timeframe is.
If I measure on a per-second basis, for example, it is easy to see usage spike rapidly immediately after the point I hit ENTER to start an action such as retrieving a webpage.
# netstat 1
input (Total) output
packets errs idrops bytes packets errs bytes colls
1 0 0 126 0 0 0 0
0 0 0 0 0 0 0 0
9 0 0 1544 11 0 1127 0
5 0 0 903 6 0 792 0
519 0 0 668870 497 0 34046 0
396 0 0 514064 378 0 24979 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
^C
That lags by fractions of a second behind the actual traffic, which is pretty good, but it would be really difficult to get this sort of nearly-instantaneous information with SNMP, unless you were polling every second, and if you don't even have SNMP on the device, then that's a bit of a puzzle.
If you want to try the SNMP route, you could install a small ethernet switch such as the Netgear GS108Tv3, configure its management on your home network, create a VLAN on two ports, and use one of those ports to connect your "router"'s WAN port, and the other to your cable/DSL modem. This gives you a way to monitor traffic levels between the NAT and modem via SNMP, even if neither of them supports it directly.
That feels a bit messy to me, though.
You could also use a different device such as an OPNsense host as your "router", and use the Archer strictly as an access point. Depending on how responsive you want your meter to be, this is probably the best practical way to get sub-second response times. You can have an on-host daemon monitoring interface traffic levels at tenth-second intervals and passing it to your gauge using whatever method you find convenient (probably not SNMP). If you are using a small networked CPU like an ESP8266 or Arduino to drive the meter, this would allow you to do the hard work of sampling the traffic rate and computing the appropriate meter reading on the router host itself, which would make the meter's complexity requirements very low.
If you can find something you like such as OPNsense to act as your NAT gateway, it becomes very easy to do this sort of interesting and fun hacking. Building an Arduino or ESP8266 that simply listens on the network and drives a meter depending on values sent to it in a UDP packet is a great starter project for embedded network devices, and gathering traffic stats on an OPNsense host is not that hard.
posted by jgreco at 6:06 AM on October 14, 2021 [1 favorite]
Well wups the netstat output is total trash. It's supposed to show a burst of traffic around seconds number 4 and 5 which is a webpage load.
posted by jgreco at 6:07 AM on October 14, 2021
posted by jgreco at 6:07 AM on October 14, 2021
SNMP is quite fun, I've done scores and scores of things with it across 1000+ switches and even more access points and a couple of dozen plus routers. But it does tend to fall into that area where consumer equipment has no support at all. You have to get into the small office or larger commercial space of devices to hit those that are SNMP manageable.
Were I to sorta do this thing.... sorta like jgeco... I'd write a bit of code or such to get the network/cpu statistics on a machine and then.... just send it out every second as a SNMP Trap. Then your monitor thing just listens on a UDP port for those traps and processes them as they come in. No polling needed.
You wouldn't necessarily have a device specific MIB. That's only if it does something that's not covered by other standard MIBs. CPU and network interfaces are well in the range of being just standard things.
I don't expect anything not-a-bit-expensive to be capable of SNMP. Though I really wish everything was so I could reboot my cable modem and router by running a script.
posted by zengargoyle at 7:26 AM on October 14, 2021
Were I to sorta do this thing.... sorta like jgeco... I'd write a bit of code or such to get the network/cpu statistics on a machine and then.... just send it out every second as a SNMP Trap. Then your monitor thing just listens on a UDP port for those traps and processes them as they come in. No polling needed.
You wouldn't necessarily have a device specific MIB. That's only if it does something that's not covered by other standard MIBs. CPU and network interfaces are well in the range of being just standard things.
I don't expect anything not-a-bit-expensive to be capable of SNMP. Though I really wish everything was so I could reboot my cable modem and router by running a script.
posted by zengargoyle at 7:26 AM on October 14, 2021
Best answer: You're right that SNMP would be the right way to do this, but if your router doesn't support SNMP you're kinda out of luck, unless you want to upgrade hardware.
I had a (software, not hardware) dashboard that showed my Internet uplink/downlink speeds, and I got the data from my "core switch" (an old enterprise switch that I used to interconnect all my gear, including the Internet gateway/router). The switch, an old HP, supported SNMP and would let me poll the number of bytes transferred through a specific port.
My recollection is that the switch didn't actually provide the rate of data going through the port; it was a basically monotonic counter of bytes which rolled-over every so often. Rather than deal with this on my own, I was lazy and used RRDTool to process and store the data. RRDTool has built-in support for byte counters and will convert them to rates and detect and deal with the zero rollover. It also handles storing the data in a "round robin database" (fixed size database) consisting of gradually less granular data over time. It's worth looking into for these sort of dashboarding-type projects just so you don't end up reinventing the wheel if you want to do summaries (show bandwidth over the last hour/day/week/month/etc.)
Anyway, I just had a shellscript that was triggered by cron every 5 minutes or so, which polled all the various sensors and other data sources and stuffed the resulting values into the RRDTool databases, and then I had a web page with some CGI (maybe? little hazy on this part now) that pulled values out of the databases and generated graphs on demand when the page was accessed. There is no real reason why you couldn't run it more frequently, like at 1-minute intervals or whatever. Maybe even faster than that.
To drive your analog meters, I would use a Raspberry Pi and do something like this. In particular, I would look at the dac.py code sample provided.
You may also want to take a look at this project, which seems very similar to what you're trying to do. The developer here decided to use Switec X25.168 stepper motors, which are apparently a common automotive part used to drive dashboard analog gauges in cars and aircraft (and have 1/3 degree resolution, not bad!) and can be controlled using I2C. This eliminates the need for an DAC like you'd need with traditional true-analog gauges or VU meters, and in theory lets you drive a whole bunch of gauges from a single bus controller.
posted by Kadin2048 at 8:10 AM on October 14, 2021
I had a (software, not hardware) dashboard that showed my Internet uplink/downlink speeds, and I got the data from my "core switch" (an old enterprise switch that I used to interconnect all my gear, including the Internet gateway/router). The switch, an old HP, supported SNMP and would let me poll the number of bytes transferred through a specific port.
My recollection is that the switch didn't actually provide the rate of data going through the port; it was a basically monotonic counter of bytes which rolled-over every so often. Rather than deal with this on my own, I was lazy and used RRDTool to process and store the data. RRDTool has built-in support for byte counters and will convert them to rates and detect and deal with the zero rollover. It also handles storing the data in a "round robin database" (fixed size database) consisting of gradually less granular data over time. It's worth looking into for these sort of dashboarding-type projects just so you don't end up reinventing the wheel if you want to do summaries (show bandwidth over the last hour/day/week/month/etc.)
Anyway, I just had a shellscript that was triggered by cron every 5 minutes or so, which polled all the various sensors and other data sources and stuffed the resulting values into the RRDTool databases, and then I had a web page with some CGI (maybe? little hazy on this part now) that pulled values out of the databases and generated graphs on demand when the page was accessed. There is no real reason why you couldn't run it more frequently, like at 1-minute intervals or whatever. Maybe even faster than that.
To drive your analog meters, I would use a Raspberry Pi and do something like this. In particular, I would look at the dac.py code sample provided.
You may also want to take a look at this project, which seems very similar to what you're trying to do. The developer here decided to use Switec X25.168 stepper motors, which are apparently a common automotive part used to drive dashboard analog gauges in cars and aircraft (and have 1/3 degree resolution, not bad!) and can be controlled using I2C. This eliminates the need for an DAC like you'd need with traditional true-analog gauges or VU meters, and in theory lets you drive a whole bunch of gauges from a single bus controller.
posted by Kadin2048 at 8:10 AM on October 14, 2021
This thread is closed to new comments.
posted by zamboni at 4:59 AM on October 14, 2021