summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* contrib/modemu: respond to AT+COPS?lr/modemu-at-copsLubomir Rintel2022-02-031-0/+8
| | | | | This queries the operator code. If NetworkManager got one, it can connect the modem device automatically without setting the APN.
* merge: branch 'bg/assume-plat-init'Beniamino Galvani2022-02-033-22/+38
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1081
| * device: fix assuming connections when platform-init arrives lateBeniamino Galvani2022-02-033-19/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the NM_UNMANAGED_PLATFORM_INIT flag is cleared last in device_link_changed(), a recheck-assume is scheduled and then the device goes immediately to UNAVAILABLE. During the state transition, addresses and routes are removed from the interface. Then, recheck-assume finds that the device can be assumed but it's too late since the device was already deconfigured. This is a problem as the whole point of assuming a device is to activate a connection while leaving the device untouched. In the NMCI "dracut_NM_vlan_over_bridge and dracut_NM_vlan_over_bond" test, NM in real root tries to assume a vlan device that was activated in initrd. When the interface gets deconfigured in UNAVAILABLE, the connection to the NFS server breaks and the rootfs becomes inaccessible. The fix to this problem is to delay state transitions in device_link_changed() to a idle handler, so that recheck-assume can run before. Fixes-test: @dracut_NM_vlan_over_bridge Fixes-test: @dracut_NM_vlan_over_bond https://bugzilla.redhat.com/show_bug.cgi?id=2047302
| * device: remove unused if branch in device_link_changed()Beniamino Galvani2022-02-031-3/+4
|/ | | | | | nm_device_set_unmanaged_by_user_settings() does nothing when the device is unmanaged by platform-init. Remove the if branch to make this more explicit.
* l3cfg: merge branch 'th/l3cfg-acd-crash'Thomas Haller2022-02-021-74/+76
|\ | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=2047788 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1077
| * l3cfg: fix handling "instance-reset" ACD eventThomas Haller2022-02-021-49/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACD state handling is unfortunately very complicated. That is, because we obviously need to track state about how ACD is going (the acd_data, and in particular NML3AcdAddrState). Then there are various things that can happen, which are the AcdStateChangeMode enums. All these state-changes come together in one function: _l3_acd_data_state_change(), which is therefore complicated (I don't think that it would become simpler by spreading this code out to different functions, on the contrary). Anyway. So, what happens when we need to reset the n-acd instance? For example, because the MAC address of the link changed or some error. I guess, we need to restart probing. Previously, I think this was not handled properly. We already tried to fix this several times, the last was commit b3316063862b ('l3cfg: on n-acd instance-reset clear also ready ACD state'). There is still an issue ([1]). The bug [1] is, that we are in state NM_L3_ACD_ADDR_STATE_READY, during ACD_STATE_CHANGE_MODE_TIMEOUT event. That leads to an assertion failure. #5 0x00007f23be74698f in g_assertion_message_expr (domain=0x5629aca70359 "nm", file=0x5629aca62aab "src/core/nm-l3cfg.c", line=2395, func=0x5629acb26b30 <__func__.72.lto_priv.4> "_l3_acd_data_state_change", expr=<optimized out>) at ../glib/gtestutils.c:3091 #6 0x00005629ac937e46 in _l3_acd_data_state_change (self=0x5629add69790, acd_data=0x5629add8d520, state_change_mode=ACD_STATE_CHANGE_MODE_TIMEOUT, sender_addr=0x0, p_now_msec=0x7ffded506460) at src/core/nm-l3cfg.c:2395 #7 0x00005629ac939f4d in _l3_acd_data_timeout_cb (user_data=user_data@entry=0x5629add8d520) at src/core/nm-l3cfg.c:1933 #8 0x00007f23be71c5a1 in g_timeout_dispatch (source=0x5629addd7a80, callback=0x5629ac939ee0 <_l3_acd_data_timeout_cb>, user_data=0x5629add8d520) at ../glib/gmain.c:4889 #9 0x00007f23be71bd4f in g_main_dispatch (context=0x5629adc6da00) at ../glib/gmain.c:3337 #10 g_main_context_dispatch (context=0x5629adc6da00) at ../glib/gmain.c:4055 That can only happen, (I think) when we scheduled the timeout during an earlier ACD_STATE_CHANGE_MODE_INSTANCE_RESET event. Meaning, we need to handle instance-reset better. Instead, during instance-reset, switch always back to state PROBING, and let the timeout figure it out. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2047788
| * l3cfg: add comment to _acd_data_collect_tracks_data() about linear searchThomas Haller2022-02-021-0/+9
| |
| * l3cfg: add assertion for scheduling timeout in _l3_acd_data_timeout_schedule()Thomas Haller2022-02-021-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first point is that ACD timeout is strongly tied to the current state. That is (somewhat) obvious, because _l3_acd_data_state_set_full() will clear any pending timeout. So you can only schedule a timeout *after* setting the state, and setting the next state, will clear the timeout. Likewise, note that l3_acd_data_state_change() for the event ACD_STATE_CHANGE_MODE_TIMEOUT asserts that it is only called in the few states where that is expected. See rhbz#2047788 where that assertion gets hit. The first point means that we must only schedule a timer when we are also in a state that supports that. Add an assertion for that at the point when scheduling the timeout. The assert at this point is useful, because it catches the moment when we do the wrong thing (instead of getting the assertion later during the timeout, when we no longer know where the error happened). See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2047788
| * l3cfg: use nm_g_timeout_add_source() helpers in "nm-l3cfg.c"Thomas Haller2022-02-021-16/+5
| | | | | | | | | | It's shorter, and brevity lets us focus on the important things in the code.
| * l3cfg: only constructing log message when needed in ↵Thomas Haller2022-02-021-9/+11
|/ | | | _l3_acd_data_state_set_full()
* l3cfg: merge branch 'th/device-manual-l3cd-prio'Thomas Haller2022-02-024-10/+41
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1065
| * core: increase l3cfg merge priority for VPN configThomas Haller2022-02-013-4/+3
| | | | | | | | | | | | | | | | | | | | | | Now that higher priorities numbers really mean more important, it seems that the VPN configuration should be rather important. Bump the number, also in relation to NMDevice's L3ConfigDataType. It might not matter too much, because usually the VPN tunnel device does not have NDevice to add other l3cds and those from VPN might be alone. Except, maybe with routing VPN (libreswan) that is different. Dunno.
| * device: adjust NM_L3CFG_CONFIG_PRIORITY_IPV6LL and L3_CONFIG_DATA_TYPE_LL_6Thomas Haller2022-02-012-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | NM_L3CFG_CONFIG_PRIORITY_IPV6LL and L3_CONFIG_DATA_TYPE_LL_6 are somewhat related. They probably should be numerically identical. Now, L3_CONFIG_DATA_TYPE_LL_6 cannot be zero (because L3_CONFIG_DATA_TYPE_LL_4 is zero and L3ConfigDataType values must be distinct). Therefore, also bump NM_L3CFG_CONFIG_PRIORITY_IPV6LL to 1. Of course, NM_L3CFG_CONFIG_PRIORITY_IPV6LL is not obviously more important than NM_L3CFG_CONFIG_PRIORITY_IPV4LL. But to be consistent with L3_CONFIG_DATA_TYPE_LL_6 is probably more important here.
| * l3cfg: fix order of NML3ConfigData priorities in NML3CfgThomas Haller2022-02-012-3/+34
| | | | | | | | | | | | | | | | | | | | There was a disagreement whether higher priority numbers mean more/less important. NMDevice and callers of nm_l3cfg_add_config() assumed that higher numbers are more important, while _l3_config_datas_get_sorted_cmp() did the inverse. There is no obvious right or wrong. We only need to agree. It seems slightly more sensible to keep the caller's interpretation.
| * Revert "nm-device: prefer manually configured addresses to automatic"Thomas Haller2022-02-012-4/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | This commit does not seem correct. The enum was moved with the declared intent to make manual IP configuration preferred. But the code comment in L3ConfigDataType states that higher numbers are more important. Also, all the other values are intentionally ordered so that more important method have higher numbers. For example, LL_4 < DHCP_4 < SHARED_4 < DEV_4 (in increasing priority). While it's often not clear whether to prefer one method over the other, or what the actual effect of (LL_4 < DHCP_4) is, the numbers were chosen intentionally. Only moving MANUALIP first, counters the relative order of the other values. If there is the problem, that the code comment is wrong (and lower numbers mean more important), then we would have to reverse all enum values. The real problem is that NML3Cfg's _l3_config_datas_get_sorted_cmp() has the wrong order/understanding. So the real fix is there and will be done next. That is, unless we would agree that _l3_config_datas_get_sorted_cmp() is in the right, and prefer lower numbers -- in which case all values had to be reversed. This reverts commit af1903fe3f41acb79acfba6463615dff87abde01.
* dhcp: include "dhcp6_ntp_server" in Dhcp6ConfigLubomir Rintel2022-02-013-1/+30
| | | | | | | | | | | Works for the internal DHCP client only as sd-dhcp does the option parsing for us. The option 56 is not understood by dhclient so we would need to parse it ourselves. Let's not do it for now, as the RFC seems to written in a somewhat poor taste. https://bugzilla.redhat.com/show_bug.cgi?id=2047415#c2
* core/trivial: whitespaceThomas Haller2022-02-011-1/+0
|
* dhcp: improve error message in assertion of NMDhcpOption dataThomas Haller2022-02-011-3/+13
| | | | | | | | We have global data NMDhcpOption that describes the DHCP meta data. There is a consistency check with NM_MORE_ASSERTS. Improve the error message when the meta data is inconsistent to help finding the bug.
* ovsdb: unrealize removed ovs-interfaces on UNAVAILABLE stateFernando Fernandez Mancera2022-01-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | When NetworkManager shuts down, it is not done properly. We cannot ensure that all pending async operations are cancelled and therefore there are possible device leaks. This means that not all the devices will be disposed and finalized because a different component is handling a reference to it. Since the l3cfg refactor, this is affecting to ovs ports. When shutting down sometimes there are ovs-interface or ovs-port devices that are not being cleared correctly. When starting NetworkManager back, these devices are not going to be created again because they already exist and the existing compatible connections will be instruct to use the device. But currently, ovsdb is only unrealizing a device after removal if the state is UNMANAGED. This is wrong, because it will left an inconsistent state in NetworkManager and the ovs-port/ovs-interface connection won't be activated. The interfaces removed by ovsdb must be unrealized if they are on UNAVAILABLE state. https://bugzilla.redhat.com/show_bug.cgi?id=2029937
* device/wwan: add compat define for MM_MODEM_CAPABILITY_5GNRThomas Haller2022-01-291-0/+4
| | | | | MM_MODEM_CAPABILITY_5GNR was added in ModemManager 1.14. Add a define for compatibility with older versions.
* wwan: merge branch 'th/wwan-5gnr-capability'Thomas Haller2022-01-294-32/+30
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1076
| * device/wwan: drop deprecated MM_MODEM_CAPABILITY_LTE_ADVANCEDThomas Haller2022-01-291-16/+4
| | | | | | | | | | This is long deprecated, and was apparently never even used/exposed by ModemManager. Drop it.
| * device/wwan: use cleanup macro in get_capabilities()Thomas Haller2022-01-291-8/+5
| |
| * device/wwan: static assert that ModemManager and NM capabilities correspondThomas Haller2022-01-292-0/+9
| |
| * device/wwan: ensure capabilities are suitable 32 bit flagsThomas Haller2022-01-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The properties NM_DEVICE_MODEM_CAPABILITIES and NM_DEVICE_MODEM_CURRENT_CAPABILITIES are uint, with a range from zero to G_MAXUINT32. nm_modem_get_capabilities() passes the "untrusted" flags from ModemManager. Ensure that they fit into 32 bit, and don't cause an assertion failure due to the range check. Yes, in practice, on all platforms where we build (known to me), guint is always the same as guint32. So this has little effect. Also, cast to guint. Previously, this was just a C enum NMDeviceModemCapabilities, which theoretically has implementation defined sizes. Yes, in practice, they too are of size guint, and this was not an actual bug. But be specific about converting between different integer types.
| * libnm: use MODEM_CAPS_3GPP()/MODEM_CAPS_3GPP2() macros in get_setting_type()Thomas Haller2022-01-291-4/+2
| |
| * libnm,core: use NM_FLAGS_ANY() for MODEM_CAPS_3GPP()/MODEM_CAPS_3GPP2()Thomas Haller2022-01-292-6/+6
| | | | | | | | | | | | | | | | | | Macros should (where possible and sensible) behave function-like. That means for example, that they evaluate arguments only once, and use parentheses around code that expands, so that unexpected uses work correctly. The parentheses was missing. Instead, just use the NM_FLAGS_ANY() macro which gets this right.
| * libnm: add "Since" gtkdoc comment to @NM_DEVICE_MODEM_CAPABILITY_5GNRThomas Haller2022-01-291-1/+1
| |
| * libnm,core: add 5GNR device modem capabilityDaniele Palmas2022-01-293-4/+10
|/ | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1076
* release: bump version to 1.35.7 (development)1.35.7-devThomas Haller2022-01-282-2/+2
|
* libnm: merge branch 'th/libnm-dangling-property-2'Thomas Haller2022-01-282-2/+16
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1075
| * libnm: add code comments to NMClientThomas Haller2022-01-281-0/+13
| |
| * libnm/tests: enable check for dangling pointer in test_activate_virtual()Thomas Haller2022-01-281-2/+2
| |
| * libnm: fix dangling pointer in "o" properties when unregistering NMObjectThomas Haller2022-01-281-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When NMClient gets destroyed, it unrefs all NMObject. We need to unbreak cycles then, and the property getters must return NULL. In particular, for "o" type properties (NMLDBusPropertyO), this was not done correctly. For example, calling nm_device_get_active_connection() while/after destroying the NMClient can give a dangling pointer and assertion failure. This will also be covered by test_activate_virtual(). Probably a similar issue can happen, when a D-Bus object gets removed (without destroying NMClient altogether). The fix is that nml_dbus_property_o_clear() needs to clear "nmobj". That is correct, because the pointer is no longer valid and should not be there. And the unit test shows that in fact a pointer is left there, and clearing it fixes it. That was different from an earlier attempt to fix this (in commit 62b2aa85e875 ('Revert "libnm: fix dangling pointer in public API while destructing NMClient"')), where clearing the pointer at a different place broke things. That attempt was wrong, because nml_dbus_property_o_notify_changed() needs to be the one that sets/clears nmobj field during a regular update. But the case here is not a regular update, nml_dbus_property_o_clear() happens during unregister/cleanup, and then we need to clear the pointer. Fixes: ce0e898fb476 ('libnm: refactor caching of D-Bus objects in NMClient') https://bugzilla.redhat.com/show_bug.cgi?id=2039331 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/896 See-also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1064 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1075
* dhcp: fix crash accepting leases without addressesBeniamino Galvani2022-01-272-17/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For IPv6 the lease doesn't necessarily have an address. If the address is missing or the DHCP client doesn't implement accept(), we don't need to wait for the address in platform. From https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1066#note_1233210 : 0 0x00007ffff760f88c in __pthread_kill_implementation () at /lib64/libc.so.6 1 0x00007ffff75c26a6 in raise () at /lib64/libc.so.6 2 0x00007ffff75ac7d3 in abort () at /lib64/libc.so.6 3 0x00007ffff77c5d4c in g_assertion_message (domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>, message=<optimized out>) at ../glib/gtestutils.c:3223 4 0x00007ffff782645f in g_assertion_message_expr (domain=domain@entry=0x5555559e7c96 "nm", file=file@entry=0x5555559deac0 "src/core/dhcp/nm-dhcp-client.c", line=line@entry=609, func=func@entry=0x5555559e0090 <__func__.31> "l3_cfg_notify_cb", expr=expr@entry=0x5555559df5cf "lease_address") at ../glib/gtestutils.c:3249 5 0x00005555558b2866 in l3_cfg_notify_cb (l3cfg=0x555555c29790, notify_data=<optimized out>, self=0x555555e9a1b0) at src/core/dhcp/nm-dhcp-client.c:609 9 0x00007ffff791abe3 in <emit signal ??? on instance ???> (instance=instance@entry=0x555555c29790, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3553 6 0x00007ffff78fcc7f in g_closure_invoke (closure=0x555555ca3900, return_value=0x0, n_param_values=2, param_values=0x7fffffffd420, invocation_hint=0x7fffffffd3a0) at ../gobject/gclosure.c:830 7 0x00007ffff7919106 in signal_emit_unlocked_R (node=node@entry=0x555555bbadc0, detail=detail@entry=0, instance=instance@entry=0x555555c29790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd420) at ../gobject/gsignal.c:3742 8 0x00007ffff791a9ca in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd5f0) at ../gobject/gsignal.c:3497 10 0x000055555564c8a6 in _nm_l3cfg_emit_signal_notify (self=self@entry=0x555555c29790, notify_data=notify_data@entry=0x7fffffffdf30) at src/core/nm-l3cfg.c:576 11 0x000055555564ce77 in _nm_l3cfg_emit_signal_notify_simple (self=self@entry=0x555555c29790, notify_type=notify_type@entry=NM_L3_CONFIG_NOTIFY_TYPE_POST_COMMIT) at src/core/nm-l3cfg.c:585 12 0x0000555555656082 in _l3_commit (self=self@entry=0x555555c29790, commit_type=NM_L3_CFG_COMMIT_TYPE_UPDATE, commit_type@entry=NM_L3_CFG_COMMIT_TYPE_AUTO, is_idle=is_idle@entry=1) at src/core/nm-l3cfg.c:4201 13 0x0000555555656189 in _l3_commit_on_idle_cb (user_data=user_data@entry=0x555555c29790) at src/core/nm-l3cfg.c:2961 14 0x00007ffff77f847b in g_idle_dispatch (source=0x555555d65680, callback=0x55555565612c <_l3_commit_on_idle_cb>, user_data=0x555555c29790) at ../glib/gmain.c:5897 15 0x00007ffff77fc130 in g_main_dispatch (context=0x555555aa5020) at ../glib/gmain.c:3381 16 g_main_context_dispatch (context=0x555555aa5020) at ../glib/gmain.c:4099 17 0x00007ffff7851208 in g_main_context_iterate.constprop.0 (context=0x555555aa5020, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4175 18 0x00007ffff77fb853 in g_main_loop_run (loop=0x555555aa5970) at ../glib/gmain.c:4373 19 0x0000555555593c56 in main (argc=<optimized out>, argv=<optimized out>) at src/core/main.c:509 Fixes: e1648d0665a0 ('core: commit l3cd asynchronously on DHCP bound event') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1074
* supplicant: use nm_ref_string_reset_str() in _properties_changed_main()Thomas Haller2022-01-271-4/+1
|
* glib-aux/tests: add tests for nm_ref_string_equal_str()Thomas Haller2022-01-271-0/+8
|
* glib-aux/trival: add code comment to nm_ref_string_equal_str()Thomas Haller2022-01-271-0/+3
|
* glib-aux: fix nm_ref_string_equal_str()Beniamino Galvani2022-01-271-1/+1
| | | | | | | | | | | | Fix comparison with a NULL string. The only current caller is nm-supplicant-interface.c, and this bug causes a missing cleanup of the CurrentBSS property on disconnect. Fixes: ac8c3a711148 ('glib-aux: improve nm_ref_string_equals_str() to work for non-C-strings') https://bugzilla.redhat.com/show_bug.cgi?id=1983735 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1073
* man: mention "rd.znet_ifnames" option in `man nm-initrd-generator`Thomas Haller2022-01-261-0/+1
|
* dhcp: for systemd DHCPv6 client always explicitly set prefix-delegationThomas Haller2022-01-261-7/+11
| | | | | | | Beginning with [1], prefix delegation will be always enabled by default. Thus, always explicitly set it. [1] https://github.com/systemd/systemd/commit/01b4e90f32c72900f26f8f770cfb0e6d66c14706
* release: bump version to 1.35.6 (development)1.35.6-devThomas Haller2022-01-262-2/+2
|
* merge: branch 'bg/500vlans'Beniamino Galvani2022-01-267-157/+408
|\ | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1066 https://bugzilla.redhat.com/show_bug.cgi?id=2028849
| * dns: better track l3cd changesBeniamino Galvani2022-01-261-6/+19
| | | | | | | | | | | | | | | | | | | | | | Update DNS only when something relevant changes: - an old l3cd gets removed, without adding a new one - a new one is added without removing an old one - an old is removed and it differs (in routes and DNS) from the new added one
| * core: update hostname once at startupBeniamino Galvani2022-01-261-0/+1
| | | | | | | | | | | | | | | | | | NMPolicy stores the last hostname set in priv->cur_hostname and checks if it changed before notifying the DNS manager. _set_hostname() should be called one time early during startup so that the priv->cur_hostname gets initialized without triggering a DNS update.
| * core: support compare flags in nm_l3_config_data_cmp_full()Beniamino Galvani2022-01-262-80/+217
| |
| * core: defer DNS updates until the device enters the SECONDARIES stateBeniamino Galvani2022-01-261-1/+21
| | | | | | | | | | | | | | | | | | I see a significant performance increase with many parallel activations if DNS updates are deferred to the SECONDARIES state. Since there is no guarantee that device_l3cd_changed() is called again when the device becomes ACTIVATED, we need also to change device_state_changed().
| * core: commit l3cd asynchronously on DHCP bound eventBeniamino Galvani2022-01-263-70/+150
|/ | | | | | | | | | | | | | | | | | When a lease is obtained, currently NMDevice performs a synchronous commit of IP configuration and then accepts the lease. Instead, let NMDevice only schedule a async commit; when the DHCP client notices that the new address was committed it will automatically accept it and emit a new signal so that the device can succeed the activation. Sync commits should be avoided because a commit does of things which are outside the control of the caller (see the comment in nm_device_l3cfg_commit()). Furthermore, when there are many pending activations, async commits seem to help in reducing the CPU usage. While making the commit async, also move the responsibility of the accept() to NMDhcpClient.
* Revert "libnm: fix dangling pointer in public API while destructing NMClient"Thomas Haller2022-01-252-3/+2
| | | | | | | | This breaks test @nmcli_monitor. With this patch, `nmcli monitor` no longer prints "There's no primary connection". Need to investigate why. For now, revert the patch. This reverts commit 2afecaf908401296a2642fdd1d73a76b9c3fa11a.
* Merge branch 'ac/gsm' into 'main'Ana Cabral2022-01-252-2/+9
|\ | | | | | | | | core/wwan: Ensure correct conditions before signal emission See merge request NetworkManager/NetworkManager!1071
View Lorry Controller Status