DHCP client issues

[Daniele Orlandi]

Hello,

I'm having this issue (maybe two) which, after digging a bit around I 
presume are related to dhclient.

This is what I do to reproduce the issues:

- Boot the system with ethernet cable disconnected
- Wait dhclient to timeout
- Connect the cable
- dhclient keeps sleeping and the interface is still without address

My context:

- Debian Jessie on an ARM system (cubieboard2).
- dhclient 4.3.1

This is the output of dhclient when run by hand:


----------------------------------------------------------------
# dhclient -d -v -pf /run/dhclient.eth0.pid -lf /var/lib \
   /dhcp/dhclient.eth0.leases eth0

Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/02:14:06:40:c1:2c
Sending on   LPF/eth0/02:14:06:40:c1:2c
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
No DHCPOFFERS received.
Trying recorded lease 192.168.1.157
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

bound: renewal in 120825 seconds.
----------------------------------------------------------------

It looks like the IP address is properly taken from a previously 
obtained lease, however the address is actually not assigned to the 
interface being down:

# ip link show eth0
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast 
state DOWN mode DEFAULT group default qlen 1000
     link/ether 02:14:06:40:c1:2c brd ff:ff:ff:ff:ff:ff

When a cable is connected is appears that dhclient does not notice the 
link status change (is it supposed to? I think it should!) and just 
keeps the lease for that long time without actually assigning the IP 
address to the interface.



The second issue is that the board lacks a RTC chip and always boots 
with the real time clock set to 2010/1/1 0:00 UTC thus when calculating 
the lease length huge numbers may come out if the old lease has been 
obtained while NTP-synced:


------------------------------------
No DHCPOFFERS received.
Trying recorded lease 192.168.1.157
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

bound: renewal in 166644509 seconds.
-------------------------------------


What concerns me is that some scenario (for example a power cycle of the 
device and its connected switch) may lead to a boot where the IP address 
is not properly assigned if not in days/years.

Thank you,
Bye,

-- 
   Daniele Orlandi