Roy Marples [Tue, 3 May 2022 06:09:34 +0000 (07:09 +0100)]
IPv6: Resolicit a router just before it expires naturally
It seems that some routers don't send out periodic advertisements
as they should. To work around this, re-solicit a router just before
it's about to expire.
Ben Woods [Sat, 13 Nov 2021 13:53:58 +0000 (21:53 +0800)]
Add epair(4) to the ignored interface types list (#73)
The FreeBSD epair(4) interface type can be thought of as a virtual patch cable.
The epair interfaces come in pairs, with network traffic being passed between the 2 pairs.
The basic intent is to provide connectivity between two virtual network stack instances.
This interface type does not typically require an IP address, as it is passing traffic
between other virtual networks/interfaces which obtain their own IP address.
Therefore, add this interface type to the list that will be ignored by dhcpcd.
Roy Marples [Fri, 12 Nov 2021 14:24:11 +0000 (14:24 +0000)]
privsep: Only set RLIMIT_NOFILES for supported platforms
Basically only for NetBSD, DragonFlyBSD, kqueue or epoll platforms.
All others will use poll(2) and return EINVAL if nfds > RLIMIT_NOFILES.
Trying to work out our nfs limit relies on already listening to
all FD's which may not be the case and was problematic.
Luckily all platforms aside from Solaris have new file creation
sandboxed away aside from accept(2) so this should still be safe.
Roy Marples [Thu, 14 Oct 2021 05:31:11 +0000 (06:31 +0100)]
DHCP: Set INFORM state only when we are about to inform
As we may not find an address right away.
While here, tidy up and comment code about deriving the address
when none is specified for inform and static setups.
Philip Paeps [Tue, 12 Oct 2021 08:07:28 +0000 (16:07 +0800)]
privsep: Fix getting interface VLANID on BSD (#58)
Include relevant headers for the definition of SIOCGETVLAN. This fixes
DHCPv6 Prefix Delegation where a prefix is delegated to several VLAN
interfaces on the same physical interface.
Roy Marples [Fri, 1 Oct 2021 15:25:53 +0000 (16:25 +0100)]
DHCP6: Don't spam the log when a RA repeatedly triggers an INFORM
This can occur if the RA reduces the prefix times in accordance
with it's own lifetimes for example.
dhcpcd only checks if the RA contents have changed to trigger a
new INFORM.
Stefan Sperling [Tue, 31 Aug 2021 09:31:15 +0000 (11:31 +0200)]
Fix rt_cmp_dest() for equivalent network prefixes with different netmasks. (#52)
When rt_add() decides that it must delete+add a route in order to change
the routing table entry, a wrong RB tree lookup result can throw it off
the rails. In the case observed, a static /64 prefix was deleted from
vlan1 while dhcpcd intended to delete its reject route bound to lo0.
Given two routes in the table, the loopback reject route installed by
dhcpd for my /48 prefix, and a cloning route for a /64 prefix on vlan1:
When searching the OS routing table dhcpcd attempts to tell routes apart
based only on the masked destination address. In the above case the masked
destinations look identical. The only difference is the length of the netmask.
The function rt_cmp_dest() didn't detect this and returned the /64 route
while dhcpcd was in fact searching for the /48 route.
This patch fixes the lookup by running rt_cmp_netmask() if the masked
destination comparison via sa_cmp() leaves us with a tie. With this change
dhcpcd deletes the /48 route as intended, and leaves the /64 route alone.
I had to move the rt_cmp_dest() function down since it needs to use the
static helper function rt_cmp_netmask(), which happened to be defined
just below rt_cmp_dest().
Why am I using an overlapping static prefix? The answer is that my ISP
assigns a static /48 prefix but won't route IPv6 unless my router sends
a DHCPv6 request when it connects via PPPoE. I configure static IPv6 subnets
on LAN interfaces and have configured dhcpcd to obtain a /48 prefix lease
without setting addresses on any internal interfaces.
My dhcpcd.conf contains:
ipv6only
noipv6rs
duid
persistent
option rapid_commit
require dhcp_server_identifier
script ""
allowinterfaces pppoe0
interface pppoe0
ia_pd 1 /2001:db8::/48
This problem was found on OpenBSD, in case that matters for reproduction
of the issue.
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
Roy Marples [Tue, 16 Feb 2021 16:43:18 +0000 (16:43 +0000)]
eloop: delete events from kqueue/epoll directly
Rather than relying on close(2) being called.
Whilst a bit less performant with many open/close, there is also
no guarantee that close(2) will actually be called as
shutdown(2) could be used instead.
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_{ARCOMPACT,ARCV2} is only defined
since kernel 5.2 and
https://github.com/torvalds/linux/commit/67f2a8a29311841ba6ab9b0e2d1b8f1e9978cd84
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
privsep-linux.c:203: warning: "AUDIT_ARCH_SPARC64" redefined
203 | # define AUDIT_ARCH_SPARC64
|
In file included from privsep-linux.c:35:
/srv/storage/autobuild/run/instance-0/output-1/host/sparc64-buildroot-linux-gnu/sysroot/usr/include/linux/audit.h:392: note: this is the location of the previous definition
392 | #define AUDIT_ARCH_SPARC64 (EM_SPARCV9|__AUDIT_ARCH_64BIT)
|
In file included from privsep-linux.c:36:
privsep-linux.c:215:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
215 | BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
| ^~~~~~~~~~~~~~~~~~
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_{SH,SHEL,SH64,SHEL64} are defined at
least since kernel 3.7 and
https://github.com/torvalds/linux/commit/607ca46e97a1b6594b29647d98a32d545c24bdff
Roy Marples [Tue, 2 Feb 2021 14:41:54 +0000 (14:41 +0000)]
eloop: Make the API more like native poll/kqueue/epoll
Just have the one callback, but return an abstracted event mask
to work out if we can read/write have something else.
Log diagnostics if the event mask is unexpected.
While here add more logging if we fail to register an event to
monitor.
Roy Marples [Sun, 31 Jan 2021 21:07:43 +0000 (21:07 +0000)]
Linux: allow pselect(2) to work in SECCOMP
The default is ppoll(2), but we still allow epoll(7) so
allowing pselect(2) makes perfect sense and allows the user
to pick the polling mechanism they want.
Fabrice Fontaine [Sun, 31 Jan 2021 20:57:40 +0000 (21:57 +0100)]
src/privsep-linux.c: add support for microblaze (#24)
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_MICROBLAZE is only defined since
kernel 3.18 and
https://github.com/torvalds/linux/commit/ce5d112827e5c2e9864323d0efd7ec2a62c6dce0
Fabrice Fontaine [Sun, 31 Jan 2021 10:12:21 +0000 (11:12 +0100)]
src/privsep-linux.c: add support for nios2 (#23)
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
Fabrice Fontaine [Sun, 31 Jan 2021 02:35:10 +0000 (03:35 +0100)]
src/privsep-linux.c: add support for xtensa (#22)
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
It should be noted that AUDIT_ARCH_XTENSA is only defined since kernel
5.0 and
https://github.com/torvalds/linux/commit/98c3115a4ec56f03056efd9295e0fcb4c5c57a85
Fabrice Fontaine [Sat, 30 Jan 2021 11:10:08 +0000 (12:10 +0100)]
src/privsep-linux.c: add support for nds32 (#21)
Fix the following build failure:
privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet"
# error "Platform does not support seccomp filter yet"
^~~~~
In file included from privsep-linux.c:36:
privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'?
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
^~~~~~~~~~~~~~~~~~
Roy Marples [Sat, 30 Jan 2021 11:04:53 +0000 (11:04 +0000)]
eloop: optimise the pselect code so it's not a wrapper for ppoll
This makes the code smaller yet and also use less memory then ppoll!
Still, the API blows chunks and we still have arbitary fd limits
which we'll realistically never hit.
Also, some BSD's note potential issues with select on the same fd
across processes so ppoll is still the winner.
Roy Marples [Sat, 30 Jan 2021 01:37:15 +0000 (01:37 +0000)]
eloop: Default to using ppoll(2) again.
Even though we now have fully working kqueue(2) and epoll(7)
with our privsep code, ppoll(2) is faster and smaller for our
workload.
This time though, we will keep the code here as it's fully working
and while fixing kqueue we also fixed other bugs in dhcpcd as a result
so it's not time wasted at all.
Roy Marples [Thu, 28 Jan 2021 11:54:05 +0000 (11:54 +0000)]
BSD: Implement kqueue(2) for eloop (again)
kqueue allows for O(1) processing of active fd's an a more
robust signal handling method without the need to use global
variables to avoid calling functions during signal delivery.
The problems with the prior implemenation have now been fixed.
Roy Marples [Sun, 24 Jan 2021 22:22:25 +0000 (22:22 +0000)]
eloop: Allow eloop to process all fds returned from poll(2)
We do this by ensuring the events list or pollfd struct storage
is not modified during the revent processing.
An event with a fd of -1 means it's been deleted and one without
a pollfd struct reference has been newly added.
This also allows us to count down the number of fd's that
returned a revent so we can break the loop early if possible.
This is a really minor optimisation that at best only applies if
more than one revent is returned via poll(2).
In the case on dhcpcd on NetBSD with privsep, the number of
fd's is really low. And on other platforms or without privsep it's
low also (just not as low).
It's only when you run dhcpcd per interface that the number
of fd's starts to creep upwards as you then need one per address
dhcpcd is monitoring (as well as the ARP listener per IPv4 address
for non NetBSD).
However, I use eloop in other code where this could be a good saving
and dhcpcd is where the master version of this lives!
Roy Marples [Sun, 27 Dec 2020 22:31:02 +0000 (22:31 +0000)]
20-resolv.conf: Don't call resolvconf -c if we didn't call -C
This solves the warnings on all OS other than Linux who don't have
a supporting resolvconf for deprecating DNS because they never
emit the NOCARRIER_ROAMING reason.