dhcpcd-discuss

On Friday, October 24, 2014 1:03 PM, Roy Marples wrote:
> On Thursday 23 Oct 2014 21:28:33 Roy Marples wrote:
>> On Wednesday 22 Oct 2014 16:07:49 Roy Marples wrote:
>>> On 22/10/2014 16:01, David Hauck wrote:
>>>> I wonder if this behaviour should be configurable?
>>> 
>>> No.
>>> 
>>> I actually had a better idea and am working on making a better ARP
>>> state engine, so we can have two, one for DHCP and one for IPv4LL.
>>> This should allow dhcpcd to negotiate DHCP and IPv4LL at the same time.
>> 
>> This has now been done.
>> 
>> DHCP will start.
>> After 5 seconds IPv4LL will start.
>> 
>> So far, I've only tested that it works - I still need to test
>> conflict and defence for IPv4LL.
> 
> I've fixed a few bugs since the initial patch and it now seems very
> stable and reliable. Valgrind is reporting no memory errors as well.
> 
> The intial reported issue remains solved while allowing concurrent
> DHCP and ARP requests :)
> 
> Testing of the trunk tarball would be nice at this point, just incase
> I've missed something silly :)
> http://roy.marples.name/projects/dhcpcd/tarball/dhcpcd- trunk.tar.gz

I just ran a quick test of this. 

I'm seeing is two things:

1. When I go from a legitimately BOUND case (DHCP server assigned address) to a failure case (i.e., C1 unplugged, C2 plugged - i.e., connected DHCP server to no connected DHCP server) I don't see IPV4LL being negotiated (I just see continual DISCOVER messages being sent). This seems to go on forever.

2. When I'm in an IPV4LL state and then switch cables to C1 (connected DHCP server) I see an eventually DHCP BOUND case (i.e., legitimate IP address). However, what's odd about this scenario is that while the DHCP server is being contacted I would have thought the IPV4LL state machine would also be active - i.e., the old IPV4LL lease would be attempted. In my current configuration I have *no* IPV4LL addresses in my ARP cache so there can't have been any collisions. 

Thanks,
-David
 
> Thanks
> 
> Roy