dhcpcd-discuss

On Monday, October 27, 2014 10:05 AM, Roy Marples wrote:
> 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 :)

Yup, this latest trunk seems to be working better wrt this sequence.

BTW, a couple additional questions:

1. If an IPV4LL link is established (with 169.254.239.165) and then lost in favour of a valid DHCP lease (e.g., 192.168.1.1) and then this is lost (NOCARRIER) and then an IPV4LL link is re-established (CARRIER, but to a segment without a DHCP server) I see that the original LL address is re-used (i.e., 169.254.239.165). Is this correct? Shouldn't the new LL be a newly random LL?

2. During the NOCARRIER state (and before IPV4LL or BOUND is established) I see there is no IPv4 address for the interface (which is expected), however this is an IPv6 address that continues to be associated. Why is this?
E.g.,
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet6 fe80::20b:abff:fe36:1cfc  prefixlen 64  scopeid 0x20<link>
        ether 00:0b:ab:36:1c:fc  txqueuelen 1000  (Ethernet)
        RX packets 228540  bytes 21362755 (20.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 196  bytes 37719 (36.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xfd6c0000-fd6e0000

Thanks,
-David