Introduction

Older Westell ADSL modems (such as the 2100/2200 series) only allow ADSL line stats to be gathered by a very bizarre multicast/broadcast packet arrangement. These modems do not have a HTTP, SNMP, or Telnet interface. There exists a package of utilities, called wdiag, that will start or stop the multicast packet stream and gather the multicasted data. However, these utilities can be somewhat difficult to set up.

Procedure

I assume the modem is installed in a device with at least two NICs. My particular setup has three, but it does not matter. For the purposes of the example, eth0 will be the internal interface, and eth1 will be the interface to which the Westell modem is connected. I assume that the Westell modem is operating in bridge mode, and that network traffic is being carried over PPPOE (which is assumed to be on ppp0). The machine is also performing stateful firewalling, so it will be necessary to add an iptables rule to allow the incoming multicast packets from the modem.

Keep in mind that the modem assumes that it is 192.168.1.1 when it is broadcasting packets. If your local network is using the 192.168.1.0/24 subnet, and your firewall machine is assigned the usual 192.168.1.1/32 address that one would expect for a gateway machine, then the firewall box will drop the incoming packets from the ADSL modem as being invalid, since its MAC address does not match that of the firewall box. If this situation applies to your setup, I suggest changing your local subnet to something that will not conflict with the modem. 10.0.0.0/8 and 172.16.0.0/16 are perfectly good reserved subnets that are often unused. Choose one of them.

First, we need to assign a proper IP to the eth1 interface to which the Westell modem is connected:

ifconfig eth1 192.168.1.180

It's not necessary to specify netmask and broadcast data; the defaults are fine with any recent Linux setup.

Next, we need to fix the routing table to allow the kernel to gather multicast packets from the modem that will be coming in via eth1.

route add -net 224.73.193.0 netmask 255.255.255.0 dev eth1

These modems broadcast hardcoded source and destination values for the multicast UDP, so this route is correct.

Next, we need to punch a hole in our firewall to allow the incoming multicast packets. I assume that OUTPUT packets are not filtered, so I'm not adding an explicit rule for those. The following rule will probably have to be slightly adapted to match your firewall script.

iptables -A INPUT -i eth1 -p udp -d 224.73.193.62/32 -s 192.168.1.1/32 \
	--sport 1875 --dport 1875 -j ACCEPT

Now all that remains is to start the modem statistics broadcasts and to listen:

wstart
westell

If no stats are gathered, then the best diagnostic is to use a packet sniffer to confirm that the packets are indeed incoming. Stat packets are 120 byte UDP packets that originate from 192.168.1.1:1875 and are sent to 224.73.193.62:1875 multicast. I use tethereal to check:

tethereal -V -i eth1

I've also written a perl script that can decode the packet dumps that tethereal produces. Just copy and paste the UDP packet contents (only the part that looks like output from a hex editor) to a file and use wdecode:

wdecode.pl < input

If these packets are showing up on the interface, then the problem is most likely with your linux box's firewall rules, routing tables, or interface IPs. Recheck the above and consider if some of the advice might have to be adapted to your setup.