NetComm modems/routers reject unrecognised leases in a way that confuses 'dhclient'

Xavion xavion.0 at
Thu Mar 17 10:11:23 UTC 2011

Hi All

I posted the following message to the NetworkManager and Arch Linux bug
trackers.  For a broader background, you can follow those two threads
here <>.  All of it relates to
'dhcpcd', but 'dhclient' reacts similarly.  Based on the feedback from those
developers, I now realise that this is probably something the 'dhclient'
developers should look into.

If my modem/router is switched off (e.g. overnight), I can't reconnect - via
> Ethernet or wireless - the next time it's switched on, without having to
> mess around first.
> This is because your script doesn't terminate 'dhcpcd' via the '-k' option.
> The effect is that the stale ".lease" file from the previous session (day)
> remains in "/var/lib/dhcpcd/".
> This ".lease" file is automatically reused when reconnecting, but my
> modem/router forgot about it while switched off (e.g. overnight). This means
> that initial connection attempts are rejected until I delete it.
> I'm guessing that all users with NetComm modem/routers - and probably
> others - would be facing this problem every time they switch theirs on. Will
> you please terminate 'dhcpcd' using the '-k' option in future releases?
> For example, instead of using "/usr/bin/killall dhcpcd", you would use
> "/sbin/dhcpcd -k [interface]". I have already tested this here and I can
> confirm that the stale ".lease" file is deleted as expected.

The context is that I had a working connection and I rebooted my
modem/router for testing purposes.  You can see from the attached output
what happened when I then tried to reconnect.  Instead of rejecting the
(now) unrecognised lease, my modem/router acknowledged it and set the IP
address to "".

I can see that this isn't the sort of behaviour that 'dhclient' should be
expecting, but there would be heaps of Linux users with NetComm
modems/routers out there.  For that reason, I thought you might want to add
a workaround in your code to treat such a response as a rejection, before
requesting a new lease.

I'm fairly sure that the Windows equivalent of 'dhclient' includes a similar
workaround, because I never have this problem when reconnecting to my
modem/router after restarting it (e.g. the next day).  I will also contact
the technical support area of NetComm to see if they can provide any insight
about the issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
`--> sudo dhcpcd -d       
dhcpcd: unknown option -- localhost
dhcpcd[11259]: version 5.2.11 starting
dhcpcd: unknown option -- localhost
dhcpcd[11259]: eth0: using hwaddr <removed>
dhcpcd[11259]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd[11259]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: unknown option -- localhost
dhcpcd[11259]: eth0: reading lease `/var/lib/dhcpcd/'
dhcpcd[11259]: eth0: rebinding lease of
dhcpcd[11259]: eth0: sending REQUEST (xid 0x290a09ba), next in 4.78 seconds
dhcpcd[11259]: eth0: acknowledged from
dhcpcd[11259]: eth0: leased for 86400 seconds
dhcpcd[11259]: eth0: adding IP address
dhcpcd[11259]: eth0: router requires a host route
dhcpcd[11259]: eth0: router requires a host route
dhcpcd[11259]: eth0: adding route to
dhcpcd[11259]: eth0: adding route to
dhcpcd[11259]: eth0: adding host route to
dhcpcd[11259]: eth0: adding default route via
dhcpcd[11259]: eth0: writing lease `/var/lib/dhcpcd/'
dhcpcd[11259]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason REBOOT
dhcpcd[11259]: forking to background
dhcpcd[11259]: forked to background, child pid 11289

More information about the dhcp-users mailing list