HOWTO: Monitor an Alcatel SpeedTouch 510 ADSL Modem

Update: As it turns out, after a firmware upgrade, the SpeedTouch does have SNMP. It can be enabled from the command line using snmp config ROCommunity="public" (for instance), and from then on it's just the same as any other box (hint: snmpwalk -v1 -c public 10.0.0.138 .1.3.6.1.2.1 will get you started). Nevertheless, the basic technique detailed below is useful for other kinds of boxes that do not expose interface statistics over SNMP.

Since the Alcatel SpeedTouch 510 does not support SNMP to gather firewall rule statistics, I was forced to find another way to monitor its traffic usage with RRDTool. Since I had a firmware version that only supported Telnet for a long while, I went ahead and figured out how to monitor it that way.

(This is a hack, mind you. I'll be doing a proper script for my own use, and have kept this down to the bare minimum: no command-line options, no fancy output: just the "N:(bytesin):(bytesout)" that RRDTool likes to have to do its stuff. Of course, if this blows up your modem, stir-fries your cat and forces you to download Britney Spears MP3s, it's your own fault.)

Ingredients:

• Just about any version of Perl
• Access to CPAN
• A text editor
• A monitor and keyboard, preferably attached to a working computer
• Did I mention you need an Alcatel SpeedTouch 510 ADSL Modem?
• With a PPPoE connection? (you can change the code for other kinds of connection)

Preparation:

Use CPAN to install Net::Telnet (Documentation).

(The impatient can just utter perl -MCPAN -e install Net::Telnet and leave it to settle for a few minutes)

Open your text editor and paste in the following code:

(Note: the Wiki parser munges part of the Perl syntax, so beware - this is standard Perl, not "Mac Perl" as someone stated on a forum once)

#!/usr/bin/perl
use Net::Telnet();
$oSpeedTouch = new Net::Telnet( Timeout=>10, Prompt=>'/=>/');
$oSpeedTouch->open("(");
$oSpeedTouch->login("", "");
@lines = $oSpeedTouch->cmd( "ip iflist");
foreach( @lines ) {
  @aFields = split/\s+/;
  if( $aFields[0] =~ /\d/ ) {
    if( $aFields[1] =~ "pppoe" ) {
      print "N:" . $aFields[4] . ":" . $aFields[5];
    }
  }
}
$oSpeedTouch->cmd(String=>"exit", Errmode=>"return");

The above code will get the bytes in/out stats from the WAN interface. You can get the same via SNMP, but if you want to do per-protocol statistics, you might want to use this approach for everything, since the SpeedTouch (even with SNMP) does not publish firewall rule counters (more on that below)

To get this to work, change the IP address to your modem's IP address (this model usually has the brain-dead factory default address 10.0.0.138, but sane people change it immediately) and, of course, season the username and password to your liking (it's the same you use to manage the modem via browser)

Serve with a cron job and a reasonable interval (say 5 minutes).

Those with more extravagant tastes may want to change the Perl interpreter, the output format and the interface to monitor (add a "print @lines;" to see what the modem spits out).

As I said above, the SpeedTouch does not publish firewall counters via SNMP (at least not in any way I could figure out). But to do protocol accounting, you have to be able to create the counters in the first place, and that's what most people don't know how to do.

The SpeedTouch's IP stack allows you to create ipchains-like "chains" at five distinct points in the packet path: input, sink, forward, source, and output. These names are relative to the router itself and not to any particular interface, and are covered in one of the many "SpeedTouch Firewall" PDFs you may find floating around on the Net. Just Google for it, there are plenty copies around.

I read through one written for the 610, which seems to be basically the same as the 510 minus a couple of bugs. One of those bugs was that I could not do anything with the input chain, so all my examples use forward and the relevant interface group.

But let's not dally. So, to count HTTP traffic to my server, I look at the WAN interface group, and do:

:firewall rule create chain=forward srcintfgrp=wan prot=tcp dstport=80 action=count
:firewall rule create chain=forward dstintfgrp=wan prot=tcp srcport=80 action=count

(The router will complain and say "the action for this rule is not decisive", but that's because the action is count)

The first rule counts inbound WAN packets to port 80, and the second counts the replies. The router will add these to the forward chain and add an index to them, so that if you look at the entire rulebase you'll see:

[firewall]=>:firewall rule list
:firewall rule create chain=source index=0 dstintfgrp=!wan action=accept
...
:firewall rule create chain=source index=5 action=drop
:firewall rule create chain=forward index=0 srcintfgrp=wan dstintfgrp=wan action=drop
:firewall rule create chain=forward index=1 srcintfgrp=wan prot=tcp dstport=www-http action=count
:firewall rule create chain=forward index=2 dstintfgrp=wan prot=tcp srcport=www-http action=count
...

Now, to get at the statistics, you'll have to keep track of the rule indexes:

[firewall]=>:firewall rule stats
Chain source, index 0, packets 461863, bytes 77896387
...
Chain source, index 5, packets 2056, bytes 115136
Chain forward, index 0, packets 0, bytes 0
Chain forward, index 1, packets 3158, bytes 322872
Chain forward, index 2, packets 3888, bytes 4380379
...

...and that's where the script above needs a lot more of brainpower. Unless you hard-code the indexes (a bad idea, especially when you want to keep track of several protocols), you need to do at least two passes: a rule list (which is parsed to get the indexes), and then a rule stats to get the corresponding values.

Still, it's fairly easy to do, and if I manage to break it out of my home-made stats framework, I'll post the code here.

To do outbound traffic statistics from your machines (if you really want to do it per machine), you will have to look at the other interface group (just use srcintfgrp=!wan) and add the source address(es) to the rule. Since there is no apparent way to add counters to NAT rules, this will be the way to go if you want to keep track of sessions initiated on the LAN.

Note: Since this is the most commonly referenced Alcatel node in my site, I thought it was the best place to link to this great Guide to Pinholing (i.e., opening specific protocols like 47/GRE and 41/6to4) on the SpeedTouch