If SIM in a modem is locked, ModemManager can't initialize SupportedIpFamilies
and NetworkManager will set the property to 0. ModemManager then updates the
property after the modem is unlocked, but NetworkManager did not watch changes
to the property. And that resulted in a connection failure:
(ttyUSB1): Failed to connect 'O2 Internet': Connection requested IPv4 but IPv4 is unsuported by the modem.
(ttyUSB1): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28]
https://bugzilla.redhat.com/show_bug.cgi?id=1263959
Got a crash with unknown reason on nm-1-0 branch. It's unclear why,
but the reason could be that a lease in client_receive_advertise()
was cleared, but not its timers.
Backtrace from nm-1-0 branch (note that the systemd code where the crash
happend is different, but similar):
#0 sd_event_source_unref (s=0xf5c007e8fb894853) at dhcp-manager/systemd-dhcp/nm-sd-adapt.c:53
#1 0x0000555555682340 in client_timeout_t1 (s=<optimized out>, usec=<optimized out>, userdata=0x5555559f5240)
at dhcp-manager/systemd-dhcp/src/libsystemd-network/sd-dhcp6-client.c:451
#2 0x00005555556a078f in time_ready (source=0x5555559f3c20) at dhcp-manager/systemd-dhcp/nm-sd-adapt.c:146
#3 0x00007ffff4a481b3 in g_timeout_dispatch () from /lib64/libglib-2.0.so.0
#4 0x00007ffff4a4779a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#5 0x00007ffff4a47ae8 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0
#6 0x00007ffff4a47dba in g_main_loop_run () from /lib64/libglib-2.0.so.0
#7 0x0000555555597073 in main (argc=1, argv=0x7fffffffe2b8) at main.c:512
Equivalent upstream systemd patch:
https://github.com/systemd/systemd/pull/1332f89087272bhttps://bugzilla.redhat.com/show_bug.cgi?id=1260727
sd_event_source is either used for sd_event_add_io() or sd_event_add_time().
Depending on the use, different fields of the struct are relevant. Refactor
the struct to have a union.
This reduces the size of the struct, but more importantly, it makes it
clear which fields are used in which context.
Systemd supports omitting the output source argument. In this case,
the created event source is floating and the reference count
is handled properly.
We have however no callers that make use of that functionality, so
instead of implementing floating references, assert that we don't
need it.
This isn't a change in behavior, because previously the could would just
SEGFAULT if a caller didn't want to take ownership of the created event.
Especially systemd, which makes use of the error argument for logging, likes
to represent errors as negative numbers. We hence must invert a negative error
code to get the real errno.
NetworkManager set wpa_supplicant's fragment_size option to 1300. But if MTU
was lower, wpa_supplicant failed with "l2_packet_send - sendto: Message too
long" due to fragmentation of EAP-TLS or EAP-PEAP packets.
Actually, MTU has to be 14 bytes bigger than the "fragment_size" parameter.
Ideally, wpa_supplicant would take MTU in the account and adjust the
fragmentation limit accordingly. See discussion in
http://lists.shmoo.com/pipermail/hostap/2015-August/033546.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=755145
Without that DATADIRNAME was not present in po/Makefile.in.in
and it resulted in /usr/\@DATADIRNAME\@/locale/cs/LC_MESSAGES/ path instead of
/usr/share/locale/cs/LC_MESSAGES/.
https://bugzilla.redhat.com/show_bug.cgi?id=1265117
- Reorder statements, to first g_return_if_fail() and log state-change.
- Also log a message when leaving _set_state_full() early due to missing firmware.
- implements 'nmcli connection add type adsl'
- initializes adsl.protocol for 'nmcli con edit type adsl'
- fixes errors in adsl properties in libnm-core/libnm-util
g_dbus_message_get_interface() can return NULL in the message filter,
for example when the client does:
#!/usr/bin/env python
import dbus
bus = dbus.SystemBus()
proxy = bus.get_object("org.freedesktop.NetworkManager",
"/org/freedesktop/NetworkManager")
proxy.foobar()
Use g_strcmp0() to compare the interface and member names.
Fixes: 34ba4e14b8
While an NMExportedObject is exported (i.e. registered at NMBusManager),
it has a list of GDBusInterfaceSkeleton interfaces. The properties of
the nm-object are bound to the interfaces and the signals connected.
Previously, when unexporting the NMExportedObject, we would only unref
the interfaces, but not explicitly disconnect. As there is no guarantee
that the lifetime of the interfaces is shorter then the lifetime of the
nm-object, hence, explicitly disconnect.
Clone the connection upon activation. This makes it safe for the user
to modify the original connection while it is activated.
This involves several changes:
- NMActiveConnection gets @settings_connection and @applied_connection.
To support add-and-activate, we constructing a NMActiveConnection with
no connection set. Previously, we would set the "connection" field to
a temporary NMConnection. Now NMManager piggybacks this temporary
connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE).
- get rid of the functions nm_active_connection_get_connection_type()
and nm_active_connection_get_connection_uuid(). From their names
it is unclear whether this returns the settings or applied connection.
The (few) callers should figure that out themselves.
- rename nm_active_connection_get_id() to
nm_active_connection_get_settings_connection_id(). This function
is only used internally for logging.
- dispatcher calls now get two connections as well. The
applied-connection is used for the connection data, while
the settings-connection is used for the connection path.
- needs special handling for properties that apply immediately
when changed (nm_device_reapply_settings_immediately()).
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=724041
NMSecretAgent (and in turn NMAgentManager) used the @connection argument both
for the connection data, but also for the connection path. Detangle these, and
accept the path separate from the connection.
This makes NMSecretAgent and NMAgentManager truly operate on a plain
NMConnection, without the non-obvious requirement, that the path of the
connection must be set.
Those getters are convenience methods to retrieve the id/type from
the NMSettingConnection. If the NMSettingConnection was missing
(and thus the connection invalid) we would raise an assertion.
Don't be so strict and just silently return NULL.
Otherwise, the caller cannot use the functions on unverified
connections.
This now gives every logging line of a NMVpnConnection
a fully descriptive prefix.
Especially for non-debug logging, this looks a bit verbose
and repetitive, so we could suppress the prefix in that case.
I still add it because I think the verbose information does help
during debugging.
connection_added() can be called before init_get_settings_cb(), and we can't
complete the connection until it is visible, else it would be uninitialized.
Test case:
* have 'em1' interface
$ nmcli con add type ethernet con-name myeth ifname em1 autoconnect no
(process:9039): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
$ nmcli con add type ethernet con-name myeth ifname em1X autoconnect no
Connection 'myeth' (71159504-c2af-4773-8ca9-a3626aa0da33) successfully added.
https://bugzilla.gnome.org/show_bug.cgi?id=754767https://bugzilla.gnome.org/show_bug.cgi?id=754794
[lkundrak@v3.sk: This is not quite the correct fix, we shouldn't emit
NMObject:connection-added for an unfinished object. Nevertheless, let's go with
it until we have a better one. Will revert this afterwards. See linked bugs.]
