* IPv4: Ignore DHCP state when building routes
As this will change periodically.
We only care if the state (address) has been added.
Fixes#440 thanks to JognSmit.
Likewise, if we change from a reject to a non reject route
we need to remove it rather than changing it as some BSD
kernels preserve the RTF_GATEWAY flag.
* Protocols will notify when dhcpcd can exit
DHCPv6 RELEASE requires the addresses to be dropped before
a RELEASE message is sent.
We now wait for an acknowledgement or a timeout before notifying
that DHCPv6 has stopped for the interface.
DHCPv4 RELEASE is the other way around, there is no acknowledgement.
So we wait for 1 second after sending the message before removing
the address and notifying DHCP has stopped for the interface.
If we are not releasing then we notify dhcpcd that the protocol has
stopped right away when we drop the lease.
dhcpcd will exit once there are no running protocols for the
interfaces.
Fixes#513.
Hopefully #535, #519 and #509 as well.
Co-authored-by: Sime Zupanovic (EXT) <sime.zupanovic.ext@ericsson.com>
Finally have kqueue and epoll working for a multi-process
setup.
The secret sauce was that after forking the fd for polling
is invalid and as such should not be closed blindly.
If an interface stops, it might affect the routing priority.
When dhcpcd is exiting we want to avoid this behaviour to keep
the system running as best as.
privsep: enforce message boundaries with MSG_EOR on our messages
The nature of the SOCK_SEQPACKET, that privsep modules uses, is stream.
See:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_10_06
To guarantee that a reader will never read two messages in one read
operation, the writer shall put end of record markers.
The problem exposed itself in FreeBSD 15.0 that started to follow the
specification better than before.
Other SOCK_SEQPACKET usage considerations: a) as long as our reader
provides a receive buffer that would fit the largest message our writer
would ever send, we are good with regards to not a reading a partial
message b) as long as our writer always write full messages with one
write, we don't need use of MSG_WAITALL in reader.
Fixes#530
Co-authored-by: Roy Marples <roy@marples.name>
There is no ordering requirement from any RFC other than the
recommendations in RFC 7844.
But it seems some DHCP servers really want the message type as
the first option.
Fixes#522.
