dhcpcd-discuss

On 16/01/2019 20:48, Stefano Cappa wrote:
> Tested and it worked perfectly. Thank u.
Awesome, fixed here:
https://roy.marples.name/git/dhcpcd.git/commit/?id=28a9b91a3667af48a45ff0cf91d4aed0cc9daf85
https://roy.marples.name/git/dhcpcd.git/commit/?id=57d586821dd9ffcccce8adb3b6302eaf5efd70e6

I made one subsequent change to reset the address if the assoicated SSID 
changes from the last one.

> This was the biggest problem but there is another issue in Link Local test.
> Not a real error, but a warning that Apple asks to investigate while 
> certificating a Bonjour device.
>
> All ipv4 linklocal tests are ok, except for the one called SUBSEQUENT 
> CONFLICTS.
> The explanation of this test is: _"The test tool will wait ten seconds, 
> and then issue two ARP replies, six seconds apart, for the address the 
> device is using.  The test tool verifies that the device then picks a 
> new address and probes/announces again.  If the device does not wait for 
> the second ARP reply before choosing a new address, instead probing 
> immediately after the first conflict, a warning is generated."_
>
> The Bonjour test log is:
> NOTICE  19:58:41.628909: Starting test: SUBSEQUENT CONFLICTS
> NOTICE  19:58:51.635203: Sending ARP reply to device for address 
> 169.254.118.180
> *WARNING 19:58:51.646603: Source address non-zero 169.254.118.180*
> *WARNING 19:58:51.646669: The host is attempting to defend its IP - 
> sending the second denial*
> *WARNING 19:58:52.757124: NOTE: Device did not wait for second conflict 
> probe before selecting a new address.*
> NOTICE  19:58:54.563253: Received probe from            169.254.224.168
> NOTICE  19:58:55.974735: Received probe from            169.254.224.168
> NOTICE  19:58:57.987509: Received announcement from     169.254.224.168
> PASSED (SUBSEQUENT CONFLICTS)
>
> Instead dhcpcd log is:
> (...)
> eth0: ARP announcing 169.254.118.180 (2 of 2)
> eth0: hardware address 00:e0:4c:36:00:13 claims 169.254.118.180
> eth0: defended IPv4LL address 169.254.118.180/16 <http://169.254.118.180/16>
> eth0: hardware address 00:e0:4c:36:00:13 claims 169.254.118.180
> eth0: IPv4LL 10 second defence failed for 169.254.118.180/16 
> <http://169.254.118.180/16>
> eth0: deleting IP address 169.254.118.180/16 <http://169.254.118.180/16>
> eth0: executing `/usr/libexec/dhcpcd-run-hooks' IPV4LL
> eth0: probing for 169.254.224.168
> eth0: ARP probing 169.254.224.168 (1 of 3), next in 1.3 seconds
> eth0: ARP probing 169.254.224.168 (2 of 3), next in 1.9 seconds
> eth0: ARP probing 169.254.224.168 (3 of 3), next in 2.0 seconds
> eth0: using IPv4LL address 169.254.224.168
> eth0: adding IP address 169.254.224.168/16 <http://169.254.224.168/16> 
> broadcast 169.254.255.255
> eth0: changing route to 169.254.0.0/16 <http://169.254.0.0/16>
> eth0: changing default route
> eth0: ARP announcing 169.254.224.168 (1 of 2), next in 2.0 seconds
> eth0: executing `/usr/libexec/dhcpcd-run-hooks' IPV4LL
> eth0: ARP announcing 169.254.224.168 (2 of 2)
>
> As you can see this is not a real error, but Apple asks what you are 
> doing to fix this in the future. So they tolerate this warning, but only 
> if you are working to try to fix it in next firmware releases.
>
> What do you think? Is it something related to dhcpd? Is it possible to 
> fix it?
>
> PS: I'm sorry for mixing two topics is a single discussion.

I'm not sure this is a dhcpcd bug - notice that dhcpcd received TWO arp 
replies for the address within 10 seconds.
Can you run a wireshark trace along side to verify that the kernel sees 
two arp replies as well please, to ensure that dhcpcd isn't doubling up.

Also, check the timestamp of the bonjour test, the warning is logged a 
substiancial ammount of millseconds after the second probe was sent 
which wells me the test tool is waiting and may have a bug.

Roy