Trivial little script for logging power and SNR from Arris modems

Discussion in 'Tomato Firmware' started by darksky, Jul 16, 2013.

  1. darksky

    darksky Addicted to LI Member

    In an attempt to help troubleshoot my ISP's inability to provide me with consistent connectivity, I wrote this script. If you have a webserver running, you can use dygraphs to make the plots I'm showing in this thread.

    It simply connected via wget to your Arris modem and parses out the RF parameters from the status page to a csv text file you can plot in some other application of your choosing. If running TomatoUSB, simply copy this script to your USB mounted filesystem, edit the two variables in the script itself (they are commented and self-explanatory) on the TomatoUSB box, and setup a cron entry in the web GUI:

    Administration>Scheduler>Custom X and pasted in the following:
    Enabled = [X]
    Time = [Every 30 minutes]
    Days = (all are checked including 'everyday')

    Example output:
    Last edited: Aug 25, 2013
  2. Monk E. Boy

    Monk E. Boy Network Guru Member

    Now I wish I still had an Arris at home instead of a &*@(#$&(* inscrutable UBEE.
  3. koitsu

    koitsu Network Guru Member

    Where do I begin...

    1) I wrote something like this in Perl for Motorola-series cable modems some time ago, though my CSV is intended for use with dygraphs and only for downstream (graphing upstream would be just as easy though). The reason I chose Perl is because shell script hackathons just don't cut it, and I'll explain all the variables/nuances here that justify using a real programming language:

    i. The frequency ranges vary per ISP, and even vary per area. For example Comcast in my area up until a couple months ago used 705-753MHz (with 711MHz skipped intentionally) for downsteram, but then changed their frequency ranges one day to 561-603MHz after some CMTS head end maintenance. Hard-coding the frequencies requires the end user to know what the proper frequency ranges are for their ISP/area. This is outside of your control, but means the user cannot just drop the script into place and have it work. If you're going to distribute this script publicly you need to make the user aware that they need to adjust things in advance.

    ii. The formatting/output will vary depending on cable modem firmware version; I know you've only so much equipment to test with and the f/w version is outside of your control, but it's important to acknowledge this. For example while writing mine, I found that Motorola changed the HTML output of their pages between minor revisions of f/w, and in a couple cases across different models (SB51xx vs. SB61xx), so I had to re-code things to handle this situation cleanly (vs. "per-model one-offs") and started documenting the differences. So what may work for you now might not work for you a year from now, or might not work for someone else using an older (or newer) Arris modem. For example, your assumption that the <td> is going to be the 69th parameter (hence the awk print) may change in a firmware update, becoming 73rd, etc...

    I say this aware that the comments in your script state it works for you on a TM822 "and related modem" (be careful with such statements), but mark my words that it will eventually vary.

    iii. The formatting/output will vary depending on if the ISP has configured DOCSIS 3.x or not. Your script makes the assumption that DOCSIS 3.x is in use, and will break badly if certain variables (ex. $DS8) don't contain any data (I'm talking about literally an empty result, not "----</td>").

    My main point: given that a USB flash drive is needed (you do not want to store this in NVRAM or in RAM, as the router will eventually resource exhaust), Entware is therefore possible, thus a real programming languages (Perl, Python, whatever) should really be used.

    2) Please hard-code paths to all the utilities you use; do not rely on $PATH. It has been proven many times over that tons of users "tinker" with their setups (particularly $PATH), doing things like sticking /opt/bin and /opt/usr/bin before the system paths, which results in different behaviour (i.e. Busybox utilities can/will differ from Entware/Optware utilities). In other words:

    date --> /bin/date
    wget --> /usr/bin/wget
    grep --> /bin/grep
    awk --> /usr/bin/awk
    sed --> /bin/sed

    3) Your UPSTREAM power level comment in the graph says "+35 to +50 is recommended (lower = better)" -- no, lower is not necessarily better. A channel hovering around 52dB would concern me just as much as one hovering around 33dB. There is a "sweet spot" generally around the mid-to-high-40s which is considered ideal, but there are an infinite number of variables/possibilities for a higher or lower number (in fact, so many that I just won't go into all of them here).


    4) Your script does not elegantly handle situations where communication with the cable modem fails or times out; the result will be the $TEMP file still containing the previous-working-run's data, which may or may not be what a person wants. Some people (myself for example) would prefer a failure cause the script to output zeros for all the signal stats. This can also be useful for situations where the cable modem is rebooting repeatedly due to work being done on the node or the CMTS head end (e.g. loss of signal causes the modem watchdog itself to reboot the modem, and the graphs should indicate such situations). Bare minimum I would suggest making use of wget's -T flag (I have no idea what the default timeout is, would need to go look at Busybox's source code).

    All of these are why I keep my Motorola script private -- I do not want to be responsible for maintaining something that other people will use, as it means I have to provide support for it and deal with every end users' needs/situation/etc.. So be aware of what you're gettin' into. :)

    Edit: Attached pictures of my own work, so that I don't come off sounding like a completely pompous jerk that sits around criticising other people's stuff and doing nothing himself. :) And a non-CSV output run:
    Jul 16 14:49:06    Device Model: Motorola SB6121 (hardware version 5.0)
    Jul 16 14:49:06        Firmware: SB_KOMODO- (Oct 29 2012 18:07:13)
    Jul 16 14:49:06      Boot Code: PSPU-Boot(25CLK)
    Jul 16 14:49:06    Modem Uptime: 5 days 13h:45m:40s
    Jul 16 14:49:06    Modem Status: Operational
    Jul 16 14:49:06 Down Channel  1: 561000000 Hz,  4 dBmV power, 38 dB SNR, mod: QAM256, corr: 16, uncorr: 654
    Jul 16 14:49:06 Down Channel  2: 567000000 Hz,  3 dBmV power, 38 dB SNR, mod: QAM256, corr: 50, uncorr: 576
    Jul 16 14:49:06 Down Channel  3: 573000000 Hz,  4 dBmV power, 38 dB SNR, mod: QAM256, corr: 16, uncorr: 585
    Jul 16 14:49:06 Down Channel  4: 579000000 Hz,  3 dBmV power, 38 dB SNR, mod: QAM256, corr: 17, uncorr: 631
    Jul 16 14:49:06  Up Channel  8:  30600000 Hz,  38 dBmV power, 5.120 Msym/sec, status: Success
    Jul 16 14:49:06  Up Channel  7:  35400000 Hz,  39 dBmV power, 2.560 Msym/sec, status: Success
    Jul 16 14:49:06  Up Channel  9:  23700000 Hz,  37 dBmV power, 5.120 Msym/sec, status: Success
    Jul 16 14:49:06 --

    Attached Files:

    • old.png
      File size:
      111.3 KB
    • new.png
      File size:
      85.6 KB
  4. darkknight93

    darkknight93 Networkin' Nut Member

    Thanks for sharing! :)
  5. darksky

    darksky Addicted to LI Member

    @koitsu - Thank you for the thoughtful reply. In short:

    1) I agree that shell scripts are crude solutions, but they are in reach for those of us ignorant of more powerful scripting languages like perl and python, etc.
    1i) Point taken. I could get more elaborate with the code where the script finds and extracts the downstream frequencies.
    1ii) Point taken. Unless it can re-written in a proper scripting language that actually parses the html table, I have no good soltion.
    1iii) See 1ii.
    2) I intentionally didn't use fully qualified paths in case someone wants to run it on a non-tomato router. It can run on any system with wget, sh, grep, sed, awk for example. Even cygwin!
    3) This isn't part of the script, just text in my visualizations.
    4) Fixed.

    EDIT: dygraphs is very cool looking... I need to learn how to use it!
  6. darksky

    darksky Addicted to LI Member

    OK! I updated the original post to a new github repo containing an update script, dygraphs js module, and example index.html. Feedback is appreciated.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice