dhcpcd-discuss

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?
 
> Thanks
> 
> Roy
>