dhcpcd-discuss

Hi Michael

For 9.1 the arp code was changed fairly significantly due to pledge and capsicum 
support. I've tested it fairly well, but there might be some breakage I guess.

On 02/06/2020 18:10, Michael Sweet wrote:
> Hi,
>
> I'm in the process of developing a Raspberry Pi-based solution using Yocto Zeus (3.0.3), dhcpcd (now at v9.1.0), and Avahi (0.8), which needs to pass Apple's Bonjour Conformance Test.  My primary goal is for this to work with a Raspberry Pi Zero Wireless, but I've also tested with a Pi 3b with the same results over both Ethernet and Wi-Fi.  I could easily update to the current Yocto Dunfell (3.1) if that will make a difference, but at this point I don't think it will...
>
> Anyways, I'm running dhcpcd with debug logging enabled and can't seem to get past the initial link-local tests.  dhcpcd correctly chooses a semi-random initial IPv4LL address and then (after BCT announces collisions) tries several other addresses before giving up and sticking with its original choice.  BCT naturally doesn't like this...

dhcpcd never gives up!
https://roy.marples.name/cgit/dhcpcd.git/tree/src/ipv4ll.c#n254
So once we hit MAX_CONFLICTS dhcpcd will try for a new address every 
RATE_LIMIT_INTERVAL seconds


> I've been digging through the source but am still coming up to speed to understand how dhcpcd decides to stop trying new IPv4LL addresses, and how this might be fixed (or if this is even the problem...)  I was also wondering why dhcpcd only chooses 169.254.x.0 addresses on my Pi - the code looks like it should have randomness in the entire lower 16 bits of the IPv4 address...

Hmmmmm, it should use the entire lower 16 bits of the address.
At least it does on litle endian machines. I'll try and test a BE machine later 
- but might take some time as it's an ERLITE router running NetBSD.

Relevant code here:
https://roy.marples.name/cgit/dhcpcd.git/tree/src/ipv4ll.c#n60

Roy