dhcpcd-discuss

On 17/07/2020 18:50, Davesh Patel wrote:
> Thanks Roy for your quick responses.
>
>  > If there is already a IPv4LL address and I use --reboot, I assume the process is
>  > still the same as above?
>
>  >> Yes, although it would use the already existing address.
>  >> At least the latest version does.
>
> Just to be sure: it uses the existing address for the IPv4LL but still sends a 
> DHCP discover?

Yes

> I have a requirement to send DHCP discover within <100ms of a trigger (e.g. link 
> up or other external trigger) but also need to start the IPv4LL in case there is 
> no DHCP server available. Will the --reboot set to 1s, send the discover 
> immediately or will it wait 1s (reboot seconds) before sending the discover?
>
> Can the reboot time be set to <1s (i.e. millisecond resolution). I think 
> not...so could you please point me to the point in the source code where I could 
> perhaps change this to allow <1s?
>
> Finally, similar to above, can ANNOUNCE_WAIT be configured to be <1s (or source 
> code easily changed to be <1s)?
>
> Essentially, I am tasked to make a link as quickly as possible.

The randomised delays exist so that 10000 computers all turning on at the same 
time don't overload the network or DHCP server.

That being said, because you're using IPv4LL (and thus requires ARP) which also 
requires Duplicate Address Detection you're looking at a worst case of 10 
seconds or so to get a working address from dhcpcd detecting carrier up.

If you turn all that off you generally get an address in a second or under.

Now, if you *really* want to be the special kid on the block and beat everyone 
else you could read the fine man page dhcpcd(8) and discover the nodelay option 
which turns off the initial randomised delay.

All other timers, such as ANNOUNCE_WAIT, are not user configurable unless you 
change the source code.

Roy