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

[Xavion]

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<https://bugzilla.gnome.org/show_bug.cgi?id=644798>and
here <https://bugs.archlinux.org/task/23282>.  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 "0.0.0.0".

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: <https://lists.isc.org/pipermail/dhcp-users/attachments/20110317/ecc04d83/attachment.html>
-------------- 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-eth0.lease'
dhcpcd[11259]: eth0: rebinding lease of 192.168.1.3
dhcpcd[11259]: eth0: sending REQUEST (xid 0x290a09ba), next in 4.78 seconds
dhcpcd[11259]: eth0: acknowledged from 192.168.1.1
dhcpcd[11259]: eth0: leased 0.0.0.0 for 86400 seconds
dhcpcd[11259]: eth0: adding IP address 0.0.0.0/24
dhcpcd[11259]: eth0: router 0.0.0.0 requires a host route
dhcpcd[11259]: eth0: router 192.168.1.1 requires a host route
dhcpcd[11259]: eth0: adding route to 0.0.0.0/32
dhcpcd[11259]: eth0: adding route to 0.0.0.0/24
dhcpcd[11259]: eth0: adding host route to 192.168.1.1
dhcpcd[11259]: eth0: adding default route via 192.168.1.1
dhcpcd[11259]: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease'
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