dhcpcd-discuss

On Thu, 2008-12-18 at 10:14 +0100, jw5-dhcpcd@xxxxxxxxxxxxxxxxxxxx
wrote:
> dhcpcd 4.99 behaves differently, it restarts its checks and accepts
> the last IP offered:
> 
> 20:57:51 dhcpcd: version 4.99.6 starting
> 20:57:51 dhcpcd: eth2: broadcasting for a lease
> 20:57:51 dhcpcd: eth2: sending DHCP_DISCOVER (xid 0xae806b1), next in 3.11 seconds
> 20:57:52 dhcpcd: eth2: offered 192.168.1.33 from 192.168.1.1
> 20:57:52 dhcpcd: eth2: checking 192.168.1.33 is available on attached networks
> 20:57:52 dhcpcd: eth2: sending ARP probe (1 of 3), next in 1.77 seconds
> 20:57:52 dhcpcd: eth2: offered 192.168.1.33 from 192.168.1.1
> 20:57:52 dhcpcd: eth2: checking 192.168.1.33 is available on attached networks
> 20:57:52 dhcpcd: eth2: sending ARP probe (1 of 3), next in 1.15 seconds
> 20:57:52 dhcpcd: eth2: offered 92.105.164.116 from 138.187.24.107
> 20:57:52 dhcpcd: eth2: checking 92.105.164.116 is available on attached networks
> 20:57:52 dhcpcd: eth2: sending ARP probe (1 of 3), next in 1.07 seconds
> 20:57:53 dhcpcd: eth2: sending ARP probe (2 of 3), next in 1.62 seconds
> 20:57:55 dhcpcd: eth2: sending ARP probe (3 of 3), next in 2.00 seconds
> 20:57:57 dhcpcd: eth2: sending DHCP_REQUEST (xid 0xae806b1), next in 3.89 seconds
> 20:58:01 dhcpcd: eth2: sending DHCP_REQUEST (xid 0xae806b1), next in 8.53 seconds
> 20:58:02 dhcpcd: eth2: acknowledged 92.105.164.116 from 138.187.24.107
> 20:58:02 dhcpcd: eth2: leased 92.105.164.116 for 28800 seconds
> 
> At the end it leases the wrong IP. I am not sure whether this is a
> problem with dhcpcd or the dhcp servers (or the modem passing along
> the dhcp request to its own dhcp server). I just would like to point
> out, that the behaviour differs and it leave the client with an
> invalid interface setup.

I would say both - dhcpcd should NOT be changing which offer it uses
midway through and the modem should not be relaying the DHCP requests to
the outside world.
Future versions of dhcpcd may have a small time delay in discover ->
probe/request though so dhcpcd can pick and choose which offer to work
with.

> 
> On second thought I looked at the code and there is a difference
> between 4.0.4 and 4.99. After 4.0.4 receives an offer and before it
> starts the ARP probing it changes its state to STATE_PROBING and
> therefore ignores all following offers. 4.99 does not do this, it stays
> in the DHS_DISCOVER state which appears to cause the problem.

I've added the DHS_PROBE state and a new function start_request which
then changes state to DHS_REQUEST. This should fix this issue.

http://roy.marples.name/projects/dhcpcd/changeset/1126/trunk

dhcpcd-4.99.7 should be out over the weekend and should be the last
experimental release as we start moving to dhcpcd-5.

Thanks for testing!

Roy

Attachment: signature.asc
Description: This is a digitally signed message part