Thomas Haller [Fri, 14 Dec 2018 10:10:57 +0000 (11:10 +0100)]
dhcp: handle multiple addresses for "Router" (option 3) in DHCP library
The Router DHCP option may contain a list of one or more
routers ([1]). Extend the API of sd_dhcp_lease to return a
list instead of only the first.
Note that networkd still only uses the first router (if present).
Aside from extending the internal API of the DHCP client, there
is almost no change in behavior. The only visible difference in
behavior is that the "ROUTER" variable in the lease file is now a
list of addresses.
Note how RFC 2132 does not define certain IP addresses as invalid for the
router option. Still, previously sd_dhcp_lease_get_router() would never
return a "0.0.0.0" address. In fact, the previous API could not
differenciate whether no router option was present, whether it
was invalid, or whether its first router was "0.0.0.0". No longer let
the DHCP client library impose additional restrictions that are not
part of RFC. Instead, the caller should handle this. The patch does
that, and networkd only consideres the first router entry if it is not
"0.0.0.0".
Thomas Haller [Fri, 14 Dec 2018 23:45:46 +0000 (00:45 +0100)]
network: don't return allocated buffer of zero length from deserialize_in_addrs()
deserialize_in_addrs() allocates the buffer before trying to parse
the IP address. Since a parsing error is silently ignored, the returned
size might be zero. In such a case we shouldn't return any buffer.
Anyway, there was no leak, because there are only two callers like
r = deserialize_in_addrs(&lease->dns, dns);
which both keep the unused buffer and later release it.
Note that deserialize_in_addrs() doesn't free the pointer before
reassigning the new output. The caller must take care to to pass
"ret" with an allocated buffer that would be leaked when returning
the result.
Thomas Haller [Mon, 18 Feb 2019 06:28:02 +0000 (07:28 +0100)]
netlink: fix routing-policy-rule netlink type for FRA_GOTO/FRA_UNUSED2
- RTA_OIF has no business in the routing-rule policy. It is numerical
identical to FRA_GOTO. Fix using the correct enum value. Note that
RTA_OIF/FRA_GOTO was not used by networkd, and the type was already
correct at uint32. So, there is no change in behavior.
- RTA_GATEWAY also does not belong to the routing-rules. It is numerical
identical to FRA_UNUSED2. Obviously, that value is unused as well,
so there is no actual change in behavior either. In particular
that is because:
- kernel would not send messages with FRA_UNUSED2 attribute.
- networkd would not try to parse/send RTA_GATEWAY/FRA_UNUSED2
attributes.
basic/hexdecoct: be more careful in overflow check
CID #139583: plen + 1 is evaluated as int, and could in principle overflow.
So cast to ssize_t and add an additional check that our overflow calculation
doesn't overflow itself.
Fix section header for stable branches and backports. All the other
headings end in a colon and have no blank lines between them and the
body of the section, so fix this one accordingly.
Some tests will create a subtree of /sys under build/test/sys and
depending on the local system that tree might end up having an infinite
chain of symlinks. For example:
$ ls build/test/sys/devices/pnp0/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/
devices drivers drivers_autoprobe
Exuberant ctags will by default follow symlinks, so configure it not to
do so through a local .ctags file setting --links=no.
Tested that `ctags -R` doesn't get stuck with the dotfile present.
Linux can be run on a device meant to act as a USB peripheral. In order
for a machine to act as such a USB device it has to be equipped with
a UDC - USB Device Controller.
This patch adds a target reached when UDC becomes available. It can be used
for activating e.g. a service unit which composes a USB gadget with
configfs and activates it.
Fixes: #11422
Oneshots going to inactive directly without ever entering UNIT_ACTIVE is
considered success. This however means that if something both Requires=
and Requisites= a unit of such nature, the verify-active job getting
merged into the start job makes it lose this property of failing the
depending jobs, as there, the start job has the result JOB_DONE on
success, so we never walk over RequisiteOf units.
This change makes sure that such units always go down. It is also only
meaningful with After=, but so is Requisite= itself. Also, we also catch
cases like a oneshot having RemainAfterExit= true making us start up
properly in such a setting, but then removing it, reloading the unit,
and restarting it. In such a case, we go down due to restart propagation
before them, and our start job waits on theirs, properly failing with
the JOB_DEPENDENCY result.
This covers cases where ConditionXYZ= creates a similar situation as
well.
Michael Olbrich [Sun, 3 Feb 2019 09:52:02 +0000 (10:52 +0100)]
v4l_id: use device_caps if available
According to the specification[1] the 'capabilities' describe the physical
device as a whole and the 'device_caps' describe the current device node.
The existence of 'device_caps' is indicated by the V4L2_CAP_DEVICE_CAPS
capability flag.
Use the 'device_caps' if available to generate the correct
ID_V4L_CAPABILITIES for the current device node.
This is relevant for UVC devices with current kernels: Two /dev/videoX
devices exist for those. One for video and one for metadata. The
V4L2_CAP_VIDEO_CAPTURE flag is present in the 'capabilities' for both
device nodes but only in the 'device_caps' of the video device node.
Without this, the ID_V4L_CAPABILITIES of the metadata device node
incorrectly contains 'capture'.
o Any parameters specific to this client (as identified by
the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
or DHCPREQUEST message), e.g., as configured by the network
administrator,
It's not clear, whether only the first 'hlen' bytes of 'chaddr'
must correspond or all 16 bytes.
Note that https://tools.ietf.org/html/rfc4390#section-2.1 says for IPoIB
"chaddr" (client hardware address) field MUST be zeroed.
with having "hlen" zero. This indicates that at least in this case, the
bytes after "hlen" would matter.
As the DHCP client always sets the trailing bytes to zero, we would expect
that the server also replies as such and we could just compare all 16 bytes.
However, let's be liberal and accept any padding here.
This in practice only changes behavior for infiniband, where we
previously would enforce that the first ETH_ALEN bytes are zero.
That seems arbitrary for IPoIB. We should either check all bytes or
none of them. Let's do the latter and don't enforce RFC 4390 in this
regard.
Ignat Korchagin [Wed, 6 Feb 2019 19:51:28 +0000 (19:51 +0000)]
resolved: use Cloudflare public DNS server as a default fallback alongside Google one
Cloudflare public DNS service is currently the fastest one according to
https://www.dnsperf.com/#!dns-resolvers. Why not improve the experience for
systemd users using this as a default fallback nameserver?
This new setting allows configuration of CFS period on the CPU cgroup, instead
of using a hardcoded default of 100ms.
Tested:
- Legacy cgroup + Unified cgroup
- systemctl set-property
- systemctl show
- Confirmed that the cgroup settings (such as cpu.cfs_period_ns) were set
appropriately, including updating the CPU quota (cpu.cfs_quota_ns) when
CPUQuotaPeriodSec= is updated.
- Checked that clamping works properly when either period or (quota * period)
are below the resolution of 1ms, or if period is above the max of 1s.
Tom Yan [Wed, 9 Jan 2019 15:35:24 +0000 (23:35 +0800)]
mount/generators: do not make unit wanted by its device unit
As device units will be reloaded by systemd whenever the corresponding device generates a "changed" event, if the mount unit / cryptsetup service is wanted by its device unit, the former can be restarted by systemd unexpectedly after the user stopped them explicitly. It is not sensible at all and can be considered dangerous. Neither is the behaviour conventional (as `auto` in fstab should only affect behaviour on boot and `mount -a`) or ever documented at all (not even in systemd, see systemd.mount(5) and crypttab(5)).
sd-bus: if we receive an invalid dbus message, ignore and proceeed
dbus-daemon might have a slightly different idea of what a valid msg is
than us (for example regarding valid msg and field sizes). Let's hence
try to proceed if we can and thus drop messages rather than fail the
connection if we fail to validate a message.
Hopefully the differences in what is considered valid are not visible
for real-life usecases, but are specific to exploit attempts only.
Peter Hutterer [Fri, 8 Feb 2019 00:30:48 +0000 (10:30 +1000)]
sd-hwdb: fix matching for characters with an ord > 127
Devices like the "Microsoft Microsoft® 2.4GHz Transceiver v9.0 Mouse" contain
characters higher than 127. That ® is correctly stored in the hwdb and passed
into the search field during query, but the comparison fails.
Our search string is a const char *, trie_string() returns a const char * but
the current character is cast to uint8_t. This causes anything over 127 to
fail the match. Fix this, we're dealing with characters everywhere here after
all.
We should probably refer to them from other man pages
for programs which use them, since right now all refs are
in systemd-boot(7). But creating the section is a good step
anyway.
They is quite a bit of those directives and they were in "MISCELLANEOUS" because
they don't quite fit anywhere. When the OCI-compat stuff is merged, there'll
be even more, so let's make a separate section for them.
We had "SYSTEM MANAGER DIRECTIVES" which was a misnomer already, because
it also listed user manager stuff. Let's make this a more general section
and move the items for other services there too (from "MISCELANENOUS").
man: move os-release, machine-info, vconsole.conf vars to envvar section
Strictly speaking, those are not environment variables, but they are compatible
and people think about them like this. Moving them makes them easier to find.
projects / thirdparty / systemd.git / log
