Currently the editor runs in a dedicated thread so that the blocking
call to readline() doesn't stop the processing of D-Bus events in the
main loop. The editor thread can access objects concurrently with the
main thread and this can cause races and crashes.
Remove the editor thread and use the non-blocking readline API.
https://bugzilla.gnome.org/show_bug.cgi?id=732097https://bugzilla.redhat.com/show_bug.cgi?id=1368353
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
Unify the two check_ip_done() and check_ip_failed() functions into a
single one to have all the state transition logic in the same place.
This also fixes a regression introduced by commit 553717bb1c
("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled").
After that commit the device immediately proceeded to IP_CHECK when
there was a disabled/ignore method. Now we wait for the termination of
the other method, like it used to be.
Fixes: 553717bb1chttps://bugzilla.gnome.org/show_bug.cgi?id=771579
It's potentially unexpected by user that dnsmasq works differently
from the libc resolver and doesn't try the servers in order. Add a
paragraph to explain that and how to tweak the resolution order.
Every program run during the build which loads a NM library must
preload libasan.so if the address sanitizer is enabled.
Add a macro to set the needed environment variables and use it when
performing the shared object link tests.
When a VPN plugin logs to syslog(), it should not use the syslog
levels that were passed in by NetworkManager directly. Instead,
it must map LOG_NOTICE to LOG_INFO and LOG_INFO to LOG_DEBUG.
Add a utility function does gets that right.
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
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.
The core only consider the first address for shared connections, don't
pretend we accept multiple addresses. This change doesn't prevent
supporting multiple addresses in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=763937
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.
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
This was added by commit 4de8851eca, probably
by copying from NMDeviceVlan. It's not clear why a netlink request to
set the device IFF_UP would fail, or why that warrants a retry.
This retry loop was added by commit dc6341acec.
But I suspect, that the main-point there was not to retry the netlink
request to set the interface up. Why would that fail, and why would
a failure to set the interface up require a retry?
I think it was added to wait for carrier. But waiting for carrier was
later dropped with commit 5074898591
and it is not clear why we would wait for carrier at all -- we don't
do that for other device types either.
Instead of letting the sub-class check the "enabled" state, let
it be handled by nm_device_bring_up().
Note that nm_device_get_enabled() only has two implementations:
NMDeviceModem:bring_up() and NMDeviceWifi:bring_up().
The virtual function NMDevice:set_enabled() has two implementations:
NMDeviceModem and NMDeviceWifi. Likewise, the get_enabled() function
should also be implemented by those types.
The only caller of nm_device_get_enabled() is NMPolicy:schedule_activate_check().
It is correct to skip Wi-Fi devices based on their enabled state.
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
Long ago before commit 1b49f94, NetworkManager did not touch the
MAC address at all. Since 0.8.2 NetworkManager would modify the
MAC address, and eventually it would reset the permanent MAC address
of the device.
This prevents a user from externally setting the MAC address via tools
like macchanger and rely on NetworkManager not to reset it to the
permanent MAC address. This is considered a security regression in
bgo#708820.
This only changed with commit 9a354cd and 1.4.0. Since then it is possible
to configure "cloned-mac-address=preserve", which instead uses the "initial"
MAC address when the device activates.
That also changed that the "initial" MAC address is the address which was
externally configured on the device as last. In other words, the
"initial" MAC address is picked up from external changes, unless it
was NetworkManager itself who configured the address when activating a
connection.
However, in absence of an explicit configuration the default for
"cloned-mac-address" is still "permanent". Meaning, the user has to
explicitly configure that NetworkManager should not touch the MAC address.
It makes sense to change the upstream default to "preserve". Although this
is a change in behavior since 0.8.2, it seems a better default.
This change has the drastic effect that all the existing connections
out there with "cloned-mac-address=$(nil)" change behavior after upgrade.
I think most users won't notice, because their devices have the permanent
address set by default anyway. I would think that there are few users
who intentionally configured "cloned-mac-address=" to have NetworkManager
restore the permanent address.
https://bugzilla.gnome.org/show_bug.cgi?id=770611
