Re: dhcpcd 7.0.8 - Device did not check if it's original address was in use before probing for a new address
Stefano Cappa
Wed Jan 16 20:48:58 2019
Tested and it worked perfectly. Thank u.
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
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
eth0: deleting IP address 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 broadcast 169.254.255.255
eth0: changing route to 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.
thank u,
Stefano
Il giorno mer 16 gen 2019 alle ore 18:41 Roy Marples <roy@xxxxxxxxxxxx> ha
scritto:
> On 14/01/2019 11:23, Roy Marples wrote:
> > dhcpcd treats the link down/up event as a reboot, thus seeds the random
> > number from the hardware address.
> > This can be changed, will work on it.
>
> Attached is a patch to address this.
> I've tested it on Arch Linux and NetBSD.
> Will test on others before comitting.
>
> If you can test it to ensure dhcpcd now passes the conformance test, I'd
> appreciate it.
>
> Roy
>
Archive administrator: postmaster@marples.name