dhcpcd-discuss

On Tuesday, October 21, 2014 11:32 AM, Roy Marples wrote:
> On 21/10/2014 17:00, David Hauck wrote:
>> As an aside, what is the expiry timeout associated with a normally
>> (i.e.,
> initially) configured IPV4LL lease/address?
> 
> No timeout. When dhcpcd gets one it will attempt to discover a DHCP
> leave every 64 + -1/+1 seconds.

What is meant by "When dhcpcd gets one"? Do you mean gets an IPV4LL address? If so, do you mean dhcpcd will attempt to contact a DHCP server every 64 +/- 1 seconds?

>>> Here's what happens
>>> 
>>> eth1 -> who owns 169.254.1.1?
>>> eth1 -> who owns 169.254.1.1?
>>> eth1 -> who owns 169.254.1.1?
>>> no replies, great I'll assign the address and announce it.
>>> eth1 -> I own 169.254.1.1
>>> eth0 -> no, I own 169.254.1.1
>>> eth1 -> I own 169.254.1.1
>>> eth0 -> no, I own 169.254.1.1
>>> eth1 has now failed to defend its IPv4LL address and must discard
>>> it and start over
>>> 
>>> Normally, if eth0 really did have 169.254.1.1 it would say this for
>>> each of the initial 3 requests eth1 made. But it didn't.
>> 
>> Are you positive that this is how the ARP PROBE and ARP ANNOUNCE
> semantics are meant to work? I can imagine (one would need to fully
> read all the associated RFCs/guidance on this to be sure - e.g., RFCs
> 826, 5227) that the ARP PROBE sequence is meant to query whether
> anyone else actually OWNS the address, i.e., *not* whether anyone else
> has the address in its ARP cache - these are different things. And
> also, subsequently, that the ARP ANNOUNCE is further (more strongly)
> saying *I am now using this address* and, like any gratuitous ARP,
> would result in a reply if anyone else had this identical entry in
> their ARP *cache*. So, I can see the potential for reading this as being incorrect/confusing.
> 
> What I decribed about is fully described in RFC3927 sections 2.2.1,
> 2.2.4 and 2.2.5

I believe the last two references should be for 2.4 and 2.5(?). 

I think there may be some reading between the lines in these sections. For example, there isn't anything in section 2.2.1 that specifically indicates another connected host should indicate they *own* the address if they have a *stale* ARP cache. Indeed, it is only the ARP ANNOUNCE state that will guarantee this - from section 2.4:

"The purpose of these ARP announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address."
 
>>> Because dhcpcd did actually assign the address, the IPv4LL conflict
>>> counter was reset and started the process over.
>>> 
>>> This is fixed here:
>>> 
>>> http://roy.marples.name/projects/dhcpcd/ci/36e83c64395acafc9030cadef3
>>> b 5fd3082edccbd?sbs=0
>>> 
>>> Basically we now only reset the conflict counter after the
>>> announcing is complete or we bind a non IPv4LL address. If we hit
>>> the conflict counter dhcpcd now transitions back to DHCP discovery.
>> 
>> What is the conflict "counter"?
> 
> It's the number of conflicting addresses we have attempted to use. See
> RFC3927 section 2.2.1 for the intended use (ie, rate limiting, I also
> use it to attempt DHCP once hit).

OK, thx (MAX_CONFLICTS defined in section 9 of 3927). 

> Roy