Depending on how arguments are passed to the called function,
this could lead to a crash.
Maybe not on 32 bit machines where the size of the pointer is
the size of an int.
Maybe not on x86_64, where the arguments are passed in registers.
Fixes: b88c309167
(cherry picked from commit 548a5440e9)
The file, imported from systemd sources, contains macros for accessing
potentially unaligned data in a safe way (i.e. byte-wise).
(cherry picked from commit 22cc119da5)
We connect signal handlers to devices when they appear, but don't
disconnect the handlers when the manager instance is destroyed. This
can cause crashes as device_ac_changed() is called on an invalid
manager instance.
Disconnect the handlers from dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383758
(cherry picked from commit 0a61317870)
The @assoc_cancellable was never initialized and thus ineffective; fix
this.
Furthermore, we only cancel it in nm_supplicant_interface_disconnect()
as we expect that clients call the function before destroying the
interface. Don't assume this and also cancel it in dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383628
(cherry picked from commit 0539725aef)
Since commit ac888de151 ("cli/connections: fail the activation when
the active connection disappears") we rely only on the disappearing of
the active-connection to determine the failure of an activation.
libnm can collapse a 'added' and a 'removed' signal if they are
received closer enough and thus we may miss the removal of the active
connection. Restore the detection of failure based on
active-connection state.
(cherry picked from commit 79a357b07a)
Previously, when the load of an object failed and there were other
objects waiting for it, those objects would remain waiting
forever. Make them fail as well.
(cherry picked from commit f4a0ab757f)
Some TTY drivers or devices appear to ignore port speed and always
report zero. Technically this means the port is hung up and control
lines should be disconnected, but with USB devices many of the serial
port attributes are meaningless and ignored by some devices.
pppd requires the port's speed to be greater than zero, and will
exit immediately when that is not the case, even though these
modems will work fine. Passing an explicit speed to pppd in this
case works around the issue, as pppd attempts to set that speed
on the port and doesn't actually care if that operation fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1281731
(cherry picked from commit 01de14b1ddcd011ebc2f4676e5950b9ec890c698)
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)
