The statement
g_return_val_if_reached (NM_MODEM_IP_TYPE_UNKNOWN);
was wrong, because the return type is 'const char *'.
But just refactor nm_modem_ip_type_to_string() to get rid of
the static table and make it a switch statement.
Fixes: 02beeeeb12
(cherry picked from commit 5599a82d0d)
dhclient only supports fqdn.fqdn for server DDNS updates with
DHCPv6. And even though the underlying DHCP options that fqdn.fqdn
controls allow non-qualified hostnames on the wire, dhclient does
not. So we must require a fully-qualified name for DHCPv6.
Second, while no-client-updates seems like it should be "off", doing
that apparently makes dhclient set the "O" flag to 1 which appears to
be a bug, and results in the server not doing the DDNS update. So
we must stop setting that option too.
Found by: Alexander Groß
(cherry picked from commit 677cee0f23)
When ipv4=auto and ipv6=auto, we'll first try with the IPv4v6 PDP type, and if
that fails (e.g. if either the modem or the operator doesn't support it), we'll
fallback to trying with IPv4 or IPv6 PDP types (only if may-fail configuration
allows it).
Patch based on a previous implementation by Dan Williams <dcbw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=733696
When the modem device is abruptly disconnected,
nm_modem_device_state_changed() calls deactivate_cleanup() with a NULL
device argument and that's perfectly fine.
We should only check the instance type if we know the device is non-NULL.
(NetworkManager:9166): NetworkManager-wwan-CRITICAL **: deactivate_cleanup: assertion 'NM_IS_DEVICE ( failed
(cherry picked from commit 41c87eb363)
ModemManager needs to have CLOCAL set in the TTY termios configuration, in order
to notify the kernel that modem control lines are not in effect (e.g. so that a
transition to LOW in the DCD input control line doesn't trigger a hangup in the
TTY).
pppd in the other hand, needs CLOCAL unset in order to have proper modem control
lines in effect during the PPP session. So, when pppd starts it will store the
original termios settings, and before exiting it will restore the original
settings in the TTY. In other words, if CLOCAL was set before launching pppd,
CLOCAL will be also set after pppd exits.
Now, in order for this sequence to work correctly, NetworkManager also needs to
make sure that ModemManager is notified about the disconnection only after pppd
has really finished re-configuring the TTY.
https://bugzilla.gnome.org/show_bug.cgi?id=734347
----------------------
Once the patch is applied, we will be making sure that ModemManager is only
notified about the disconnection AFTER pppd has fully exited:
NetworkManager[27589]: <info> (ttyUSB2): device state change: activated -> deactivating (reason 'user-requested') [100 110 39]
Terminating on signal 15
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 10 / phase 'terminate'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 8 / phase 'network'
Connect time 0.3 minutes.
Sent 56 bytes, received 0 bytes.
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 11 / phase 'disconnect'
Connection terminated.
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 1 / phase 'dead'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_exit_notify): cleaning up
NetworkManager[27589]: <warn> pppd pid 27617 exited with error: pppd received a signal
NetworkManager[27589]: <info> (ttyUSB2): modem state changed, 'connected' --> 'disconnecting' (reason: user-requested)
NetworkManager[27589]: <info> (ttyUSB2): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[27589]: <info> (ttyUSB2) modem deactivation finished
NetworkManager[27589]: <info> (ttyUSB2): device state change: deactivating -> disconnected (reason 'user-requested') [110 30 39]
NetworkManager[27589]: <info> (ttyUSB2): deactivating device (reason 'user-requested') [39]
(cherry picked from commit fe090c34b7)
This method doesn't prevent the original logic in which the child process was
stopped when the last reference of the PPP manager was unref-ed.
(cherry picked from commit 14f732e8df)
This method isn't run if NM is quitting; so the deactivate() method still needs
to be implemented to handle sync disconnection requests.
(cherry picked from commit f3efdbcdf2)
It's always user requested -- auto activation never happens on already active
devices. nm_device_release_one_slave() rightly asserts teardown with
(un)configuration does not happen for no reason at all.
https://bugzilla.gnome.org/show_bug.cgi?id=744812
(cherry picked from commit 600489003f)
Since GCC 4.4, gcc does not warn about unknown -Wno-* flags. At
least, it does not warning unless another warning is raised as well
(https://gcc.gnu.org/wiki/FAQ#wnowarning).
We didn't notice up to now, because we only tested flags that GCC
actually supports.
Hack around this, by checking for the -W* counterpart instead.
(cherry picked from commit 0462104317)
It was confusing to understand the difference between calling nm_device_connection_is_available()
and check_connection_available(), they behaved similar, but not really
the same. Especially nm_device_connection_is_available() would look
first into @available_connetions, and might call check_connection_available()
itself. Whereas @available_connetions was also populated by testing
check_connection_available(). This interrelation makes it hard to
understand when nm_device_connection_is_available() returned true.
Rename nm_device_connection_is_available() to nm_device_check_connection_available()
and remove all direct calls of check_connection_available() in favor of
the wrapper nm_device_check_connection_available().
Now we only call nm_device_check_connection_available() with different
parameters (@flags and @specific_object). We also have the additional
guarantee that specifying more @flags will widen the result and making
a connection "more" available, while specifying a @specific_object will
restrict it.
This also changes behavior in several cases. For example before
nm_device_connection_is_available() for user-requests would always
declare matching connections available on Wi-Fi devices (only)
regardless of the device state. Now the device state gets consistently
considered.
For default-unmanaged devices it also changes behavior in complicated
ways, because before we would put connections into @available_connetions
for every device-state, but nm_device_connection_is_available() had a
special over-ride only for unmanaged-state.
This also fixes a bug, that user can activate an unavailable Wi-Fi
device:
nmcli radio wifi off
nmcli connection up wlan0
(cherry picked from commit d80f1bf4f0)
Having logging statements in a simple getter (or is_*()) means
you cannot call these functions without cluttering the log.
Another approach would be to add an @out_reason argument, and
callers who actually care log the reason. For now, just get rid
of the messages.
(cherry picked from commit e524be2c34)
The argument name should express what the caller wants
(he wants to know, whether the connection can be activated
for an internal or external activation request).
Whether that involves checking device-specific overrides, is
not the point -- nm_device_check_connection_compatible() is
also a virtual function with device-specific overrides.
(cherry picked from commit a7e0a038bf)
The queued activation request must transition state to
DEACTIVATED, otherwise it is not removed from the list
of active_connections in NMManager.
(cherry picked from commit b9da094da9)
After refactoring libnm-core to use GBytes instead of
GByteArray/DBUS_TYPE_G_UCHAR_ARRAY, it was forgotten to update
keyfile writer.
This causes keyfile writer to skip the NMSetting8021x:password-raw setting
and raise a g_critical() warning.
Fixes: c43f88907b
(cherry picked from commit c651b27793)
==12663== 45 bytes in 1 blocks are definitely lost in loss record 2,464 of 4,708
==12663== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12663== by 0x7F4A6F5: g_malloc (gmem.c:97)
==12663== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==12663== by 0x4B8AE5: nm_manager_new (nm-manager.c:4793)
==12663== by 0x432F3D: main (main.c:413)
(cherry picked from commit b1e6c9be91)
==29353== 620 (+620) (32 (+32) direct, 588 (+588) indirect) bytes in 1 (+1) blocks are definitely lost in loss record 6,905 of 7,076
==29353== at 0x7CDBAC8: g_type_create_instance (gtype.c:1844)
==29353== by 0x7CBF356: g_object_new_internal (gobject.c:1774)
==29353== by 0x7CC0D4C: g_object_newv (gobject.c:1922)
==29353== by 0x7CC14E3: g_object_new (gobject.c:1614)
==29353== by 0x50B58A: nm_secret_agent_new (nm-secret-agent.c:489)
==29353== by 0x50915F: impl_agent_manager_register_with_capabilities (nm-agent-manager.c:309)
==29353== by 0x62649BE: invoke_object_method (dbus-gobject.c:1899)
==29353== by 0x62649BE: object_registration_message (dbus-gobject.c:2161)
==29353== by 0x649D5CE: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:1018)
==29353== by 0x648F193: dbus_connection_dispatch (dbus-connection.c:4718)
==29353== by 0x6261DB4: message_queue_dispatch (dbus-gmain.c:90)
==29353== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==29353== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==29353== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
(cherry picked from commit 7d706daf3e)
==5177== 6 (+6) bytes in 1 (+1) blocks are definitely lost in loss record 118 of 6,581
==5177== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5177== by 0x7F4A6F5: g_malloc (gmem.c:97)
==5177== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==5177== by 0x4AD902: nm_auth_chain_set_data (nm-auth-utils.c:194)
==5177== by 0x50919E: impl_agent_manager_register_with_capabilities (nm-agent-manager.c:323)
==5177== by 0x62649BE: invoke_object_method (dbus-gobject.c:1899)
==5177== by 0x62649BE: object_registration_message (dbus-gobject.c:2161)
==5177== by 0x649D5CE: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:1018)
==5177== by 0x648F193: dbus_connection_dispatch (dbus-connection.c:4718)
==5177== by 0x6261DB4: message_queue_dispatch (dbus-gmain.c:90)
==5177== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==5177== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==5177== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==5177== by 0x7F451B1: g_main_loop_run (gmain.c:3975)
(cherry picked from commit da5c332151)
==5177== 104 (+104) bytes in 1 (+1) blocks are definitely lost in loss record 5,502 of 6,581
==5177== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5177== by 0x7F4A6F5: g_malloc (gmem.c:97)
==5177== by 0x7F6159F: g_slice_alloc (gslice.c:1007)
==5177== by 0x7F61B6D: g_slice_alloc0 (gslice.c:1032)
==5177== by 0x7CDB9A3: g_type_create_instance (gtype.c:1847)
==5177== by 0x7CBF356: g_object_new_internal (gobject.c:1774)
==5177== by 0x7CC0D4C: g_object_newv (gobject.c:1922)
==5177== by 0x7CC14E3: g_object_new (gobject.c:1614)
==5177== by 0x79A4C57: g_simple_async_result_new (gsimpleasyncresult.c:319)
==5177== by 0x515B34: nm_connectivity_check_async (nm-connectivity.c:289)
==5177== by 0x515D74: run_check (nm-connectivity.c:217)
==5177== by 0x515DBF: idle_start_periodic_checks (nm-connectivity.c:229)
(cherry picked from commit e5499c558f)
Conflicts:
src/nm-connectivity.c
==1345== Invalid read of size 1
==1345== at 0x827DC15: vfprintf (vfprintf.c:1642)
==1345== by 0x8345D04: __vasprintf_chk (vasprintf_chk.c:66)
==1345== by 0x7F882DB: vasprintf (stdio2.h:210)
==1345== by 0x7F882DB: g_vasprintf (gprintf.c:316)
==1345== by 0x7F6319C: g_strdup_vprintf (gstrfuncs.c:507)
==1345== by 0x7F63258: g_strdup_printf (gstrfuncs.c:533)
==1345== by 0x472833: nm_platform_link_to_string (nm-platform.c:2337)
==1345== by 0x472A05: log_link (nm-platform.c:2754)
==1345== by 0x9DC5D5F: ffi_call_unix64 (unix64.S:76)
==1345== by 0x9DC57D0: ffi_call (ffi64.c:525)
==1345== by 0x7CBA553: g_cclosure_marshal_generic (gclosure.c:1448)
==1345== by 0x7CB9D34: g_closure_invoke (gclosure.c:768)
==1345== by 0x7CCB34B: signal_emit_unlocked_R (gsignal.c:3483)
==1345== Address 0xa91b5a0 is 0 bytes inside a block of size 5 free'd
==1345== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1345== by 0x68E7D6D: link_free_data (link.c:223)
==1345== by 0x6D47B1F: nl_object_free (object.c:186)
==1345== by 0x46C31C: put_nl_object (nm-linux-platform.c:222)
==1345== by 0x46C31C: link_change (nm-linux-platform.c:2354)
==1345== by 0x46C87F: link_set_user_ipv6ll_enabled (nm-linux-platform.c:2583)
==1345== by 0x4476C4: set_nm_ipv6ll (nm-device.c:4418)
==1345== by 0x4476C4: ip6_managed_setup (nm-device.c:7515)
==1345== by 0x453F12: _set_state_full (nm-device.c:7665)
==1345== by 0x4B6609: add_device (nm-manager.c:1885)
==1345== by 0x4B6880: system_create_virtual_device (nm-manager.c:1126)
==1345== by 0x4B6B40: system_create_virtual_devices (nm-manager.c:1163)
==1345== by 0x4B6E00: platform_link_added (nm-manager.c:2213)
==1345== by 0x4B6E00: platform_link_cb (nm-manager.c:2228)
==1345== by 0x9DC5D5F: ffi_call_unix64 (unix64.S:76)
(cherry picked from commit f93f0e0b15)
ndp_close() does not do that -- it only closes the socket. It's safe to call
even if we didn't start solicitation as it has a NULL-check.
==7745== 80 (+80) bytes in 2 (+2) blocks are definitely lost in loss record 3,983 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x6F57A2D: ndp_msgrcv_handler_register (libndp.c:1697)
==7745== by 0x47572E: start (nm-lndp-rdisc.c:691)
==7745== by 0x44A457: addrconf6_start_with_link_ready (nm-device.c:4280)
==7745== by 0x44C1E7: linklocal6_complete (nm-device.c:3931)
==7745== by 0x44C1E7: update_ip_config (nm-device.c:6667)
==7745== by 0x44C2F8: queued_ip_config_change (nm-device.c:6688)
==7745== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==7745== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==7745== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==7745== by 0x7F451B1: g_main_loop_run (gmain.c:3975)
==7745== by 0x432F74: main (main.c:460)
(cherry picked from commit 5d9f9febfb)
==7745== 37 (+37) bytes in 1 (+1) blocks are definitely lost in loss record 2,679 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45B097: set_property (nm-dhcp-client.c:851)
==7745== by 0x7CBF688: object_set_property (gobject.c:1415)
==7745== by 0x7CBF688: g_object_new_internal (gobject.c:1808)
==7745== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==7745== by 0x7CC14D0: g_object_new (gobject.c:1617)
==7745== by 0x45FF9F: client_start (nm-dhcp-manager.c:253)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
(cherry picked from commit c26ef29a47)
==7745== 11 (+11) bytes in 1 (+1) blocks are definitely lost in loss record 408 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45C188: nm_dhcp_client_start_ip4 (nm-dhcp-client.c:417)
==7745== by 0x460147: client_start (nm-dhcp-manager.c:268)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
==7745== by 0x456467: nm_device_activate_stage3_ip_config_start (nm-device.c:4801)
==7745== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==7745== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==7745== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
(cherry picked from commit 76430f9cca)
==4203== 97 (+97) bytes in 2 (+2) blocks are definitely lost in loss record 4,586 of 5,632
==4203== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4203== by 0x7F4A6F5: g_malloc (gmem.c:97)
==4203== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==4203== by 0x47E4C8: nm_settings_connection_set_filename (nm-settings-connection.c:2228)
==4203== by 0x7CBF6EC: object_set_property (gobject.c:1415)
==4203== by 0x7CBF6EC: g_object_new_internal (gobject.c:1828)
==4203== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==4203== by 0x7CC14D0: g_object_new (gobject.c:1617)
==4203== by 0x12A08193: nm_ifcfg_connection_new (nm-ifcfg-connection.c:229)
==4203== by 0x12A0542B: update_connection (plugin.c:225)
==4203== by 0x12A0696A: add_connection (plugin.c:715)
==4203== by 0x4814BB: nm_settings_add_connection (nm-settings.c:1030)
==4203== by 0x4817DE: pk_add_cb (nm-settings.c:1136)
(cherry picked from commit 9b7c8db16a)
