dhcpcd-discuss

On 25/10/2014 10:56, Roy Marples wrote:
> On Friday 24 Oct 2014 22:44:20 David Hauck wrote:
>>> 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.
> 
> I've done an even quicker test and I think both issues are now resolved.
> However my test was with wireless, I'll try the more matching to your issue 
> with a wire later.

Looks fine testing with a cable as well with your scenario.
Can you grab a new trunk build and test please?

Thanks

Roy