We can only allow possible match if all the differences are exceptions.
Before, we accepted the connection if an exception was found, but it is wrong
because there may be another difference (that is fatal).
When assuming the connections on restart we want to prefer more-recently-used
connections. That's why we have to sort connections according to timestamps in
descending order. That means connections used more recently (higher timestamp)
go before connections with lower timestamp.
https://bugzilla.redhat.com/show_bug.cgi?id=1067712
Asserting against "/.." is wrong, because one could rename a link to
"..em1", which is a valid ifname but would crash NetworkManager.
Signed-off-by: Thomas Haller <thaller@redhat.com>
No need to allocate a dynamic buffer in most of the cases.
And extended test cases to test with/without white space
and leading zeros.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Instead of waiting until the device is disposed and dbus-glib does
it for us, remove them when the Manager is done with them. If
something (like pending D-Bus calls) holds a reference to the device
when the Manager removes it, the device would previously still
service method calls until all references are released. When
the device is removed, it's dead, and it shouldn't be exported
anymore.
Rebasing the shvar changes to master added some new instances of
svNewFile() and svWriteFile() (in the aliases code) that needed to be
updated for the API changes.
shvar.c was assuming it could do a single read() to read in the ifcfg
file, without taking partial reads or EINTR into account. Fix that.
Also, it was keeping the raw contents of the ifcfg file in the
shvarFile even though it never looked at it after svOpenFile().
(Presumably lineList originally consisted of pointers into arena, but
that had to be changed to support readwrite.) Fix that.
It would simplify things further to use g_file_get_contents() and
g_file_set_contents(), but the current code is perhaps more resilient
to symlink attacks because it keeps the fd open?
activate_data_free() deletes the data from priv->pending_activation_checks,
thus iterating over the list with g_slist_free_full() causes a double
free or invalid memory access.
This bug does not hit easily, because the policy only get's disposed
when NM shuts down and then there are likely no pending activations
queued.
Fixes regression introduced by commit 4f0c70e945.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Instead of having separate booleans for each unmanaged option, make them
a single flags variable instead. Also split out user-unmanaged from
internal management like suspend/resume so we can control them separately.
We'll want to track internal management separately in the future, so split out
user management (eg, whether the device has been explicitly marked unmanaged
by the user).
Instead of tracking unmanaged-ness in a couple variables (and because
I'd like to add one for user-unmanaged later) let's do it in a single
flags variable, and consolidate setting of the unmanaged states in one
place.
The function toStdString() is only available when QT was
compiled with STL support. The configure script does
not check STL support and might build the QT examples
even if toStdString() is not available.
Fix this, by not using the function.
This fixes the previous commit f73e3669b3
that I pushed accidentally.
https://bugzilla.gnome.org/show_bug.cgi?id=727608
Signed-off-by: Thomas Haller <thaller@redhat.com>
Extended address flags are represented by the additional netlink
attribute IFA_FLAGS. Older kernels don't know this flag and refuse
the messages RTM_NEWADDR and RTMDEL_ADDR when it contains unknown
attributes. See net/core/rtnetlink.c, rtnetlink_rcv_msg(). This was
fixed by kernel commit 661d2967b3f1b34eeaa7e212e7b9bbe8ee072b59.
libnl was fixed in commit 5206c050504f8676a24854519b9c351470fb7cc6 only to
send the additional netlink attribute, when there are actually flags
that make this necessary.
This commit changes nm-platform to strip the flags to &= 0xFF, if we detect
that the kernel does not understand extended address flags.
https://bugzilla.redhat.com/show_bug.cgi?id=1063885
Signed-off-by: Thomas Haller <thaller@redhat.com>
The function toStdString() is only available when QT was
compiled with STL support. The configure script does
not check STL support and might build the QT examples
even if toStdString() is not available.
Fix this, by not using the function.
https://bugzilla.gnome.org/show_bug.cgi?id=727608
Signed-off-by: Thomas Haller <thaller@redhat.com>
Returns the length of a string at compile time. Contrary to strlen(),
which is a run time expression -- even if the compler might be able to
optimize strlen() for string constants.
Signed-off-by: Thomas Haller <thaller@redhat.com>
lldpad 0.9.46 and earlier appear to be very sensitive to carrier, and if the
interface has no carrier will refuse to do anything with it, reporting that
"Device not found, link down or DCB not enabled". So while setting up and
tearing down DCB configuration, we must wait for the carrier at various
points before proceeding, to ensure that the operations are successful.
Non-git-master versions of lldpad refuse to touch a device that doesn't
have a carrier. And when enabling/disabling DCB, the kernel driver will
reconfigure itself and may turn carrier off for a few seconds. So we
must ensure that before enabling/disabling DCB, the carrier is already
on. Next we must ensure that *after* enabling/disabling DCB, the
carrier is back on before doing further DCB setup.
There's a race condition between enabling/disabling DCB and receiving
the carrier event in NetworkManager that has to be handled carefully.
Because the carrier may not yet be down after the dcbtool call to
enable/disable DCB returns, we need to wait for a couple seconds for
the carrier to go down, and then again for it to come back up.
Otherwise we might see the still-on carrier, proceed with DCB setup,
and the carrier finally goes down halfway through the setup, which
will fail the operations with "DCB not enabled, link down, or DCB
not supported" errors from lldpad.
Even ignore-carrier devices need to be aware of carrier-up events so
they can continue DHCP when the link comes up. They just ignore all
carrier-down events.
Fix a bug when reading an invalid alias file, where the code meant to
skip the rest of the loop iteration, but failed.
Also fix a memory leak and remove an unused variable.
Bugs noticed by coverity.
