dhcpcd-discuss

I applied both patches and its working. very good.

PS about subsequent conflicts I created a report with wireshark. I hope its
enough, otherwise I'll create a report from the beginning of the test and
not only subsequent conflicts.

Il giorno gio 17 gen 2019 alle ore 13:01 Roy Marples <roy@xxxxxxxxxxxx> ha
scritto:

> 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
>

Attachment: subsequentconflicts.pcapng
Description: Binary data