| Age | Commit message (Collapse) | Author |
|---|
|
To mirror the recent name change of the concept for sd_bus objects,
follow the same logic for sd_event_source objects, too.
|
|
Add path of MTU disovery for IPIP and GRE Kind of tunnels
|
|
|
|
address class
In case of a class E or F address, ignore the address.
|
|
|
|
Like Infiniband. See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
|
|
systemctl would print 'CPUQuotaPerSecUSec=(null)' for no limit. This
does not look right.
Since USEC_INFINITY is one of the valid values, format_timespan()
could return NULL, and we should wrap every use of it in strna() or
similar. But most callers didn't do that, and it seems more robust to
return a string ("infinity") that makes sense most of the time, even
if in some places the result will not be grammatically correct.
|
|
Found by coverity. CID #1237529 and #1237528.
|
|
sd_bus_message_get_errno can currently return either a number of
different poitive errno values (from bus-error-mapping), or a negative
EINVAL if passed null as parameter.
The check for null parameter was introduced in 40ca29a1370379d43e44c0ed425eecc7218dcbca
at the same as the function was renamed from bus_message_to_errno and
made public API. Before becoming public the function used to return
only negative values.
It is weird to have a function return both positive and negative errno
and it generally looks like a mistake. The function is guarded by the
--enable-kdbus flags so I wonder if we still have time to fix it up?
It does not have any documentation yet. However, except for a few details
it is just a convenient way to call sd_bus_error_get_errno which is documented
to return only positive errno.
This patch makes it return only positive errno and fixes up the two
calls to the function that tried to cope with both positive and negative
values.
|
|
It is redundant to store 'hash' and 'compare' function pointers in
struct Hashmap separately. The functions always comprise a pair.
Store a single pointer to struct hash_ops instead.
systemd keeps hundreds of hashmaps, so this saves a little bit of
memory.
|
|
187fe1db took advantage of floating events, but didn't remove pointers
it made superfluous.
|
|
This lets the routing metric for links to be specified per-network,
still defaulting to DHCP_ROUTE_METRIC (1024) if unspecified. Hopefully
this helps with multiple interfaces configured via DHCP.
|
|
|
|
|
|
|
|
This makes DHCPv4 and IPv4LL coexist peacefully.
[tomegun: apply to both the dhcp routes, use in_addr_is_null() rather than a
separate variable to indicate when prefsrc should be applied]
|
|
netdev
|
|
|
|
|
|
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=83134.
|
|
Don't wait for the link to be fully synchronised.
|
|
link_update()
This allows us also to simplify link_has_carrier() a bit.
|
|
|
|
This should help in debugging failing event sources.
|
|
|
|
|
|
|
|
operstate
https://bugs.freedesktop.org/show_bug.cgi?id=81287
|
|
As the comment says, the passed in callback must always be invoked, or the underlying link
will hang. This was missed when reworking the code, so add it back in.
|
|
We are only guaranteed to stay in ENSLAVING state whilst enslaving by bridges/bonds, not
when adding stacked devices (as then the underlying device can be IFF_UP'ed and configured
in parallel), so drop these asserts.
|
|
Elements must be removed from the hashtable before they are freed.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=82721
|
|
The interface for creating tuntap devices should be ported to rtnl so it would support the same settings
as other kinds. In the meantime, the best one can do is to drop in a .link file to set the desired options.
|
|
Unlikely to happen but still...
|
|
|
|
|
|
|
|
|
|
ones later
This is primarily important for the domains list, as we really should
prefer the locally configured domain over the dhcp supplied ones when we
use it as a search list.
|
|
Also, simplify things a bit and make sure we don't forget looking at one
of the entries.
|
|
|
|
|
|
This allows the search/routing domanis to be specified per link/network and be passed
on to resolved.
|
|
makes ethernet addresses look funny
|
|
'ieee80211_radiotap'
|
|
This option will also apply to the search domains, so make it plural.
|
|
|
|
Most routers will send garbage, so make this opt-in only.
|
|
For now this only exposes the domain name (DHCP Option 15), and not
the search string (DHCP Option 119), which will be implemented in
a follow-up patch.
|
