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 :saveall
The hardest part is reconfiguring the modem/router to run the DHCP client on its Ethernet port(s).
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 eth0Now you can run the DHCP client on the Ethernet ports, using something like:
/usr/sbin/udhcpc -i eth0 -f /etc/udhcpc.scriptNote that there are two possible helper scripts one can use:
/bin/cp /proc/uptime /tmp/wan_uptimeto
[ "$1" = "bound" ] && /bin/cp /proc/uptime /tmp/wan_uptimeWith 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 :saveallThis removes Ethernet port 4 from the bridge, and creates a new IP interface named ip_wan_eth which is attached to Ethernet port 4.
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 filter | udp port 67 |
---|---|
Wireshark display filter | udp.port eq 67 |