This is quite helpful to debug why a pattern didn't match.
As it could produce quite a lot of output if something is not found in a
log file, the complete output is only printed in verbose mode, otherwise,
`head` is used to print the first 10 lines of output.
We only get stdout from SSH, so the stderr redirection is only really
for errors ssh itself produces.
The client identifier serves as unique identifier just like a unique MAC
address would, so even with identity_leases disabled some DHCP servers
might assign unique leases per identity.
DHCP servers will respond to port 67 if giaddr is non-zero, which we set
if we are not broadcasting. While such messages are received fine via
RAW socket the kernel will respond with an ICMP port unreachable if no
socket is bound to that port. Instead of opening a dummy socket on port
67 just to avoid the ICMPs we can also just operate with a single
socket, bind it to port 67 and send our requests from that port.
Since SO_REUSEADDR behaves on Linux like SO_REUSEPORT does on other
systems we can bind that port even if a DHCP server is running on the
same host as the daemon (this might have to be adapted to make this work
on other systems, but due to the raw socket the plugin is not that portable
anyway).
The kernel creates such SAs to handle uncompressed small packets. They
are implicitly created and deleted with IPComp SAs. The problem is that
when we delete an IPComp SA only that state is deleted and removed from
the SA lists immediately, the IP-in-IP state is not removed until the IPComp
state is eventually destroyed. This could take a while if there are still
references to it around. So the IP-in-IP states will keep getting reported
by ip xfrm state until that happens (we also can't flush or explicitly delete
such kernel-created states).
In kernels before 4.14 this wasn't really a problem but since
ec30d78c14a8 ("xfrm: add xdst pcpu cache") the kernel seems to keep the
references to the last used SAs around a lot longer.
Also, usually a test scenario following an IPComp scenario will create
and use new SAs and thus the cached SAs will disappear before the kernel
state is checked again. However, if a following scenario uses different
hosts the states might remain, which caused some unrelated scenarios to
fail before adding this fix.
chroot will capture the user environment's PATH variable, which may be
wrong (e.g. not include /bin:/sbin, as it is on Arch). We should set a
known-working PATH variable in the chroot.
Andreas Steffen