dhcpcd-discuss

On 27/10/2014 17:02, David Hauck wrote:
> On Monday, October 27, 2014 3:54 AM, Roy Marples wrote:
>> 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?
> 
> Can I just download the previously tarball again?

Yes, that should work :)