Timeout just if not all infos got supplied

[Degoah]

Is there a possibility to configure dhcpcd in context of DHCPv6 in such a way, that it ONLY forks to the background as soon as all information dhcpcd were requested - based on the flags set in the RA message - to get from the DHCPv6 server are available?

Current behaviour:

1. dhcpcd receives a RA message with a valid prefix, RDNSS option, and the "O", "M" flag set.
2. dhcpcd forks to the background as soon as it bound an IPv6 address based on SLAAC.
3. Being in background dhcpcd solicits a lease.
4. If dhcpcd doesn't receive any lease from the DHCPv6 server in time, it doesn't time out - i.e. the timeout parameter has no effect as soon as a SLAAC-based IPv6 address has been configured and dhcpcd forked to background.

So, what I'm looking for is to make dhcpcd ONLY fork to the background, if it got not just the SLAAC-based IPv6 address, but also a DHCPv6 specific lease - if it is requested to solicit one based on the "O"/"M" flag(s) set in the RA message:

Requested behaviour
A) Lease arrives in time:

1. dhcpcd receives a RA message with a valid prefix, RDNSS option, and the "O", "M" flag set.
2. dhcpcd solicits a lease.
3. dhcpcd receive a lease from the DHCPv6 server before it timesout and forks now to the background.

B) Lease doesn't arrive in time:

1. dhcpcd receives a RA message with a valid prefix, RDNSS option, and the "O", "M" flag set.
2. dhcpcd solicits a lease.
3. dhcpcd doesn't receive any lease from the DHCPv6 server in time -> dhcpcd times out.

The options ipv6ra_fork from the dhcpcd.confg file isn't that one, which brings the requested behaviour.

Any ideas or any plans to make the requested behaviour a feature?

[rsmarples]

No plans for this no.
dhcpcd forks as soon as it has something useable in terms on an address and DNS.
If the address is in the RA or from DHCPv6 it doesn't matter.

Why are you behold to forking anyway? I mean, you could get a DHCPv6 address that lasts 30 seconds and then the DHCPv6 server goes away and the address expires. What's your expectation?

[Degoah]

The current behaviour of dhcpcd - forking already to the background as soon as it configured an IPv6 address based on SLAAC - isn't what I need completely. Instead, I'm checking - after dhcpcd forked to the background - whether or not the "M"/"O" bit where set in the RA message in order to know that dhcpcd is going to request information from the DHCP server. To know, that dhcpcd has received a valid lease, my app periodically executes "--dumplease" on dhcpcd and checks this way, whether the "reason=BOUND6, protocol=dhcp6" event got triggered. Calling periodically "--dumplease" is done as long as a specific maximum time has not been reached. After the maximum time has been reached and no "reason=BOUND6, protocol=dhcp6" event got triggered, my app proceeds by informing upper layer constructs that no DHCP server is available...

I wonder, If there is an alternative to this approach without using hook scripts...?!

[rsmarples]

If the upper layer needs to know about DHCP availability then hook scripts are the answer.
This means you are event driven rather than polling. If you poll quicker then the events come in then it's a waste of CPU cycles. If you poll slower then the events come in then you might be reacting later than ideal.

Why do you not want to use the hook scripts? They are there exactly for this purpose!

[Degoah]

Why do you not want to use the hook scripts? They are there exactly for this purpose!

I was not completely sure if this is the way to go, because I need to pass the data obtained by the hook script again somehow into my application. Therefore, I decided to dump the lease using the --dumplease option and read the stdout stream after the dhcpcd process forks into the background.

[rsmarples]

--dumplease only shows you the current leased data.

The hook scripts also have knowledge over the prior leased data as well so your application can tell what's changed without needing to remember anything. This is important for some users.

[Degoah]

I will reconsider the usage of the --dumplease from within my application and potentially switch over to the use of a hook script. Either way, I need to poll for changes - assuming that the latest DHCP-specific information get written by the hook script to a file, or make it event driven by using inotify to monitor filesystem events on that file and making my application afterwards parse that file. Many roads lead to Rome...