Testing the DHCP client on the WAN interface

The average modem/router doesn't have the ability to capture traffic on the WAN interface, so it's hard to see what's going on when the DHCP client fails to assign/renew the IP address on the WAN interface.

The solution (if one has suitable hardware available) is to create a test setup using a separate ADSL modem (e.g. another modem/router in bridge mode), and then configure the modem/router under test to use the DHCP client on its Ethernet port(s) rather than on its ADSL port. Then one needs a way to use a sniffer program like Wireshark to monitor the traffic between the ADSL modem and the router under test.

One way to achieve this is with a PC with two Ethernet ports bridged together, and running Wireshark:

Modem/router <-----> PC with Wireshark <-----> ADSL Modem <=====> phone socket
(where <-----> is Ethernet and <=====> is phone cable)

If the box being used as the ADSL modem is a Speedtouch/Thomson/Technicolor box, there's an easier solution. The firmware (on the boxes I have) allows one to setup one Ethernet port as a monitor for another port - so one can run Wireshark on that monitor port and view the traffic flowing on the other port.
For example, I use Ethernet port 1 as the link from the ADSL modem to the router, and configure Ethernet port 4 as the monitor port. This is achieved by telnetting to the modem, and issuing the commands:

:eth switch mirror capture port=4
:eth switch mirror ingress port=1 state=enabled
:eth switch mirror egress port=1 state=enabled

Now a computer plugged in to Ethernet port 4 and running Wireshark sniffs the traffic flowing (in both directions) on Ethernet port 1.

The hardest part is reconfiguring the modem/router to run the DHCP client on its Ethernet port(s).

Running the DHCP client on Ethernet port(s)

Netgear DG834 series (and similar boxes)

You can't separate the Ethernet ports from one another, so you have to treat all the Ethernet ports in the same way. This means that during testing you can only connect to the Netgear via wireless.
Telnet or ssh in via wireless, and then remove the Ethernet ports from the internal bridge:

/usr/sbin/brctl delif br0 eth0
Now you can run the DHCP client on the Ethernet ports, using something like:
/usr/sbin/udhcpc -i eth0 -f /etc/udhcpc.script
Note that there are two possible helper scripts one can use: Whichever one you use, you might want to incorporate the change I made in my firmware which stops the WAN uptime from being reset whenever the lease is renewed. On a running Netgear, /etc is writeable, so you can modify one line in the script from
/bin/cp /proc/uptime /tmp/wan_uptime
[ "$1" = "bound" ] && /bin/cp /proc/uptime /tmp/wan_uptime
With this change in place, the WAN uptime should keep on increasing if the DHCP lease is renewed properly. If the WAN uptime keeps on getting reset, then the DHCP lease isn't being renewed and you're getting new leases instead.

Note that you can't really use the Internet from attached devices, this is just for testing DHCP. You'd have to setup the firewall to get the Internet working from attached devices.


You can separate out individual Ethernet ports on these boxes, so you can run the DHCP client on just, for example, Ethernet port 4.

I based these the following instructions on ST780 WAN through LAN.

Telnet to the box, and issue the commands:

:eth bridge ifdelete intf=ethport4
:eth ifadd intf=eth_wan
:eth ifconfig intf=eth_wan dest=ethif4
:eth ifattach intf=eth_wan
:ip ifadd intf=ip_wan_eth dest=eth_wan
:ip ifconfig intf=ip_wan_eth status=up
:ip ifattach intf=ip_wan_eth
This removes Ethernet port 4 from the bridge, and creates a new IP interface named ip_wan_eth which is attached to Ethernet port 4.
Now save the configuration to a file, and edit the file - search for all instances of your current WAN interface name (Internet or Static) and, where there's no matching line for ip_wan_eth, substitute the WAN interface name with ip_wan_eth. You'll probably find this just affects the dhcc.ini and nat.ini sections of the configuration file. Now restore the configuration to the box, and reboot it. You should find that Ethernet port 4 is now being used for the WAN connection, and is no longer usable as a LAN port.

Wireshark capturing

It's probably best to capture all the data on the link between modem/router and the ADSL modem, assuming that the link is quiet during the test period. Otherwise you can use a filter looking for traffic on UDP port 67 to capture only the DHCP traffic (but then you might miss something else which is happening when the DHCP problem occurs).

Wireshark capture filterudp port 67
Wireshark display filterudp.port eq 67