dhcpcd-discuss

Hi Roy,
 
 
On Fri, 17 Oct 2014 at 03:40:00, Roy Marples wrote:
> On 17/10/2014 10:01, Roy Marples wrote:
>> Hi David
>> 
>> On 17/10/2014 00:52, David Hauck wrote:
>>> I wanted to run through a quick search of the mailing list but your domain seems to be down (??).
>> 
>> Yeah, server upgrade time. Not enough memory on the server to keep
>> everything up AND compile clang + llvm when the OS wants an updated
>> compiler. Not sure if I can put more memory in it either :/

;)
 
>>> I wonder if you might be able to comment on a new DHCPCD test I've
>>> been trying to run/configure. It's pretty basic ;).
>>> 
>>> I've configured a 20s timeout along with ipv4ll and am testing
>>> various scenarios where the connected DHCP server
> is offline/online. I simulate this online/offline behaviour by
> plugging in one of two interface cables to the configured DHCP
> interface. One cable (C1) connects directly to a standalone node
> (Windows PC - no DHCP server
> running) and the other cable (C2) connects to a LAN ( where a DHCP server is reachable).
>>> 
>>> When C1 is connected and I bring up the interface I see an expected timeout and fallback via IPV4LL:
>>> 
>>> # ifup eth1
>>> dhcpcd[30900]: version 6.1.0 starting
>>> dhcpcd[30900]: eth1: waiting for carrier
>>> dhcpcd[30900]: eth1: carrier acquired
>>> dhcpcd[30900]: eth1: soliciting a DHCP lease
>>> dhcpcd[30900]: timed out
>>> dhcpcd[30900]: allowing 8 seconds for IPv4LL timeout
>>> dhcpcd[30900]: eth1: probing for an IPv4LL address
>>> dhcpcd[30900]: eth1: using IPv4LL address 169.254.37.21
>>> dhcpcd[30900]: eth1: adding host route to 169.254.37.21 via
>>> 127.0.0.1
>>> dhcpcd[30900]: eth1: adding route to 169.254.0.0/16
>>> dhcpcd[30900]: forked to background, child pid 30969
>>> 
>>> When I disconnect C1 and then connect C2 I see the following in the system log:
>>> 
>>> 20141016 16:24:48.215 info daemon(dhcpcd):eth1: carrier lost
>>> 20141016 16:24:48.224 info daemon(dhcpcd):eth1: deleting host route
>>> to 169.254.37.21 via 127.0.0.1
>>> 20141016 16:24:48.224 info daemon(dhcpcd):eth1: deleting route to
>>> 169.254.0.0/16
>>> 20141016 16:24:48.236 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=NOCARRIER, beeppid=0, ip=, sn=, gw=, dns=,
>>> options=, hn=
>>> 20141016 16:24:53.488 info daemon(dhcpcd):eth1: carrier acquired
>>> 20141016 16:24:53.504 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=CARRIER, beeppid=30986, ip=, sn=, gw=, dns=,
>>> options=, hn=
>>> 20141016 16:24:58.628 info daemon(dhcpcd):eth1: using IPv4LL
>>> address
>>> 169.254.37.21
>>> 20141016 16:24:58.628 info daemon(dhcpcd):eth1: adding host route
>>> to
>>> 169.254.37.21 via 127.0.0.1
>>> 20141016 16:24:58.628 info daemon(dhcpcd):eth1: adding route to
>>> 169.254.0.0/16
>>> 20141016 16:24:58.644 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=IPV4LL, beeppid=30986, ip=169.254.37.21,
>>> sn=255.255.0.0, gw=, dns=, options=, hn=
>>> 20141016 16:25:00.655 info daemon(dhcpcd):eth1: deleting host route
>>> to 169.254.37.21 via 127.0.0.1
>>> 20141016 16:25:00.655 info daemon(dhcpcd):eth1: deleting route to
>>> 169.254.0.0/16
>>> 20141016 16:25:00.667 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=EXPIRE, beeppid=0, ip=, sn=, gw=, dns=, options=,
>>> hn=
>>> 20141016 16:25:01.673 info daemon(dhcpcd):eth1: probing for an
>>> IPv4LL address
>>> 20141016 16:25:06.529 info daemon(dhcpcd):eth1: using IPv4LL
>>> address
>>> 169.254.183.168
>>> 20141016 16:25:06.529 info daemon(dhcpcd):eth1: adding host route
>>> to
>>> 169.254.183.168 via 127.0.0.1
>>> 20141016 16:25:06.529 info daemon(dhcpcd):eth1: adding route to
>>> 169.254.0.0/16
>>> 20141016 16:25:06.544 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=IPV4LL, beeppid=31033, ip=169.254.183.168,
>>> sn=255.255.0.0, gw=, dns=, options=, hn=
>>> 20141016 16:25:06.554 info daemon(dhcpcd):eth1: deleting host route
>>> to 169.254.183.168 via 127.0.0.1
>>> 20141016 16:25:06.554 info daemon(dhcpcd):eth1: deleting route to
>>> 169.254.0.0/16
>>> 20141016 16:25:06.566 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=EXPIRE, beeppid=0, ip=, sn=, gw=, dns=, options=,
>>> hn=
>>> 20141016 16:25:07.572 info daemon(dhcpcd):eth1: probing for an
>>> IPv4LL address
>>> 20141016 16:25:12.335 info daemon(dhcpcd):eth1: using IPv4LL
>>> address
>>> 169.254.141.18
>>> 20141016 16:25:12.335 info daemon(dhcpcd):eth1: adding host route
>>> to
>>> 169.254.141.18 via 127.0.0.1
>>> 20141016 16:25:12.348 info daemon(dhcpcd):eth1: adding route to
>>> 169.254.0.0/16
>>> 20141016 16:25:12.365 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=IPV4LL, beeppid=31068, ip=169.254.141.18,
>>> sn=255.255.0.0, gw=, dns=, options=, hn=
>>> 20141016 16:25:14.376 info daemon(dhcpcd):eth1: deleting host route
>>> to 169.254.1
>>> 41.18 via 127.0.0.1
>>> 20141016 16:25:14.376 info daemon(dhcpcd):eth1: deleting route to
>>> 169.254.0.0/16
>>> 20141016 16:25:14.388 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=EXPIRE, beeppid=0, ip=, sn=, gw=, dns=, options=,
>>> hn=
>>> 20141016 16:25:15.394 info daemon(dhcpcd):eth1: probing for an
>>> IPv4LL address
>>> 20141016 16:25:20.411 info daemon(dhcpcd):eth1: using IPv4LL
>>> address
>>> 169.254.10.96
>>> 20141016 16:25:20.411 info daemon(dhcpcd):eth1: adding host route
>>> to
>>> 169.254.10.96 via 127.0.0.1
>>> 20141016 16:25:20.411 info daemon(dhcpcd):eth1: adding route to
>>> 169.254.0.0/16
>>> 20141016 16:25:20.426 info daemon(dhcpcd):eth1: 60-netacquire:
>>> received reason=IPV4LL, beeppid=31105, ip=169.254.10.96,
>>> sn=255.255.0.0, gw=, dns=, options=, hn=
>>> 
>>> The '60-netacquire' lines are simple echoes I've done from a custom
>>> hook script. The key thing to note here is that the DHCPCD state
>>> machine seems to be cycling between EXPIRE and IPV4LL (and each IPV4LL
>>> has a new address).
>>> 
>>> I believe there is ample (intricate?) guidance on several aspects
>>> of this (RFC 3927 and RFC 4436) but I'm not
> familiar enough with these and DHCPCD to know how to interpret these
> results. At a high level it seems that the DHCP state machine should
> revert to attempting to contact the DHCP server after C1 is disconnected and then C2 is connected (since the DHCP server is reachable once C2 is connected). Why isn't this happening?
>>> 
>>> If I bring down the interface (with C2 connected) and then bring it up again a proper lease is provided:
>>> 
>>> dhcpcd[6119]: version 6.1.0 starting
>>> dhcpcd[6119]: eth1: waiting for carrier
>>> dhcpcd[6119]: eth1: carrier acquired
>>> dhcpcd[6119]: eth1: soliciting a DHCP lease
>>> dhcpcd[6119]: eth1: offered 205.159.216.180 from 205.159.216.146
>>> dhcpcd[6119]: eth1: leased 205.159.216.180 for 28800 seconds
>>> dhcpcd[6119]: eth1: adding host route to 205.159.216.180 via
>>> 127.0.0.1
>>> dhcpcd[6119]: eth1: adding route to 205.159.216.128/25
>>> dhcpcd[6119]: eth1: adding default route via 205.159.216.130
>>> dhcpcd[6119]: forked to background, child pid 6191
>> 
>> Can you test with dhcpcd-6.5.0 please? That's pretty close to where
>> trunk is for the most part, but I doubt the issue you're seeing is
>> any better. Is the only extra to the default config `timeout 20`?
> 
> I don't see this problem with dhcpcd-6.5.0 (well, the latest trunk).
> There was a problem, although unrelated, which resulted in this patch
> http://roy.marples.name/projects/dhcpcd/ci/4c1f2f8a298ad244f8c739710ba
> e46088ea7efd6?sbs=0 But that patch means nothing for 6.1.0.
> 
> So, can you test 6.5.0 with that patch please?

Sure, I'll test either 6.5.0 of 6.1.0 with the patch, but may not get to this before the end of the day.

Thanks,
-David

> Thanks
> 
> Ry
> 
> 
> ---
> This email is free from viruses and malware because avast! Antivirus protection is active.
> http://www.avast.com