dhcpcd-discuss

Roy Marples <roy@xxxxxxxxxxxx> writes:

> On Wed, 2008-11-26 at 09:54 +0100, Jean Wolter wrote:
>> It does help - dhcpcd now actually uses the montonic clock provided by
>> the underlying kernel. But it does not solve the problem we are
>> experiencing.
>
> http://www.uclibc.org/lists/busybox/2007-July/028051.html
> uclibc-0.9.28 supports it but uclibc-0.9.27 doesn't.
>
> So I guess I'd rather that you upgraded to uclibc-0.9.28

I am not expecting you to fix problems with older versions of
libraries. I just tried to point out, that the monotonic clock is used
and is therefore not the solution to the problem we see.

>> So the bug seems to be the unconditional timeout reset in
>> handle_link().
>
> Could be.
> I've attached a patch that may help you, but I need to regression test
> it a little before applying.
> Another attached patch should address this also.
>
> Let me know how they work for you!

Both changes work fine:

Wed Nov 26 19:52:20 2008: eth2: sending ARP probe (1 of 3), next in 1.02 seconds
Wed Nov 26 19:52:20 2008: eth2: ignoring offer of 192.168.1.33 from 192.168.1.1
Wed Nov 26 19:52:21 2008: eth2: ignoring offer of 85.5.83.104 from 138.187.24.10
Wed Nov 26 19:52:21 2008: eth2: sending ARP probe (2 of 3), next in 1.18 seconds
Wed Nov 26 19:52:23 2008: eth2: sending ARP probe (3 of 3), next in 2.00 seconds
Wed Nov 26 19:52:25 2008: eth2: sending DHCP_REQUEST with xid 0x5a7e98f9, next in 4.69 seconds

I booted the same setup on top of a 2.4 linux kernel, which does
not provide a monotonic clock - dhcpcd detected it correctly,
displayed the warning and used gettimeofday.

regards,
Jean