dhcpcd-discuss

Hi Mick

On Friday 05 Jun 2015 19:02:42 Mick wrote:
> I have over the years been confused about the ClientID Vs DUID Vs MAC
> address, or whatever various routers are using to give my laptop an IP
> address.  In addition, some routers take a long time to provide an IP
> address, which is annoying at best.  More recently (dhcpcd-6.9.0) I
> discovered that I end up with two addresses showing, an IP4ALL and a normal
> router provided address.

Here's some history :)

No ClientID == BOOTP pretty much
MAC based ClientID == most DHCP clients
DUID based ClientID == dual stack DHCP and DHCPv6 clients

Some DHCP tried to ensure ClientID was MAC based and threw a wobbly if not 
.... this should no longer be a problem with modern DHCP servers.

> I changed clientid to duid and back to client id in my dhcpcd.conf, but the
> behaviour is pretty much the same.  The router is contacted, an IP4ALL
> address is obtained within a couple of seconds, then a minute or so later I
> eventually get an address from the router.

This has nothing to do with the above discussion.

> dhcpcd is called from ifplug on my laptop, via an openrc network interface
> start up script - this is on a Gentoo build.

It won't fix your problem, but you get better mileage when you add dhcpcd to 
the default or boot runlevel and stop using the net.* scripts.

> Is there some way of waiting until the router's dhcpd responds before an
> IP4ALL IP address is sought for?  It seems to me that IP4ALL should be the
> IP address space of last resort, rather than the first thing to get.
> 
> Also, I end up with two addresses because the IP4ALL is not dropped after
> the router's dhcp server decides to respond:
> ======================================
> ip -s address show dev enp11s0                Fri Jun  5 18:53:06 2015
> 
> 2: enp11s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq state UP
> group def
> ault qlen 1000
>     link/ether 00:26:b9:20:b4:9c brd ff:ff:ff:ff:ff:ff
>     inet 169.254.181.113/16 brd 169.254.255.255 scope global enp11s0
>        valid_lft forever preferred_lft forever
>     inet 10.10.10.7/24 brd 10.10.10.255 scope global enp11s0
>        valid_lft forever preferred_lft forever
>     inet6 fe80::6446:88fd:e7eb:b031/64 scope link
>        valid_lft forever preferred_lft forever
>     RX: bytes  packets  errors  dropped overrun mcast
>     102630     603      0       362     0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     24236      220      0       0       0       0
> ======================================
> 
> Shouldn't the IP4ALL be dropped as soon as a dhcp address is obtained?

Yes it should.

This is a new bug in dhcpcd, probably introduced in dhcpcd-6.8.x and it stems 
off new code I have to work with new code only found in NetBSD which I have yet 
to decide how best to solve. I'll probably go for the best way of solving it, 
which is also sadly the slowest - but may have a more long term gain.

The problem is that in older dhcpcd version there was just DHCP. Over the 
years, more and more features have been added but the main IPv4 stack pretends 
it's a DHCP client through and through. I have already separated out the ARP 
and IPv4LL code quite nicely now, but the core state still needs to be split 
out some more. In a nutshell, when the DHCP address is added, dhcpcd loses 
track of the IPv4LL state which was added.

Now, this shouldn't be much of a real world problem - the extra address 
staying around is pretty harmless in itself.

Roy

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