crypto_verify_private_key_data() must try to decrypt the key only when
a password is supplied.
Previously the decrypt test always passed because we detected an
unsupported cipher and faked success. Now since version 3.5.4 gnutls
supports PBES1-DES-CBC-MD5 and the key is actually decrypted when a
password is supplied.
Also, don't assert that a wrong password works because we're now able
to actually verify it (only with recent gnutls).
https://bugzilla.gnome.org/show_bug.cgi?id=771623
(cherry picked from commit 0e96d23733)
When comparing the bond-settings of an activated device against
the settings from the connection, some properties might easily
differ. Hack them around in NMSettingBond:compare_property().
For example:
the setting in the connection has:
[bond]
mode=active-backup
later, the device gets:
[bond]
active_slave=inf_ib0
fail_over_mac=active
mode=active-backup
Note that the fail_over_mac changes due to:
kernel: nm-bond: enslaved VLAN challenged slave inf_ib0. Adding VLANs will be blocked as long as inf_ib0 is part of bond nm-bond
kernel: nm-bond: The slave device specified does not support setting the MAC address
kernel: nm-bond: Setting fail_over_mac to active for active-backup mode
https://bugzilla.redhat.com/show_bug.cgi?id=1375558
(cherry picked from commit 0fb723e720)
The 'device-added' and 'device-removed' signals indicate when the
value of the 'Devices' property changes. The property only returns
realized devices and so if a device unrealizes we should emit the
removed signal for it.
Fixes: 5da37a129chttps://bugzilla.gnome.org/show_bug.cgi?id=771324
(cherry picked from commit cdedd2b53e)
priv->path is NULL when the agent handles all requests (for example
when executing "nmcli agent").
Fixes: f3099db28e
(cherry picked from commit 2a391348b6)
Since we use g_str_has_prefix() to match a request_id with the
connection path, there can be wrong matches. For example:
request_id: /org/freedesktop/NetworkManager/Settings/10/802-1x
connection: /org/freedesktop/NetworkManager/Settings/1
would match. Add a trailing slash to the connection path stored in the
agent to prevent this.
(cherry picked from commit f666efed0d)
We want to embed the current commit-id in the ./configure script.
That way the generated ./configure file in the source tarball
references the commit-id from which the tarball was created.
Then, in a second step, a script can check ./configure to find
the parent commit. This is for example done by the 'makerepo.sh'
script.
This is generally useful, and also done by network-manager-applet
and libnl3 projects. Move the function to a separate m4 macro
to reuse it. It should also be re-used in NetworkManager's VPN plugins.
(cherry picked from commit b33aacbc91)
Some drivers (brcmfmac) don't change the MAC address right away.
NetworkManager works around that by waiting synchronously until
the address changes (commit 1a85103765).
wpa_supplicant on the other hand, only re-reads the MAC address
when changing state from DISABLED to ENABLED, which happens when
the interface comes up.
That is a bug in wpa_supplicant and the driver, but we can work-around by
waiting until the MAC address actually changed before setting the interface
IFF_UP. Also note, that there is still a race in wpa_supplicant which might
miss a change to DISABLED state altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=770504https://bugzilla.redhat.com/show_bug.cgi?id=1374023
(cherry picked from commit 32f7c1d4b9)
An empty 802-11-wireless-security.proto is equivalent to
'wpa,rsn'. Previously we added the two protocols when reading the
connection and the variables were missing, with the result that an
empty value would be read as 'wpa,rsn' at the next restart. This is
harmless but makes the two connections appear as different, with bad
effects when 'monitor-connection-files' is enabled.
Ensure that the original value persists after a write/read cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=770907
(cherry picked from commit 00c4e7e73a)
brcmfmac and possibly other drivers don't change the MAC address
right away, but instead the result is delayed. That is problematic
because we cannot continue activation before the MAC address is
settled.
Add a hack to workaround the issue by waiting until the MAC address
changed.
The previous attempt to workaround this was less intrusive: we would
just refresh the link once and check the result. But that turns out
not to be sufficent for all cases. Now, wait and poll.
https://bugzilla.gnome.org/show_bug.cgi?id=770456https://bugzilla.redhat.com/show_bug.cgi?id=1374023
(cherry picked from commit 1a85103765)
A D-Bus signal is asynchronous and it can happen that nm-dhcp-helper
emits the "Event" signal before the server is able to register a handler:
NM_DHCP_HELPER=/usr/libexec/nm-dhcp-helper
nmcli general logging level TRACE
for i in `seq 1 500`; do $NM_DHCP_HELPER & done
journalctl -u NetworkManager --since '1 min ago' | grep "didn't have associated interface" | wc -l
499
Avoid that, by calling the synchronous D-Bus method "Notify".
Interestingly, this race seem to exist since 2007.
Actually, we called g_dbus_connection_signal_subscribe() from inside
GDBusServer:new-connection signal. So it is not clear how such a race
could exist. I was not able to reproduce it by putting a sleep
before g_dbus_connection_signal_subscribe(). On the other hand, there
is bug rh#1372854 and above reproducer which strongly indicates that
events can be lost under certain circumstances.
Now we instead g_dbus_connection_register_object() from the
new-connection signal. According to my tests there was no more race
as also backed by glib's documentation. Still, keep a simple retry-loop
in nm-dhcp-helper just to be sure.
https://bugzilla.redhat.com/show_bug.cgi?id=1372854https://bugzilla.redhat.com/show_bug.cgi?id=1373276
(cherry picked from commit 2856a658b3)
Don't exit(1) from fatal_error() because that skips destroying
local variables in main(). Just return regularly.
(cherry picked from commit bb489163db)
It's not "signal-handles", as it currently tracks the registration ID of
type int. Rename it, it is effectively the list of connections that we
track.
(cherry picked from commit 2dd3a5245f)
tv.tv_usec is guaranteed to have less then 6 digits, however rounding it up
we might reach 1000000 and thus the value becomes mis-aligned. To round
correctly, we would have to carry over a potential overflow to the seconds.
But that seems too much effort for little gain. Just truncate the value.
(cherry picked from commit c1b4b99a3c)
