To whom it may be of use: I recently switched to a ZyXEL VMG1312-B30A modem attached to my router and, naturally, I wanted to get the DSL line values into collectd.
Here is my result: A script that pulls the data via netcat (emulating telnet) and offers them to collectd-mod-exec with meaningful values:
Note: From time to time, and without any identifiable underlying cause, the modem seems to randomly bump the FEC "error" counter by ~10000 from one minute to the next, resulting in a huge spike. (You can see this in the screenshot above, towards the end of the timeline.) After logging for a while I confirmed this is not a parsing issue, but already present in the raw value output of xdslctl, so there's really nothing I can do about it. Without any deeper insight, I suspect a glitch in the firmware. The FEC counter by itself is only a very weak indicator anyway since "forward error correction" is not actually an "error counter", but rather monitoring the very regular operation of the protocol. Personally, I don't even watch FEC counters anymore.
(Edited because the darn forum software won't ever update oembed caches.)
a) the ZyXEL appears not to speak any of the ciphers OpenWrt's own dropbear-ssh client comes with (it bombs out with No matching algo enc c->s)
b) the shell opened by ssh is actually more restricted than the shell opened by telnet, and some weird rights issue prevents the execution of xdslctl
It is mostly specific to the output of the Broadcom xdslctl utility which delivers a certain output. Chances are it will work for other Broadcom-based modems, but I have no way of knowing that.
To be clear: None of what I am doing here is rocket surgery, it's just a shell script retrieving the output from the modem and some parsing into usable values. The point of releasing it to the public is ... to save someone the time to do it themselves, or even just as a pointer how to parse values from a multi-line file.
xdslctl output is very standard (unless the oem modify it) @slh snmp most of the time is bugged on this broadcom platform... (problem with driver updating the stats in the right time)
Honestly, I did not. Partly because I wanted to go about it with what is built into default OpenWrt (hence netcat and not some installable telnet client), partly because I am utterly unfamiliar with SMNP.
Simple Network Management Protocol ( SNMP ) is one of the oldest (since the 80s) and most widely used Internet Standard protocol for collecting and organizing information about managed devices on IP networks.
With Openwrt you just have to install the SNMP package and you're in business.
Then use the SNMPWALK tool to find what metrics are provided by your device.
In the meantime I tried. The ZyXEL VMG1312-B30A does not offer SNMP access (edit: at least not with my firmware, the "SNMP" config screen mentioned in the manual is simply missing, and there is no snmpd running or even to be found anywhere in the file system.)
And even if it did, the snmpwalk output of the related (but not identical) "B10A" variant suggests that it would only expose router-related statistics, not DSL modem statistic.
Also, there is a "dslstats" software to be used with Broadcom modems which ... does exactly what I do: retrieve statistics via telnet. However, the website has a compability list with a bunch of modems where my approach, inelegant as it is, might work too.
I don't own one myself so I can't offer any support for it.
I was just talking about SNMP in general, that it's preferred if available.
I completely understand what you mean, same case with Lantiq based routers with OpenWRT.
I can get the router-related stats via SNMP but not the DSL modem stats, need to use Prometheus node exporter for that.
I might give it a try at some point but I would also prefer SSH support as my Techicolor modem has SSH running and I can execute xdslinfo commands via SSH...
How collectd needs to be setup or does the script everything on its own?
line so it receives the output of xdslctl info --stats and puts it into the $xdslinfo variable. The script can probably parse the output right away.
Really, I'm not doing any rocket surgery here, it's just parsing a string into variables that can be shoved into the rrd/collectd database. This is more of an "here's how I did it, it may save you some time, maybe you can use it directly, maybe you can learn from it and adapt it" kind of deal, it's not next-level magic.
As with all collectd-exec scripts: you need collectd-mod-exec installed and have it run the script. I just updated the Gist with a current version of the script, and the exec.lua you can use with luci-app-statistics.
nice work. i have a few dlink 520B (broadcom based) and it doesn't seem to expose line stats via SNMP. commands are a bit different to get stats on this platform (adsl info --stats) but looks promising.
this could be a big time saver when troubleshooting multiple lines
edit: on the dlink 520 b, i took a different approach by using curl
For posterity and public amusement: There seems to be a weird bug in the Zyxel VMG1312 xdslctl tool. I got curious why my uptime graph plateaus like this:
It appears the function in xdslctl that tranforms line uptime seconds to a human-readable string wets the bed and is stuck at either 49 days 17 hours 2 min 45 sec (the value I read and re-parse to seconds) or rolls over zero (in the webstats). Which is ... weird because the device uptime string still updates completely fine. I suspect someone chose a really inappropriate data type somewhere in the postprocessing functions.
xdslctl stats --show still gives a sensible "available seconds" (AS) value, but I'm not sure how closely it relates to the actual line uptime (edit: it might not be related to the continuous uptime at all.) And right now I don't want to reset my line just to check. For the time being, I don't think I will rewrite the parser and I'll just read the graph as "line uptime is great thxbye."
