dhcpcd-discuss

On Mon, 24 Nov 2008 13:58:24 +0100, Jean Wolter
<jw5-dhcpcd@xxxxxxxxxxxxxxxxxxxx> wrote:
> dhcpcd starts up, gets an offer after discovery and tries to check via
> ARP, whether the offered IP is free. dhcpcd times out during this
> check and leaves the interface un-configured. The following excerpt of
> the system log shows this behavior:
> 
> Mon Nov 17 19:36:52 2008: + /sbin/dhcpcd -d -c /etc/dhcpcd.sh eth2
> Mon Nov 17 19:36:52 2008: eth2: dhcpcd 4.0.4 starting
> Mon Nov 17 19:36:52 2008: eth2: hardware address = 00:0d:b9:06:55:9e
> Mon Nov 17 19:36:52 2008: eth2: executing `/etc/dhcpcd.sh', reason
PREINIT
> Mon Nov 17 19:36:52 2008: eth2: host does not support a monotonic clock -
> timing can skew
> Mon Nov 17 19:36:52 2008: eth2: broadcasting for a lease
> Mon Nov 17 19:36:52 2008: eth2: sending DHCP_DISCOVER with xid 0xfa958c3,
> next in 3.19 seconds
> Mon Nov 17 19:36:52 2008: eth2: offered 192.168.1.33 from 192.168.1.1
> Mon Nov 17 19:36:53 2008: eth2: checking 192.168.1.33 is available on
> attached networks
> Mon Nov 17 19:36:53 2008: eth2: sending ARP probe (1 of 3), next in 1.81
> seconds
> Mon Nov 17 19:36:53 2008: eth2: ignoring offer of 192.168.1.33 from
> 192.168.1.1
> Mon Nov 17 19:36:53 2008: eth2: ignoring offer of 85.5.83.104 from
> 138.187.24.10
> Mon Nov 17 19:37:33 2008: eth2: timed out
> 
> If I disable the arp check, dhcpcd assigns the offered IP and
> everything is fine.
> 
> Is this a bug? Somehow I have the impression that the additional
> offers confuse the state machine of dhcpcd and it misses the timeouts
> for the ARP probes and in turn forgets to conclude that the IP is not
> assigned and can be acknowledged/leased.

The state machine of dhcpcd-3 and dhcpcd-4 can get easily confused when the
timing goes wrong.
That is why you have this warning
> Mon Nov 17 19:36:52 2008: eth2: host does not support a monotonic clock -
> timing can skew

I would guess from that you're running dhcpcd in an embedded environment?
IIRC some ucLibc versions don't work well with clock_gettime.
I've attached a patch that talks directly to the kernel for CLOCK_MONOTONIC
if the libc call fails.
Does this fix things?

Thanks

Roy

Attachment: bin4oIlXVG_K3.bin
Description: Binary data