There is no excuse for clients to send connections to NetworkManager
that have invalid/unknown fields. Just reject them.
This is a dangerous change, because we might now reject connections
that we were accepting previously. Who know what clients were sending
and it used to work.
AddAndActivateConnection is allowed to provide an incomplete connection
that will be completed by NetworkManager. That is, a connection that
does not verify.
But we still want to catch invalid properties or unknown setting types.
Thus, we want to reject invalid partial connections.
This possibly rejects invalid requests from clients that were accepted
before. Thus this change has the potential to break misbehaving clients.
There is no excuse for clients to send connections to NetworkManager
that have invalid/unknown fields. Just reject them.
As Reapply() is new API in nm-1-1, there is no problem with backward
compatibility.
NM_UTILS_ERROR is our way to say, that we don't care about
the GError domain and code. nmcli sometimes passes domain "1"
and code "0" to g_set_error(), which could be considered
a bug.
We usually don't care about the error but only about the error
message, so let's have a universally available error quark around.
Don't try to realize our device when the parent device is not real.
Instead, enqueue the activation and wait until it is active before
realizing our device and progressing the device to DISCONNECTED so that
it can get connected.
If it's traversing from unavailable to disconnected (e.g. realizing
of the device was delayed because it was awaiting the parent connection),
then we just want to progress the activation.
We'll need to share the best conneciton logic and it's the only caller
of nm_device_get_available_connections(). Let's just move it all to
NMDevice and provide the best connection from there instead.
The root-test "/general/netns/bind-to-path" mounts a tmpfs
over /var/run for the duration of the test and unmounts it at
the end.
Due to a bug, we first mount the tmpfs, then switch to another
namespace, and finally unmount /var/run on that other namespace.
That means, when you run the tests as root, it will bork /run
on your system.
Fixes: 46f5c07643
If the user specifies an invalid 'dhcp' option in configuration,
currently we disable DHCP. Instead, fall back to other available
clients, as we do for other options.
The buffer was too small to contain _NMLOG_PREFIX_NAME and the pointer,
resulting in truncated messages like:
dns-mgr[0x561d1183d: set resolv-conf-mode: none
The _LOG*() macros based on _NMLOG() prefix each line with a
context. Since we no longer log the location of the logging line,
this is the more important.
When a pidfile exists, it is always stale after this point
and kill_existing() should always unlink it.
Also, refactor kill_existing() to use nm_utils_kill_process_sync()
which waits for the process to be gone.
Update systemd code from upstream. In the meantime, two
patches that we applied early in NetworkManager core were
applied in upstream systemd too. So, resync.
"NMSTATEDIR" is "nmstatedir" is "'${localstatedir}'/lib/$PACKAGE" is
usually "/var/lib/NetworkManager".
The "install-data-hook" in "src/Makefile.am" properly installs the
directory with permissions 700. When creating the directory at startup,
we must also use those permissions.
It does more than intended; apart from denying messages to that particular
interface it also denies all messages non-qualified with an
interface globally.
This blocks messages completely unrelated to wpa_supplicant, such as
NetworkManager communication with the VPN plugins.
From the dbus-daemon manual:
Be careful with send_interface/receive_interface, because the
interface field in messages is optional. In particular, do NOT
specify <deny send_interface="org.foo.Bar"/>! This will cause
no-interface messages to be blocked for all services, which is
almost certainly not what you intended. Always use rules of the form:
<deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
We can just safely remove those rules, since we're sufficiently protected
by the send_destination matches and method calls are disallowed by default
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=763880
No point ins storing "TRUE" as value in the @shared_ips hash
table. That forces glib to allocate a separate storage for the
value. Just use g_hash_table_add() instead.
The macro _LOGx_ENABLED() is defined with a default implementation
that depends on _NMLOG_DOMAIN. Although that default does not
check for LOGD_DHCP4 vs. LOGD_DHCP6, still provide it.
Determining the correct domain might involve a larger performance
impact that what we would safe.
The fields in the neighbor variant should have a defined order.
Instead of sorting the hash table entries while constructing the
variant in lldp_neighbor_to_variant(), refactor the management of
the TLV attributes.
As we only support known attributes, we can
store them in an array at a known index instead of putting them
in a hash table.
An alternative would be to have explict fields for every known
attribute. That would be even more efficient, but requires more
work when adding new attributes.
We register the callback early on, so we get notified about
every single neighbor as they show up. No need to iterate over
them explicitly -- and probably, at that early state, there are
no neighbors yet.
The systemd event tells which neighbor changed. Make use
of this information and don't rebuild all the neighbors
all the time.
That means, we must also change our rate limiting. Instead of
rate limiting the processing of all neighbors, we process neighbors
right away but limit the notification that gobject property changed.
When we receive an update for a certain neighbor, the update
might be invalid and we want to reject it. However, we still
must create an invalid object to compare whether the update
causes a remove of a previously valid neighbor.
Let lldp_neighbor_new() create an instance as long as the
id fields are present.
