dhcpcd-discuss

On Tuesday, October 21, 2014 12:11 PM, Roy Marples wrote:
> On 21/10/2014 19:46, 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?
> 
> Yes
> 
>> If so, do you mean dhcpcd will attempt to contact a DHCP server
>> every 64
> +/- 1 seconds?
> 
> Yes.
> On a reboot or carrier up it's after the ARP announcement has finished
> + a small random delay. If it's not that's a bug.
> 
>>> 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(?).
> 
> Yes, sorry.
> 
>> 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."
> 
> However, your kernel is not clearing it's stale ARP cache on these
> announcements, 

Well, this is the behaviour we're trying to get to the bottom of and it doesn't seem obvious that it should be doing this; there is no guidance/de facto description of the relevant behaviour in the case of these local ARP entries in a multihomed environment, where the interface in question is going online/offline, and when operating in conjuction with IPV4LL (i.e., ARP PROBEs vs. ARP ANNOUNCEs).

It's certainly true that "normal" ARP entries are only flushed based on the ARP implementation in the stack (on Linux this appears to when the ARP table reaches a default 1024 entries or the entry "times out" - i.e., no activity, ARP or otherwise - where the timeout is dynamic). 

> it's actually saying they are duplicates via ARP Would
> you like me to provide a human readable output from your trace?

That's OK, I've reviewed the trace in WS. It's clear what the node is doing (i.e., not reporting that it *owns* the address during the PROBEs but further identifying a conflict during the ANNOUNCE phase). 

I'm not defending the stack's behaviour in this regard. As I mentioned earlier it's been hard to find any guidance/de facto descriptions for what the stack should be doing in these cases. I'm sure this must exist, I just haven't found anything on this yet...

> Or too see for yourself, install wireshark and open it. Filter on arp
> || bootp to see all the relevant transactions.
> 
> Roy