Linux: use broadcast flag with ipvlan interfaces by default.
Linux ipvlan interfaces share a MAC address with their siblings and
parent physical interface. Before they are assigned an IP address,
these virtual interfaces do not receive DHCP OFFER unicast messages
because the ipvlan driver does not know to pass them to the virtual
interface yet by IP. This chicken-and-egg problem is resolved with
two changes:
In this patch, we set the broadcast flag for an interface if it
belongs to the ipvlan driver, as detected via SIOCETHTOOL ETHTOOL_GDRVINFO.
(closes #32)
A forthcoming patch will automatically modify the DHCP IAID for
ipvlan interfaces so that they do not conflict with the parent
(lower/physical) interface IAID. For now, dhcpcd will display a warning
log message when conflicting IAID (same MAC address) interfaces are active.
(A minor grammar correction is included free of charge.)
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.
Roy Marples [Sun, 27 Dec 2020 19:53:31 +0000 (19:53 +0000)]
hooks: add NOCARRIER_ROAMING reason
This is given when the OS supports the concept of wireless roaming
or the IP setup can be persisted when the carrier drops.
When this happens, routes are moved to a higher metric (if supported)
to support non preferred but non roaming routes.
The `interface_order` hook variable will now order the interfaces
according to priority and move roaming interfaces to the back of the
list.
If resolvconf is present then it is called with the -C option
to deprecate DNS and if carrier comes back it is called again with the
-c option to activate it once more.
As part of this change, default route metrics have been changed to
support a larger number of interfaces.
base metric 1000 (was 200)
wireless offset 2000 (was 100)
IPv4LL offset 1000000 (was 10000)
roaming offset 2000000
Roy Marples [Sat, 12 Dec 2020 13:12:26 +0000 (13:12 +0000)]
Linux: Support wireless IP roaming
This is achieved by checking that the interface is wireless,
IFF_UP and IFF_LOWER_UP are present, but IFF_RUNNING is missing.
This gives exactly the same support as modern NetBSD when carrier
loss is detected, but without the address verifications when the
carrier comes back as that needs to be handled in the kernel.
While IP setup is maintained, other configuration data is discarded.
Note that this should be improved in the future.
Thanks to Boris Krasnovskiy <borkra@gmail.com> for helping with this.