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)
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)
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)
Before switching to gdbus (before 1.2.0), NetworkManager used dbus-glib.
Most objects in the D-Bus API with properties had a signal
NetworkManager-specific "PropertiesChanged" signal. Nowadays, this way of
handling of property changes is deprecated for the common "PropertiesChanged"
signal on the "org.freedesktop.DBus.Properties" interface.
There were a few pecularities in 1.0.0 and earlier:
(1) Due to the implementation with dbus-glib, a property-changed
signal was emitted on *all* interfaces. For example:
- a change on a NMDeviceVeth of "NMDeviceEthernet.HwAddress" would be
emitted both for the interfaces "fdo.NM.Device.Ethernet" and
"fdo.NM.Device.Veth". Note that NMDeviceVeth is derived from
NMDeviceEthernet and there is no "HwAddress" on veth device.
- a change of "NMVpnConnection.VpnState" was emitted on both
interfaces "fdo.NM.VPN.Connection" and "fdo.NM.Connecion.Active".
Note that NMActiveConnection is the parent type of NMVpnConnection and
only the latter has a property "VpnState".
(2) NMDevice's "fdo.NM.Device" interface doesn't have a "PropertiesChanged"
signal. From (1) follows that all property-changes for this type were instead
invoked with an interface like "fdo.NM.Device.Ethernet" (or multiple
interfaces in case of NMDeviceVeth).
1.2.0 introduced gdbus, which gives us the standard "fdo.DBus.Properties"
signal. However, it made the mistake of not realizing (1), thus instead
of emitting the signal once for each interface, it would pick the first
one in the inheritance tree.
With 1.4.0, a bug from merge commit 844345e caused signals for devices
to be only emitted for the interface "fdo.NM.Device.Statistics", instead
of "fdo.NM.Device.Ethernet" or "fdo.NM.Device.Veth" (or both).
The latter is what bgo#770629 is about and what commit 82e9439 tried to fix.
However, the fix was wrong because it tried to do the theoretically correct
thing of emitting the property-changed signal exactly once for the
interface that actually ontains the property. In addition, it missed that
NMDevice doesn't have a PropertiesChanged signal, which caused signals for
"fdo.NM.Device" to get lost *sigh*.
Now, restore the (broken) behavior of 1.0.0. These old-style property changed
signals are anyway considered deprecated and exist solely to satisfy old clients
and preserve the old API.
Fixes: 63fbfad3705db5901e6a2a6a2fc332da0f0ae4be
https://bugzilla.gnome.org/show_bug.cgi?id=770629https://bugzilla.redhat.com/show_bug.cgi?id=1371920
(cherry picked from commit bef26a2e69)
Now that we validate the JSON syntax of a team/team-port
configuration, any existing connection with invalid JSON configuration
would fail to load and disappear upon upgrade. Instead, modify the
setting plugins to emit a warning but still load the connection with
empty configuration.
(cherry picked from commit d6ec009afd)
After the fix in [1], if the connection is assumed we don't update its
firewall zone. The goal of that change was to prevent NM from
interfering with the configuration done externally on devices not
created by NM.
However if there is an assumed persistent connection active on the
device NM touches the configuration in other ways, for example it
configures DHCP and manages the default route. So it seems correct to
also update the firewall zone.
OTOH, if the connection is assumed-generated there is no persistent
connection specifying a firewall zone and updating it makes no sense.
Bug [1] was about not interfering with devices unknown to NM (for
which there is no persistent connection) and so this change should not
conflict with the previous fix.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1098281https://bugzilla.redhat.com/show_bug.cgi?id=1366288
(cherry picked from commit c39e03edbf)
nm_exported_object_notify() hooks GObject's property-change signal
and searches for the D-Bus interface to which to send the
PropertiesChanged signal.
Then it would enqueue the value encoded as GVariant in pending_notifications.
However, thereby the association between the property that changed and the
interface was lost. So later in idle_emit_properties_changed() it would
just pick the first interface with a properties-changed-id.
That is wrong. pending_notifications must be associated with the D-Bus
interface that we are going to notify. That is, each InterfaceData must
have its own separate list.
This is broken since introducing NMExportedObject and moving to gdbus.
Only now it was discovered as NMDevice itself has two D-Bus interfaces:
"Device" and "Device.Statistics".
Note that the order of the PropertiesChanged in our D-Bus API is not defined
so that later signals can reach the receiver before earlier signals.
Also, multiple change signals for one property may be combined.
That is not changed by this patch and is not considered a bug, but something
that our D-Bus API wrt. PropertiesChanged does not guarantee.
https://bugzilla.gnome.org/show_bug.cgi?id=770629
(cherry picked from commit 82e94390de)
At this point we don't know if the slave has been using an assumed
connection that just vanished -- the best bet is to let the device be.
If it's meant to be unenslaved, it won't be due to an external event.
https://bugzilla.redhat.com/show_bug.cgi?id=1357738
(cherry picked from commit 3127fb0d17)
When a software device unrealizes, we want to forget about the "user-explict"
unmanaged state. It means, that after a software device is deleted, the
"user-explict" managed flag will be cleared for that device.
It might be nice to preserve the managed-state after deletion of the device.
However, the unrealized-device only exists as long as we have a connection
for the device. That means, before this patch whether the unmanaged flag
was forgotten depends on whether the user had some connections that keep
the device alive as unrealized. That behavior was complicated, just don't
do that.
(cherry picked from commit 34880d62d0)
There is a "goto retry" in do_change_link_request(), at that point,
seq_result has the value -EOPNOTSUPP, instead of
WAIT_FOR_NL_RESPONSE_RESULT_UNKNOWN.
Fixes: 02fb3eff48
(cherry picked from commit 145d199589)
It seems some drivers return success for nm_platform_link_set_address(),
but at that point the address did not yet actually change *sigh*.
It changes a bit later, possibly after setting the device up.
Add a workaround to retry reading the MAC address when platform indicates
success but the address still differs at first.
https://bugzilla.gnome.org/show_bug.cgi?id=770456
(cherry picked from commit 67b6852358)
Seems odd numbers may be coerced to the next-smaller even number.
Avoid that by using an even number for the test, as the number
has no particular meaning.
https://bugzilla.gnome.org/show_bug.cgi?id=765835
(cherry picked from commit 895c61a742)
Depending on the connection we are about to read,
we would assert that the user provided a @out_unhandled
argument.
That means, the user must always provide a valid @out_unhandled
pointer, because he cannot know beforehand how the reading
of the ifcfg file goes.
(cherry picked from commit 50d7ac4af3)
Clear some IP related entries from the ifcfg-rh file if
the connection is a slave connection.
Also, drop utils_ignore_ip_config(). It is guaranteed, that
writer only handles connections that verify(). Such connections
have an IPv4/IPv6 setting if (and only if) they are not slave
types.
https://bugzilla.redhat.com/show_bug.cgi?id=1368761
(cherry picked from commit cf7b8866ce)
