dhcpcd-discuss

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.

>> 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

>> 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/36e83c64395acafc9030cadef3b
>> 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).

Roy