There is an error sending a reply from an INET6 sysctl RT dump
on FreeBSD-14 using the dhcpcd-9 branch.
It seems to be related to capsicum and doesn't happen on FreeBSD-13.
We should handle the error gracefully and allow dhcpcd to try to
contuinue regardless.
Detecting host routes based on address comparison is not needed in
classless routes as /32 mask can be explicitly used. This detecting
mechanism did cause issues when gateway was set to 0.0.0.0 (link local
routes).
Some network devices can send probes where the source address in the frame
does not match the sender in the ARP request, due to firmware bugs or
crafted packets.
Without verification this can cause to fail the defense, so we lose the
address, then request a new one. This might lead to the DHCP address pool
being exhausted and all sorts of problems like frequent IP changes.
A real life example is that some Cisco devices can send ARP probes in bursts,
where the frame's source address is clearly invalid, so hosts running dhcpcd
release addresses frequently, e.g., Raspberry Pis.
Example output:
"invalid ARP probe, sender hw address mismatch (00:be:75:xx:xx:xx, 00:00:00:yy:yy:yy)"
RFC5227, Section 1.1 describes that the two addresses must match in case
of ARP probes, so add the extra check and log a warning if we receive an
invalid packet like that.
Signed-off-by: Laszlo Toth <laszlth@gmail.com>
Each process should now cleanly wait for child processes to exit.
They should only exit when no children left.
There is still no way to cleanly log the privilged process exiting
as well as the manager process as the manager needs the
privilged process to log.
Now, at least, dhcpcd should alway say it's exited.
As well as removing not enabled code to wait a bit before
removing the IP address when sending a DHCP RELEASE message.
This means that we no longer need to allow nanosleep in SECCOMP.
Hopefully fixes#127.
We could rebind a lease, get a NAK and enter DISCOVER.
We need to restart the BPF in the middle as the BPF filter could
change.
As such, add a started flag to each privsep process and when
searching for a process by id only find started ones.
If we ask them to stop then the started flag is removed.
Fixes errors about writing to stopping processes an unknown
processes exiting.
Rather than opening / closing on demand.
This mirrors the behaviour of dhcpcd without privsep and ensures
that dhcpcd always has the resource available to do it's operations
to ensure the network stays up.
This also has the advantage of working around a recent FreeBSD-14
capsicum issue where opening a route socket in the privileged
process without capsicum fails with the same error as if it was
in capsicum.
See RFC 8415 21.4, 21.6, 21.21 and 21.22.
As such it's impossible to request a lease time as such and we
MUST use the vltimes and pltimes sent by the server.
This addresses the concern in #116 but does fix it as it's not a dhcpcd
problem.
1. If the received Valid Lifetime is greater than 2 hours or
greater than RemainingLifetime, set the valid lifetime of the
corresponding address to the advertised Valid Lifetime.
2. If RemainingLifetime is less than or equal to 2 hours, ignore
the Prefix Information option with regards to the valid
lifetime.
3. Otherwise, reset the valid lifetime of the corresponding
address to 2 hours.
dhcpcd-run-hooks is intended to skip hooks with filenames ending in `~`,
but the test only works if `$skip_hooks` is defined and not empty.
Refactor the test such that files ending in `~` are always skipped, as
appears to be the intent of this code.
