Manually disconnecting a profile of course blocks autoconnect of the
same profile. Otherwise, the profile would likely re-activate right
away, which is clearly against the users intention. If the users just
want to re-activate the profile, they should issue `nmcli connection up`
instead, with does a full down and up cycle.
This is more interesting for profiles that have 'connection.multi-connect'
set to 'multiple'. Would you expect that manually deactivating such a
profile blocks autoconnect of the profile on all devices? Maybe
yes, maybe not. Currently that is indeed the case and autoconnect gets
blocked regardless of multi-connect.
In the past, the headers "linux/if.h" and "net/if.h" were incompatible.
That means, we can either include one or the other, but not both.
This is fixed in the meantime, however the issue still exists when
building against older kernel/glibc.
That means, including one of these headers from a header file
is problematic. In particular if it's a header like "nm-platform.h",
which itself is dragged in by many other headers.
Avoid that by not including these headers from "platform.h", but instead
from the source files where needed (or possibly from less popular header
files).
Currently there is no problem. However, this allows an unknowing user to
include <net/if.h> at the same time with "nm-platform.h", which is easy
to get wrong.
Previously we would compile source files from shared/nm-utils
multiple times. That not only slows down compilation, but it makes it
confusing which project require exactly what.
Most of the files in shared/nm-utils are a mixed bag of utility
functions. Just build one libnm-utils-base library. Since the linker
will throw away unused parts, there is no problem that not every user
of libnm-utils-base needs everything.
Also add libnm-utils-udev, which cannot be part of libnm-utils-base as
it has an additional dependency on libudev.
For one, it's not unreasonable that we want to run the same
tests both for gitlab and travis.
Move the actual tests into a script, which is called by both
CI environments.
We still can do something different, based on the environment.
The advantage here is, that the common part will be shared, and
the places where we differ can easily be spot.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/44
The ebpf syscall doesn't work on RHEL even if the linux/bpf.h header
is available: let's explicitly disable it.
On Fedora explicitly enable eBPF instead of autodetecting it.
This allows us to somehow work with no PCI (or USB for that matter), such
as some virtual machines. Old ModemManager doesn't like this though, but
there doesn't seem to be a way around it.
https://github.com/NetworkManager/NetworkManager/pull/246
We support all of these:
nmcli -v
nmcli -version
nmcli --version
Change the help output to display the first and last versions for
options, since they are the most common ones for command line tools.
While this is packaged in "NetworkManager-config-server.rpm"
sub-package, it's not in "00-server.conf" file. The reason
is that a convenient way to disable configuration from
"/usr/lib/NetworkManager/conf.d", is by putting a (possibly empty)
file into /etc directory with the same name. If the sub-package
only provides one large "00-server.conf" file, this is no longer
possible at a granular level.
The need for this is the following:
"ipv4.dhcp-client-id" can be specified via global connection defaults.
In absence of any configuration in NetworkManager, the default depends
on the DHCP client plugin. In case of "dhclient", the default further
depends on /etc/dhcp.
For "internal" plugin, we may very well want to change the default
client-id to "mac" by universally installing a configuration
snippet
[connection-use-mac-client-id]
ipv4.dhcp-client-id=mac
However, if we the user happens to enable "dhclient" plugin, this also
forces the client-id and overrules configuration from /etc/dhcp. The real
problem is, that dhclient can be configured via means outside of NetworkManager,
so our defaults shall not overwrite defaults from /etc/dhcp.
With the new device spec, we can avoid this issue:
[connection-dhcp-client-id]
match-device=except:dhcp-plugin:dhclient
ipv4.dhcp-client-id=mac
This will be part of the solution for rh#1640494. Note that merely
dropping a configuration snippet is not yet enough. More fixes for
DHCP will follow. Also, bug rh#1640494 may have alternative solutions
as well. The nice part of this new feature is that it is generally
useful for configuring connection defaults and not specifically for
the client-id issue.
Note that this match spec is per-device, although the plugin is selected
globally. That makes some sense, because in the future we may or may not
configure the DHCP plugin per-device or per address family.
https://bugzilla.redhat.com/show_bug.cgi?id=1640494
Often, during tests we want to assert against the logged messages.
In fact, most tests enable assertions for all logging and enforce
them with g_test_assert_expected_messages(). So, this is common.
However, sometimes it can be cumbersome to understand which logging
lines will be produced. For example, the next commits will call
nm_dhcp_manager_get() during the tests, which initializes NMDhcpManager
and logs a message which plugin was selected (or an additional warning,
if the selected plugin was not found). The availability of the DHCP plugin
depends on searching the path for "/usr/bin/dhclient", so from testing code
it's hard to determine what will be logged.
Instead, add a way to temporarily disable logging during testing.
Most singletons can only be instantiated once (unless NM_DEFINE_SINGLETON_ALLOW_MULTIPLE
is defined). Otherwise, an assertion will be triggered if the singleton is destroyed
and another instance is requested.
For testing, we want to create multiple singleton instances and being able to reset
the singleton getter. Add a function for that.
The entire point of using version 3/5 UUIDs is to generate
stable UUIDs based on a string. It's usually important that
we don't change the UUID generation algorithm later on.
Since we didn't have a version 5 implementation, we would always
resort to the MD5 based version 3. Version 5 is recommended by RFC 4122:
o Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; If
backward compatibility is not an issue, SHA-1 is preferred.
Add a version 5 implementation so we can use it in the future.
All test values are generated with python's uuid module or OSSP uuid.
We link against libuuid.so, but it was entirely internal to
libnm-core. We only exposed UUIDs in string form.
Add API to also handle UUIDs in binary form.
Note that libuuid already defines a type "uuid_t". However,
don't use it and instead use our own typedef NMUuid.
Reasons:
- uuid.h should be internal to libnm-core (nm-utils.c specifically),
and not be used by or exposed it other parts of the code.
- uuid_t is a typedef for a guchar[16] array. Typedefs
for arrays are confusing, because depending on whether
it's an automatic variable or a pointer in a function argument,
they behave differently regarding whether to take their address
or not and usage of "sizeof()".
Backport a series of upstream patches from systemd, related
to out-of-bounds heap write with DHCPv6.
On master, we anyway will do a full re-import of systemd code.
Cherry-pick individual patches first, to make backporting easier.
CVE-2018-15688
This doesn't change anything in the generated source, but I think makes
semantically more sense, as these structures have undefined size, and we
only want to know the size up to the data field in these cases.
(cherry picked from commit 20b55f853847378b85561a4e299604d27b5cd25b)
