Re: Network Manager enabling 802.11r - fast Transition
On Mon, Oct 24, 2022 at 12:52:48PM +0200, Shawn Adams via networkmanager-list
wrote:
> All,
>
> Perhaps I'm missing something, but do not see a UI option to enable 802.11r.
>
> I can edit the /etc/system/NetworkManager/ and manally set
> the key-mgmt:
>
> [wifi-security]
> key-mgmt=FT-EAP FT-EAP-SHA384
This is not a valid key-mgmt from NM point of view. When you restart
NM (or after, a "nmcli connection reload") you should see something like:
failed to load connection: invalid connection:
802-11-wireless-security.key-mgmt: 'ft-eap ft-eap-sha384' is not a valid value
for the property
in logs and the profile is not loaded. The valid values are those
listed in "man nm-settings".
key-mgmt
Key management used for the connection. One of "none" (WEP or no
password protection), "ieee8021x" (Dynamic WEP), "owe"
(Opportunistic Wireless Encryption), "wpa-psk" (WPA2 + WPA3
personal), "sae" (WPA3 personal only), "wpa-eap" (WPA2 + WPA3
enterprise) or "wpa-eap-suite-b-192" (WPA3 enterprise only).
> Then restart NM and this works (yes provided the driver supports, which it
> does).
>
> FYI - can set OKC via wpa_cli.
>
> However; when NM is restarted, the UI config tool shows the ESSID connection
> profile, but is missing
> the certificate selection, i need to reconfigure via the UI.
>
> am I missing a more elegant method of enabling 802.11r ?
Currently there isn't a way to explicitly enable or disable FT. NM
automatically enables FT when wpa_supplicant reports that the wireless
interface supports it. The detection is based on whether the
"Capabilities" D-Bus field of the wireless interface contains
"KeyMgmt=wpa-ft-psk".
If you increase NM logging level to trace and restart it, you should
see what capabilities are reported ('+' means supported):
[1666943325.0852] sup-iface[ad2675fb588f7c6b,2,wlan0]: interface
supported features: AP? FT+ SAE+ BIP+
And when connecting, you can see which configuration is passed to
wpa_supplicant:
[1666943444.7227] Config: added 'ssid' value 'test'
[1666943444.7227] Config: added 'key_mgmt' value 'WPA-EAP FT-EAP
FT-EAP-SHA384 WPA-EAP-SHA256'
[1666943444.7227] Config: added 'password' value ''
[1666943444.7227] Config: added 'eap' value 'PEAP'
...
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Preventing network scans once connected via libnm
On Mon, Oct 03, 2022 at 09:04:47PM +, Charles Lohr wrote:
> Thank you for the prompt and clear reply.
>
> Will BSSID locking interfere with explicit (controller-based) handoff for
> mesh networks? (Not regular roaming where the station would be responsible
> for selecting a new ap)
BSSID locking is relevant only when the interface is connected to a
network through NetworkManager. If the connection profile sets AP or
ad-hoc mode, BSSID locking is not necessary because background
scanning is already disabled. For other modes (infrastructure and
mesh), it's necessary to set the BSSID to avoid scanning:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.40.0/src/core/supplicant/nm-supplicant-config.c#L585-614
When the interface is not connected to a network via NM, the only way to
disable periodic scanning is to set the interface as unmanaged by
NetworkManager. See also:
https://mail.gnome.org/archives/networkmanager-list/2022-June/msg5.html
https://mail.gnome.org/archives/networkmanager-list/2022-July/msg1.html
> The lockout during our application running won't work for us because there
> are some processes running as root. But this isn't crucial.
Polkit rules are quite flexible and probably there is a way to achieve what you
want.
https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
Beniamino
> -Original Message-
> From: Beniamino Galvani
> Sent: Monday, October 3, 2022 1:13 AM
> To: Charles Lohr
> Cc: 'networkmanager-list@gnome.org'
> Subject: Re: Preventing network scans once connected via libnm
>
> On Sat, Oct 01, 2022 at 12:46:24AM +, Charles Lohr via
> networkmanager-list wrote:
> > In our application, we need to maintain connection to an AP and it needs to
> > stay low latency for a variety of reasons. Whenever networks are scanned,
> > for us they create an unacceptable level of latency (>50ms in many cases)
> > on the connection.
> >
> > Sometimes we stop NetworkManager from running with `pkill -STOP
> > NetworkManager` and `pkill -CONT NetworkManager` but, for a variety of
> > reasons this is disadvantageous.
> >
> > I've seen references to people online saying you can prevent scanning once
> > connected by specifying a BSSID, but I don't see how that can be done with
> > libnm.
> >
> > Currently we use the following, where path can be gotten from either a
> > scan or `nm_connection_get_path`
> >
> > ```
> > nm_client_activate_connection_async ( m_pClient, conn,
> > (NMDevice*)m_pDevice, sAccessPointPath.c_str(), nullptr, []( GObject*
> > pObj, GAsyncResult* res, gpointer pContext ) {...} ); ```
> >
> > What mechanism can we use to specify that a given path should lock it's
> > BSSID when using NetworkManager via libnm?
>
> Hi,
>
> to disable scanning, you can set the property NM_SETTING_WIRELESS_BSSID of
> the setting NMSettingWireless to the AP's BSSID when the connection profile
> is created. To get the AP's BSSID use nm_access_point_get_bssid().
>
> References:
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.40.0/examples/C/glib/add-connection-libnm.c#L44
> https://networkmanager.dev/docs/api/latest/nm-settings-dbus.html#id-1.2.9.4.48
> ("bssid property")
> https://networkmanager.dev/docs/libnm/latest/NMAccessPoint.html#nm-access-point-get-bssid
> https://fedoramagazine.org/using-python-and-networkmanager-to-control-the-network/
>
> > Second question: Are there any mechanisms we can use to lock out other
> > apps from requesting scans from NetworkManager? This solution would be
> > preferred for our application because scans have such a significant impact
> > on the system. Or is there a way to just outright disable all scanning via
> > NetworkManger for a period of time?
>
> If the feature is enabled at build time, NM can use polkit to authorize D-Bus
> requests. In particular, there is a "Wi-Fi scan"
> permission that grants access to scans. I think you can use polkit rules to
> restrict the access to a certain user or process; however, note that any
> process running as root bypasses polkit checks and is always authorized.
>
> References:
> https://networkmanager.dev/docs/libnm/latest/libnm-nm-dbus-interface.html#NMClientPermission
> https://networkmanager.dev/docs/api/latest/nmcli.html (nmcli general
> permissions)
>
> Beniamino
>
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Preventing network scans once connected via libnm
On Sat, Oct 01, 2022 at 12:46:24AM +, Charles Lohr via networkmanager-list
wrote:
> In our application, we need to maintain connection to an AP and it needs to
> stay low latency for a variety of reasons. Whenever networks are scanned,
> for us they create an unacceptable level of latency (>50ms in many cases) on
> the connection.
>
> Sometimes we stop NetworkManager from running with `pkill -STOP
> NetworkManager` and `pkill -CONT NetworkManager` but, for a variety of
> reasons this is disadvantageous.
>
> I've seen references to people online saying you can prevent scanning once
> connected by specifying a BSSID, but I don't see how that can be done with
> libnm.
>
> Currently we use the following, where path can be gotten from either a scan
> or `nm_connection_get_path`
>
> ```
> nm_client_activate_connection_async ( m_pClient, conn, (NMDevice*)m_pDevice,
> sAccessPointPath.c_str(), nullptr, []( GObject* pObj, GAsyncResult* res,
> gpointer pContext ) {...} );
> ```
>
> What mechanism can we use to specify that a given path should lock it's BSSID
> when using NetworkManager via libnm?
Hi,
to disable scanning, you can set the property
NM_SETTING_WIRELESS_BSSID of the setting NMSettingWireless to the AP's
BSSID when the connection profile is created. To get the AP's BSSID
use nm_access_point_get_bssid().
References:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.40.0/examples/C/glib/add-connection-libnm.c#L44
https://networkmanager.dev/docs/api/latest/nm-settings-dbus.html#id-1.2.9.4.48
("bssid property")
https://networkmanager.dev/docs/libnm/latest/NMAccessPoint.html#nm-access-point-get-bssid
https://fedoramagazine.org/using-python-and-networkmanager-to-control-the-network/
> Second question: Are there any mechanisms we can use to lock out other apps
> from requesting scans from NetworkManager? This solution would be preferred
> for our application because scans have such a significant impact on the
> system. Or is there a way to just outright disable all scanning via
> NetworkManger for a period of time?
If the feature is enabled at build time, NM can use polkit to
authorize D-Bus requests. In particular, there is a "Wi-Fi scan"
permission that grants access to scans. I think you can use polkit
rules to restrict the access to a certain user or process; however,
note that any process running as root bypasses polkit checks and is
always authorized.
References:
https://networkmanager.dev/docs/libnm/latest/libnm-nm-dbus-interface.html#NMClientPermission
https://networkmanager.dev/docs/api/latest/nmcli.html (nmcli general
permissions)
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling periodic scans
On Fri, Jul 01, 2022 at 02:12:45AM +0300, Slava Monich wrote: > Actually, this wasn't about connected interfaces. When the interface is > connected, AP roaming has to be supported, locking connection to BSSID of > the AP is not an option, there's no way to avoid active scans. > That's fine. > > What I had in mind was a scenario when the device running network manager > has more than one Wi-Fi interface, and those are not connected (but have to > be ready to be connected at any time). Passive scans produce lots of D-Bus > traffic, which creates serious load (I mean it, really serious load) on the > device. And yet, periodic scans on all those interfaces produce more or less > the same list of networks, needlessly wasting precious system resources. > > It seems to make every bit of sense to disable scans on all but one > disconnected Wi-Fi interface, and let the UI use the list of available APs > produced by that one single interface. And since no connection is involved > at this stage, it can't be a connection property, right? It's got to be an > org.freedesktop.NetworkManager.Device.Wireless property. Correct. > And yes, it means that this property is not going to be persistent but it > doesn't need to be, since it has to be updated every time when the system > state changes (e.g. an interface appears or disappears, gets connected or > disconnected). Which is fine since this scenario implies a separate service > choosing which interface will do the scanning, that logic is product > specific and out of scope. > > Am I missing something? I don't know others' opinion, but this seems a legitimate use case to me, and I'm in favor of adding such D-bus property to the Device.Wireless interface. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling periodic scans
On Sun, Jun 19, 2022 at 09:01:12PM +0300, Slava Monich wrote: > Hi! > > Are there any objections to adding e.g. BackgroundScanEnabled readwrite > property to org.freedesktop.NetworkManager.Device.Wireless D-Bus interface? > The idea is to allow to disable periodic background scans for those WiFi > interfaces which don't need it. There are use cases for that in the embedded > world. Hi, if the Wi-Fi connection profile is locked to a specific BSSID, that disables periodic scanning while connected. Is this a suitable solution for your use case? Or, what is the use case? If we want to make this behavior configurable, perhaps it should be in the connection profile and not on the device D-Bus object, so that the property can be changed persistently and it depends on the network. See also: https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/ Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Would Provision Domain Names be hard to implement in NM? (RFC 8801)
On Mon, May 30, 2022 at 01:14:51PM +0200, Petr Menšík via networkmanager-list
wrote:
> Hi,
>
> RFC 8801 [1] is standard tracks already. Would it be difficult to
> implement it in NM? I think it provides very nice way to make profiles
> on ethernet connections for example. Not sure if I can have multiple
> configurations switched automatically withou Radius used for port security.
Hi,
I have quickly read RFC 8801 and RFC 7756, and it's not clear to me
how the PvD model would fit in the NM picture.
> But this RFC allows specification of domains and prefixes used on given
> connection. That would be useful for VPN connected to work for example,
> but when I still want to reach some local resources. For example printer
> or local file storage, when I work from home. Unlike Radius it can work
> fine at home networks too. But it can use TLS for obtaining basic
> infromation, so those information can be secure at the same time.
From what I understood, the RFCs define the concept of PvDs
(provisioning domains) that contain related network configuration as
DNS servers, DNS domains, default gateways, etc. A PvD can be explicit
(provided to the client via e.g. a RA option), or implicit when a
client automatically creates a different PvD for each interface.
What is not clear to me is how to use that information. For PvD-aware
nodes, the recommendation is to use the received information
consistently (for example, use the DNS server from one PvD for the
domains of the same PvDs, etc.). Note that NM already does something
like that implicitly when using one of dns={dnsmasq,systemd-resolved}:
it queries a nameserver only on the interface that announced it, and
it routes queries according to the automatically-received domains.
The RFC also talks about PvD-aware applications that can choose the
PvD, but I don't think infrastructure for that exists outside NM.
> It requires some kind of autoconfiguration of IP addresses. But I would
> like to have possible LLMNR or mDNS configuration configured just on
> some kind of networks. Could provision domain allow profiles in NM,
> which would be autoconfigured via network? It would be great for laptops
> connected via ethernet.
I don't know, there seems no mention of LLMNR or mDNS in the RFC. I
see that it allows the nodes to fetch a JSON that contains more
information, and that probably can be extended to do everything.
While I agree that in theory this feature would be nice, I think the
use cases are not well defined yet and it seems that implementing this
in NM will require a significant effort.
Does any existing DHCP/RA server implement the needed options? Do you
know of any existing real deployment of this feature?
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PSK+SAE when creating an Access Point
On Mon, Apr 04, 2022 at 11:08:26AM +0200, Beniamino Galvani wrote: > On Tue, Mar 22, 2022 at 11:52:00AM +0100, Alfonso Sanchez-Beato via > networkmanager-list wrote: > > Hi there! > > > > I have been using NetworkManager 1.36.2 to create an Access Point, but I am > > having some problems. Only devices that support WPA3 are able to connect to > > the AP. Looking at the history, I see that > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/f5d78c2d289c9e4a4c247d2520c7c3e2baf537c8 > > introduced a change that configures wpa_supplicant to be able to connect to > > any of WPA, WPA2 or WPA3 and choose the best candidate. However, it looks > > like this is breaking the hotspot case, at least for me - when I revert the > > change I am able to connect again from WPA2-only devices. > > > > I have seen these problems on > > * An intel NUC with Intel wifi driver > > * On a VM, when loading mac80211_hwsim with two radios (one for hotspot, > > the other for connecting to it) > > Hi, I can reproduce the problem with mac80211_hwsim. The root cause is > that NM passes both SAE and FT-SAE as key-mgmt to > wpa_supplicant. wpa_supplicant currently doesn't support FT in AP > mode, but still advertises FT-SAEit to the STA, leading to a key > derivation mismatch. > > This patch works for me: > > http://lists.infradead.org/pipermail/hostap/2022-April/040352.html > > Arguably, we could also fix this in NM by not passing FT-SAE in AP > mode; however I prefer that the fix is done in wpa_supplicant so that > in the future, when FT support is added to AP mode it will work > automatically with NM. I changed my mind. FT requires special configuration in the AP and so it doesn't make sense that NM automatically enables because it would be useless and in some cases (FT-SAE) harmful. In the end, I did this patch to disable FT when NM configures the supplicant in AP mode: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1184 Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PSK+SAE when creating an Access Point
On Tue, Mar 22, 2022 at 11:52:00AM +0100, Alfonso Sanchez-Beato via networkmanager-list wrote: > Hi there! > > I have been using NetworkManager 1.36.2 to create an Access Point, but I am > having some problems. Only devices that support WPA3 are able to connect to > the AP. Looking at the history, I see that > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/f5d78c2d289c9e4a4c247d2520c7c3e2baf537c8 > introduced a change that configures wpa_supplicant to be able to connect to > any of WPA, WPA2 or WPA3 and choose the best candidate. However, it looks > like this is breaking the hotspot case, at least for me - when I revert the > change I am able to connect again from WPA2-only devices. > > I have seen these problems on > * An intel NUC with Intel wifi driver > * On a VM, when loading mac80211_hwsim with two radios (one for hotspot, > the other for connecting to it) Hi, I can reproduce the problem with mac80211_hwsim. The root cause is that NM passes both SAE and FT-SAE as key-mgmt to wpa_supplicant. wpa_supplicant currently doesn't support FT in AP mode, but still advertises FT-SAEit to the STA, leading to a key derivation mismatch. This patch works for me: http://lists.infradead.org/pipermail/hostap/2022-April/040352.html Arguably, we could also fix this in NM by not passing FT-SAE in AP mode; however I prefer that the fix is done in wpa_supplicant so that in the future, when FT support is added to AP mode it will work automatically with NM. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.34.0 released
Hi everybody, On behalf of the NetworkManager community, I am happy to announce a new release of NetworkManager: 1.34.0. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/9133a30c9deb3a003a20b09a617a25b07ada18ae Find the tarball at our usual location: https://download.gnome.org/sources/NetworkManager/1.34/ https://download.gnome.org/sources/NetworkManager/1.34/NetworkManager-1.34.0.tar.xz sha256: 819795d0899076204f5672421a58f1b1d9e393536ee87bb844b911e6243bf0bd sha512: f00a75abc26c4a85e23565f9ce103a8a0675b0820df439e06749057202cf01823273ffd0b1d80afa31d7b50cf2cbdce041d781e2dd70c49ee68946b45c2b0ac9 To see what's new check the NEWS file: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.34.0/NEWS or https://networkmanager.dev/blog/networkmanager-1-34/ Thanks to everybody who contributed to this release with patches and translations: Ana Cabral, Andrew Zaborowski, Beniamino Galvani, Benjamin Berg, Björn Lindqvist, Christian Glombek, echengqi, Fernando Fernández Mancera, Frederic Martinsons, gaoxingwang, Gris Ge, Harald van Dijk, Javier Jardón, Javier Sánchez Parra, Jonas Kümmerlin, josef radinger, Julian Wiedmann, Lubomir Rintel, Lukasz Majewski, Maxine Aubrey, Michael Catanzaro, Nacho Barrientos, Philip Withnall, Rain-lk, Robin Ebert, Sibo Dong, Simon McVittie, Thomas Haller, Vojtech Bubela, wangce, Wen Liang, xiangnian, Yu Watanabe. B. signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ODP: ODP: ODP: ODP: Ampak AP6356S with WPA3
On Mon, Oct 04, 2021 at 09:36:29PM +, Piotr Lobacz wrote:
> Hi Beniamino,
> i have added printf's in this patched file for wpa_supplicant like that:
>
> --- a/wpa_supplicant/dbus/dbus_new_handlers.c 2021-10-04 22:50:45.114545070
> +0200
> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c 2021-10-04 22:54:14.478466782
> +0200
> @@ -2790,10 +2790,18 @@
> goto nomem;
> #endif /* CONFIG_WPS */
>
> + printf("before if capa.key_mgmt SAE !!!\n");
> #ifdef CONFIG_SAE
> if ((capa.key_mgmt & WPA_DRIVER_CAPA_KEY_MGMT_SAE) &&
> !wpa_dbus_dict_string_array_add_element(_array, "sae"))
> + {
> + printf("got into if statement !\n");
> goto nomem;
> + }
> + else
> + {
> + printf("got into else statement !!!\n");
> + }
> #endif /* CONFIG_SAE */
>
> if (!wpa_dbus_dict_end_string_array(_dict,
Hi,
probably capa.key_mgmt doesn't contain
WPA_DRIVER_CAPA_KEY_MGMT_SAE. It's probably shown somewhere in
supplicant logs, but to be sure can you please check with:
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -2880,6 +2880,8 @@ dbus_bool_t wpas_dbus_getter_capabilities(
#endif /* CONFIG_WPS */
#ifdef CONFIG_SAE
+ printf("capa.key_mgmt: %08x, (sae: %d)\n", capa.key_mgmt,
+ !!(capa.key_mgmt & WPA_DRIVER_CAPA_KEY_MGMT_SAE));
if ((capa.key_mgmt & WPA_DRIVER_CAPA_KEY_MGMT_SAE) &&
!wpa_dbus_dict_string_array_add_element(_array, "sae"))
goto nomem;
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ODP: ODP: ODP: Ampak AP6356S with WPA3
On Mon, Oct 04, 2021 at 08:44:43AM +, Piotr Lobacz wrote: > Hi Benjamino, > after adding patch to wpa_supplicant, unfortunatelly i'm still getting: > > Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK' > > on Hotspot creation. Hi, what's the output of this command? busctl -j get-property fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1/Interfaces/1 fi.w1.wpa_supplicant1.Interface Capabilities (replace /1 with the actual index on D-Bus of the interface, if necessary). You should see "sae" in the "KeyMgmt" array. If not, either the patch is not working or the driver is not properly exporting the capability. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ODP: ODP: Ampak AP6356S with WPA3
On Sun, Oct 03, 2021 at 10:04:24PM +, Piotr Lobacz wrote: > Hi again Beniamino, > this problem also exsists on Hotspot... and I'm afraid that it hasn't been > solved in there yet... If hotspot is being created like this: > > nmcli dev wifi hotspot ifname wlan0_ap ssid test password "test1234" > > the default security is set to WPA2 and if i switch it to WPA3 then my client > device is being rejected because of: > > ieee80211 phy0: brcmf_cfg80211_external_auth: External authentication failed: > status=1 > > I'm pretty sure that this is the same error as previous one. Hi Piotr, since [1], NetworkManager also enables WPA3 (SAE) when the connection is configured with key_mgmt=wpa-psk (both in STA and AP mode). When adding SAE to the key_mgmt list, NM needs first to know if wpa_supplicant supports it, otherwise wpa_supplicant would fail to start. NM looks at the "Capabilities" D-Bus property of the Interface object to detect SAE support [2]. wpa_supplicant started to export the value in [3], which is not in the 2.9 release. I think what's happening is that NM passes a configuration to wpa_supplicant without SAE because the supplicant doesn't export the capability. Can you please try with that wpa_supplicant commit? With the commit applied you should see in NM logs something similar to: Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE' ^^ Beniamino [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/f5d78c2d289c9e4a4c247d2520c7c3e2baf537c8 [2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/f7f4db156ffdd0792dbfcddde3ba60a7ee561dcc [3] https://w1.fi/cgit/hostap/commit/?id=7a9c36722511ce4df88b76cceceb241d6c6a151e signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ODP: Ampak AP6356S with WPA3
On Sat, Oct 02, 2021 at 11:20:19PM +, Piotr Lobacz wrote: > One more thing, setting the logging level to trace in NetworkManager causes > also problems with the connection... , but i have seen one difference in > establishing the connection using Edit a connection and Activate a > connection. The difference was in config, when i was using Edit... from > nmtui there was no auth_alg parameter. In other case it was and it was > assigned to OPEN. Hi, this problem should be fixed by commit https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/109d561bed8341b36111e527185513dafd856c0d Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: System no longer connects to wifi network after router firmware upgrade, how to troubleshoot more?
On Sat, Sep 04, 2021 at 08:52:41AM -0700, Alan Tu via networkmanager-list wrote: > Hello, A router firmware upgrade has caused my network-manager system not to > be able to connect to the fastest wifi access point. I'd like to know how to > troubleshoot exactly what is going on so I can provide feedback to either the > NIC driver maintainers, the software stack, the Asus firmware people, etc. > > I'm running Debian testing (v11 + updates.) network-manager is at version > 1.30.6-1. The NIC is an Asus USB dongle running the rtl8814au module from > aircrack-ng. The access point is an Asus RT-AX88u router (irony, I know). > > This system was connected to a wifi network called wln. Because of old smart > speakers, I had to split my network. wln runs on the 5 GHz band and > "wln_legacy" runs on the 2.4 GHz band. The server was connected to the wln > SSID. > > I upgraded the Asus router firmware, a mistake in hindsight. My Windows > tablet and my iDevices are talking with the 5 GHz wln network just fine as > before. But network-manager (or something underneath that) is not able to > connect. > > The wln network is still visible: > $ nmcli dev wifi list > ... > * 04:D9:F5:FA:D4:F8 wln_legacy Infra 7 540 Mbit/s 87 ▂▄▆█ > WPA2 > 04:D9:F5:FA:D4:FC wln Infra 52540 Mbit/s 24 > ▂___ WPA2 > > But when trying to bring the wln connection up, I see messages in the system > journal like this: > > Sep 03 12:46:11 raptor NetworkManager[555]: [1630698371.4330] device > (wlx1831bf53a3a2): Activation: starting connection 'wln' > (afc892b2-7e5f-45a5-9858-16a155bc8bb3) > Sep 03 12:46:11 raptor NetworkManager[555]: [1630698371.4384] device > (wlx1831bf53a3a2): state change: disconnected -> prepare (reason 'none', > sys-iface-state: 'managed') > Sep 03 12:46:11 raptor NetworkManager[555]: [1630698371.5565] device > (wlx1831bf53a3a2): state change: prepare -> config (reason 'none', > sys-iface-state: 'managed') > Sep 03 12:46:11 raptor NetworkManager[555]: [1630698371.5575] device > (wlx1831bf53a3a2): state change: config -> need-auth (reason 'none', > sys-iface-state: 'managed') > Sep 03 12:46:11 raptor NetworkManager[555]: [1630698371.5637] device > (wlx1831bf53a3a2): state change: prepare -> config (reason 'none', > sys-iface-state: 'managed') > Sep 03 12:46:11 raptor NetworkManager[555]: [1630698371.5751] device > (wlx1831bf53a3a2): supplicant interface state: disconnected -> scanning > Sep 03 12:46:37 raptor wpa_supplicant[564]: wlx1831bf53a3a2: Reject scan > trigger since one is already pending > Sep 03 12:46:37 raptor NetworkManager[555]: [1630698397.1961] device > (wlx1831bf53a3a2): state change: config -> failed (reason 'ssid-not-found', > sys-iface-state: 'managed') > > How can I gather more debug information, to better articulate what is going > on? I'd appreciate some pointers! Thank you in advance. In cases like this, more verbose NM and wpa_supplicant logs are helpful. Increase NM logging level by setting "level=TRACE" in the [logging] section of NetworkManager.conf. For wpa_supplicant, add '-ddd' to the command line argument. Both changes require a restart of the daemon. Since those logs can be quite verbose, if you are using systemd-journal you should probably disable rate-limiting by setting e.g. "RateLimitBurst=0" in /etc/systemd/journald.conf. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Number of static IPv6 DNS servers limited to 3
On Thu, Sep 09, 2021 at 04:42:45PM +0200, Anders Blomdell wrote: > Even thogh the 'ipv6 setting' of 'nm-settings-dbus(5)' doesn't mention this > limitation. > The number of IPv4 DNS server seems to be limited to 10 DNS servers. > > Is this by design? In previous versions of NM the ifcfg-rh configuration plugin could only handle 10 DNS servers. This limit was raised here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/00f63074d6200badb5193b69c60bd211d7a743f3 This patch is not yet in any released version of NM. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PPP over ATM support
On Tue, Jun 22, 2021 at 04:58:12PM +0200, Denis Prost via networkmanager-list wrote: > Hi everyone, > > I'm connecting to the internet through an ADSL speedtouch USB modem which > uses PPP over ATM (pppoa). > > [...] > > Is pppoa supposed to be supported by NetworkManager ? If yes, how can I add > a pppoa connection ? Try something like: nmcli connection add type adsl username myuser password mypass protocol pppoa See 'man nmcli' and 'man nm-settings' for more details. That said, ADSL support in NM didn't have much development and testing in the last years and so I'm not sure if it still works well. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Understanding IPv6-PD over PPPoE
On Wed, Jun 16, 2021 at 12:21:22PM +0100, Steve Hill wrote: > On 16/06/2021 11:44, Bjørn Mork wrote: > > > Not at all. Assigning a global address to lo (loopback) is perfectly > > fine. > > Can an address from PD be automatically assigned to lo by NetworkManager? Currently, no. I think assigning the PD to the loopback interface is not different from assigning it to a dummy interface, e.g.: nmcli connection add type dummy ifname dummy1 \ ipv4.method disabled ipv6.method shared The only problem is that now you have 2 connections. If they activate automatically at boot, no problem. Otherwise you need to remember to activate the dummy when you bring up the pppoe; probably you can achieve that using dispatcher scripts. Beniamino > > No need to assign an address to a link unless you want to assign > > a prefix to it. > > Having the address on the "correct" NIC makes address selection work > properly where you have multiple connections. > > > And you obviously don't want to do that for the link > > you received the IA_PD from, which is why it isn't allowed > You don't want to send router advertisements for the prefix on that link, > but assigning a /128 address, which would be automatically used for outgoing > connections being made through that NIC, should be fine. signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Understanding IPv6-PD over PPPoE
On Wed, Jun 16, 2021 at 09:28:16PM +0200, Marc Haber wrote: > On Wed, Jun 16, 2021 at 01:36:23PM +0200, Bjørn Mork wrote: > > Marc Haber writes: > > > Unfortunately, it is pretty hard in Germany to get a dedicated VDSL > > > modem so that you can do the PPPoE yourself, so I can't comment about > > > the exchanges that go on on the wire. > > > > You can't use any VDSL modem, or bridge the one you have? > > Modern Fritzboxes cannot be bridged any more, at least the ones that > also do SIP, since one would lose the phone features of the box. One possibility is to use a separate router (or Linux machine) connected to the LAN port of the modem and use PPPoE pass-through, if the Fritzbox supports it and the ISP allows multiple PPPoE sessions. I use this solution with the VDSL gateway provided by Telecom Italia. Beniamino > And > "any VDSL" modem is hard to find on the market, and if it is found, it > costs > 100 Euros, way more than a Fritzbox. > > I have not yet been this curious. > > Greetings > Marc signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Understanding IPv6-PD over PPPoE
On Wed, Jun 16, 2021 at 11:43:36AM +0300, Andrei Borzenkov wrote: > It is explicitly prohibited to assign any IA_PD prefix to the same > interface via which this was obtained. > > the requesting router MUST >NOT assign any delegated prefixes or subnets from the delegated >prefix(es) to the link through which it received the DHCP message >from the delegating router. You are right, RFC 3633 forbids it. However, if I understand correctly this approach is the one mentioned in [1], which refers to an expired IETF draft [2] saying: As stated in [RFC 3633], "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which is received the DHCP message from the delegating router", however the approach described in this document may still be useful in other DHCPv6 scenarios or non-DHCPv6 scenarios. Moreover, [RFC 3769] has no explicit requirement that avoids the approach described in this document. Furthermore, this has been tested in DHCPv6-PD implementations and worked well, so we must say that it may be implementation-dependent. >From [1], it seems that some ISPs are using this method. It would be interesting to research what e.g OpenWRT or other OSes do. Beniamino [1] https://www.ripe.net/publications/docs/ripe-690#4-1-4---64-prefix-out-of-the-ipv6-prefix-assigned-to-the-end-user [2] https://datatracker.ietf.org/doc/html/draft-palet-v6ops-point2point-01 signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Understanding IPv6-PD over PPPoE
On Tue, Jun 15, 2021 at 03:44:47PM +0100, Steve Hill via networkmanager-list wrote: > > I'm trying to get to grips with IPv6-PD over PPPoE. > > I'm on CentOS 8 (NetworkManager 1.30) and have main.dhcp=dhclient. My PPPoE > connection is set to ipv6.method=auto. > > With no NICs set to ipv6.manual=shared, I can see from a traffic dump that: > > - PPP link comes up and assigns IPv4 through LCP. > - I send an IPv6 router solicitation to my ISP. > - ISP responds with a router advertisement, which has the "managed address > configuration" and "other configuration" flags set. > - I send DHCPv6 Solicit with an IA_NA option. > - ISP responds with a DHCPv6 Advertise, which does NOT contain an IPv6 > address. > > I end up with an IPv6 default route pointing at the PPP interface, but no > public IPv6. IPv6 traffic from me to a public address ends up with my > link-local address as the source, which is obviously broken. > > > Conversely, with one or more NICs set to ipv6.method=shared (even if its > only a dummy NIC), I get: > > - PPP link comes up and assigns IPv4 through LCP. > - I send an IPv6 router solicitation to my ISP. > - ISP responds with a router advertisement, which has the "managed address > configuration" and "other configuration" flags set. > - I send DHCPv6 Solicit with IA_NA and IA_PD options. > - ISP responds with a DHCPv6 Advertise, which does NOT contain an IPv6 > address, but does contain my /48 public prefix. > > Again, the PPP NIC ends up with no public address, but now the "shared" NIC > gets a public v6 address. IPv6 traffic from me to a public address ends up > with the "ipv6.method=shared" NIC's address as the source, as this is the > only public v6 address available. > > > Is my ISP behaving in a broken way, by not assigning me an address in > response to IA_NA, or is it standard behaviour for ISPs to only respond to > IA_PD requests? > > It feels as though NetworkManager should always be making both IA_NA and > IA_PD requests and, if it didn't receive an IA_NA response from the ISP, it > should assign an address from the delegated prefix to the PPP interface. > This would prevent the situation where a machine with no > "ipv6.method=shared" NICs ends up with no public v6 address at all. > > > Any insight would be appreciated - many thanks. :) Hi, as you have seen, currently NM only requests a prefix delegation when there is an other interface in IPv6 shared mode. The IPv6 address on the PPP interface itself can only be obtained via SLAAC or DHCPv6(IA_NA), not via DHCPv6(IA_PD). I'm not sure how the latter is common; to support it, NM would need to always request a prefix delegation (even without another interface in shared mode) or, better, to have a new option to make this behavior configurable (for example, "ipv6.dhcp-request-pd=yes|no|auto"). Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn.conf working on the CLI and with systemd but not with NM: wrong IPv6 setting when configuring the tun interface?
On Thu, Jun 03, 2021 at 07:17:31AM +, Samuel Le Thiec via networkmanager-list wrote: Hi, > For a moment I thought that Network Manager may be assuming a point-to-point > topology for > the VPN instead of the "topology subnet" as specified in the server.conf, so > I did try to > 'push "topology subnet"' to the clients, but it didn't help: without the > 'push "route-ipv6 > .."' above, the client is still missing the route to the subnet. Right, 'topology' has no effect for IPv6. > > I can totally live with that, but is it the expected behaviour? If so, why > > does it > > differ from starting openvpn manually from the cli or even as a systemd > > openvpn-client@.service? It's not expected. I think the NetworkManager OpenVPN plugin parses the IPv6 configuration incorrectly. If the server pushes, for example: ifconfig-ipv6 2001:db8:f00:bebe::1003/64 2001:db8:f00:bebe::1 NetworkManager considers the first argument as the subnet and the second as the peer, and so it does something equivalent to: ip addr add dev tun0 2001:db8:f00:bebe::1003/64 peer 2001:db8:f00:bebe::1 which appears in the "ip -6 addr" output as: inet6 2001:db8:f00:bebe::1003 peer 2001:db8:f00:bebe::1/128 scope global valid_lft forever preferred_lft forever Instead, according to 'man openvpn', NM should simply add address "2001:db8:f00:bebe::1003/64" and use the second argument as a fallback gateway for the routes specified by '--route-ipv6': --ifconfig-ipv6 ipv6addr/bits ipv6remote configure IPv6 address ipv6addr/bits on the ``tun'' device. The second parameter is used as route target for --route-ipv6 if no gateway is specified. --route-ipv6 ipv6addr/bits [gateway] [metric] setup IPv6 routing in the system to send the specified IPv6 net- work into OpenVPN's ``tun''. The gateway parameter is only used for IPv6 routes across ``tap'' devices, and if missing, the ``ipv6remote'' field from --ifconfig-ipv6 is used. I have opened an issue for this [1] and I will prepare a patch for it. [1] https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/71 Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 1.20.4 and wpa_supplicant v2.9
On Thu, May 20, 2021 at 02:07:08PM +0200, Juan A. Rubio via networkmanager-list wrote: > Hello, > > I'm using NetworkManager version 1.20.4 on a device with a > Buildroot-based custom Linux distribution. The version of > wpa_supplicant is 2.9 and I've noticed that this version of supplicant > has lost the -u flag. If the '-u' flag is not recognized, wpa_supplicant was compiled without the CONFIG_CTRL_IFACE_DBUS_NEW option. You have to enable the option and rebuild wpa_supplicant. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mac andom does not work with wl driver
On Mon, May 10, 2021 at 01:32:59AM +0100, Bhasker C V via networkmanager-list wrote: > Hi, > > My wifi works (thanks for bwtnguy who pointed me to the issue) > However when I turn on > wifi.cloned-mac-address=stable > The NM does not connect to wifi anymore. > > My driver is wl. I use it with BCM4331 chip wifi card. > debian bullseye (NetworkManager==1.30.0 wpa_supplicant==v2.9) > Is this a known issue? Is there a fix for this ? Hi, this is a known issue, the Broadcom wl driver doesn't work well if the MAC is changed. Unfortunately the driver is closed and so only Broadcom can fix this problem. According to this [1] the 'b43' open source driver supports BCM4331. You could try if it works better. [1] https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: AccessPoint 5GHz DFS Channel Radar Detection Failure
On Wed, May 05, 2021 at 09:16:44AM +, Stärk Nadja wrote: > Hello, > > I'm working with NetworkManager v1.22.8 and face some issues with my 5 GHz > access point. > > I need to create it on DFS channel 100 and when a radar event is detected the > channel should be switched. > > Debug output of wpa_supplicant is enabled. > If I send a radar event through the debugfs to channel 100 now, I can see > that it was received by wpa_supplicant: > > nl80211: Event message available > > nl80211: Drv Event 94 (NL80211_CMD_RADAR_DETECT) received for p2p-dev-wlan0 > > nl80211: DFS event on freq 5500 MHz, ht: 1, offset: 0, width: 1, cf1: > 5500MHz, cf2: 0MHz > > p2p-dev-wlan0: Event DFS_RADAR_DETECTED (42) received Hi, the event is detected on p2p-dev-wlan0, which is a P2P interface; probably it should be on wlan0 instead. How do you simulate the event? > But the channel is not switched. > > > I made some debugging in wpa_supplicant (v2.9) and figured out that the > function wpas_ap_event_dfs_radar_detected in ap.c instantly returned because > the wpa_s->ap_iface and the wpa_s->ifmsh is empty. > > > > Is the NetworkManager able to handle a fully working 5 GHz access point? Do I > just need to add some extra configurations? Yes, I think it should if you set property 'wifi.band' to 'a'. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: I'd like to use the upstream DHCP server when using network sharing.
On Tue, Jan 26, 2021 at 07:31:04PM +, Vallevand, Mark K wrote: > I'll try to explain. > > I have three interfaces. I'll call them eth0, eth1 and wlan0. > Normally, we create a bridge, br0, and enslave eth0 and eth1. We assign an > IP to br0 (DHCP) and it can access devices connected to eth0 and eth1. > Those devices also can access each other, too. A DHCP server is upstream on > eth0. > Now, we want to use wlan0 instead of eth0. So, we create br0 and only > enslave eth1. Br0 is set to DHCP. > Wlan0 connects to a NAT/PAT access point with WPA2. It serves DHCP. > Everything works as expected. It gets an address from the access point DHCP > pool. > Before sharing, we add a config file in > /etc/NetworkManager/dnsmasq-shared.d/. There is only one setting in the > file. "interface=br0" This forces NetworkManager's dnsmasq to only listen > on br0. This prevents inference with other dnsmasq instances that we are > running. > We also assign an ipv4.addresses to br0 the br0 connection, so the DHCP pool > range will be determined. > We enable sharing on br0. There is some magic that happens here. I haven't > looked at the code too much. When br0 is shared, what actually happens? When sharing is enabled on br0, NM starts dnsmasq to serve DHCP and DNS requests on the interface. It also enables NAT for the traffic going out of the interface. > Anyway, NetworkManager seems to use wlan0 without any configuration by us. NM only enables NAT for traffic originated from the br0 subnet. Then the kernel uses the routing table to determine where packets go. > Devices behind eth1 get addresses from the correct pool and can access > devices on the other side of the access point. > That's a lot of explanation. Maybe we are thinking of this backwards. > Should we share wlan0? Suggestions are welcome. No, this sounds right. > We'd like to convince NetworkManager's dnsmasq to forward or relay or ignore > DHCP requests so that they are handled by the DHCP server on the access > point. Suggestions are welcome. You would need to put the wifi interface and eth1 under the bridge, but as said previously wifi interfaces can't be used as client in a bridge. > Finally, we noticed that traffic originating at br0, say, ping -I br0 > x.x.x.x, where x.x.x.x is on the other side of access point, does not work. > Traffic the other way from br0 to devices behind eth1 will work. Sorry, I don't know why. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: I'd like to use the upstream DHCP server when using network sharing.
On Tue, Jan 26, 2021 at 01:58:53PM +, Vallevand, Mark K wrote: > Actually, I am using a bridge. It is currently between two NICs. > We removed the 'upstream' NIC from the bridge and then enabled > NetworkManager interface sharing on the bridge. > NetworkManager selects the Wi-Fi connection and creates all the plumbing and > it works. What does "selects" mean here? Sorry, I didn't understand the configuration scenario. Do you want to share the Wi-Fi connectivity to the bridge, or the other way around? How is the Wi-Fi connection configured (DHCP, static, no addressing)? Where do you have the default route? > There are some issues. > The first on that list is that we'd like to convince the dnsmasq started by > NetworkManager to proxy or forward DHCP request to the Wi-Fi connection. NetworkManager doesn't support that directly, but perhaps you can add custom configuration for dnsmasq in /etc/NetworkManager/dnsmasq-shared.d/ . Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: I'd like to use the upstream DHCP server when using network sharing.
On Sun, Jan 17, 2021 at 07:55:53PM +, Vallevand, Mark K via networkmanager-list wrote: > I'd like to use the upstream DHCP server when using network sharing. > > Is this possible? No, connection sharing starts its own DHCP server on the "downstream" interface (the one with ipv4.method=shared). If you need only to pass frames between two interfaces, probably you can use a bridge instead... > I'm sharing an interface and the Wi-Fi connects to either a > home/small-office router which serves DHCP, or it connects to an access > point which passed DHCP requests to a corporate server. however, note that a Wi-Fi client interface usually doesn't work when it is under a bridge. So I think your only option (if I understood well what you want to do), is connection sharing, which creates a different subnet with DHCP on the downstream interface and enables NAT. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: cannot connect rtl8192fs to wireless network using NetworkManager with wpa_supplicant
On Sun, Jan 24, 2021 at 02:32:01PM +, Piotr Lobacz wrote: > i am struggling for a week to connect via NM together with > wpa_supplicant using systemd on buildroot. I have compiled > wpa_supplicant with dbus support. Before that i tried to use only > NM, but the nmcli was saying that the wlan0 interface was > unavailable. I was unable even to scan network using nmcli, but > iwlist wlan0 scan command was working just great. More over if i use > only wpa_supplicant configuration file with this command: > [...] > There is one more thing. This rtl8192fs driver needs private > parameters to work. Before i call wpa_supplicant command i need to > call this 4 commands: > [...] > But the connection isn't being established. I have attached logs > from wpa_supplicant and NetworkManager. > Btw. i have also tried to establish connection setting this iwpriv > parameters on wlan0 interface but for some reason these are not > working for wpa_supplicant/NetworkManager. I was wondering if NM > somehow passes it's own configuration to the interface? If yes how > can make some modifications? Yes, NetworkManager passes its own configuration to wpa_supplicant via D-Bus. You should be able to see the configuration in NM logs; on my machine for example I see: NetworkManager[1645]: [1611663864.0215] Config: added 'ssid' value 'home' NetworkManager[1645]: [1611663864.0215] Config: added 'scan_ssid' value '1' NetworkManager[1645]: [1611663864.0215] Config: added 'bgscan' value 'simple:30:-70:86400' NetworkManager[1645]: [1611663864.0215] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK' NetworkManager[1645]: [1611663864.0215] Config: added 'auth_alg' value 'OPEN' NetworkManager[1645]: [1611663864.0215] Config: added 'psk' value '' You could try to see if the same configuration works with wpa_supplicant alone. Regarding iwpriv parameters, NM doesn't support them. But if you set them manually before connecting with NM, I guess they should work. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager does not verify server certificate name on EAP-TLS WIFI connections
On Tue, Jan 26, 2021 at 01:23:46PM +0100, IB Development Team wrote: > > output I can see one conn try with subject matching failure and then next > attempt that succeeded (no conn config file changed between): > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: Trying to associate with > 11:11:11:11:11:11 (SSID='myssid' freq=2437 MHz) > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: Associated with > 11:11:11:11:11:11 > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-EAP-STARTED EAP > authentication started > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: > CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13 > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-EAP-METHOD EAP > vendor 0 method 13 (TLS) selected > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-EAP-PEER-CERT > depth=2 subject='' hash=[...] > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-EAP-PEER-CERT > depth=1 subject='' hash=[...] > Jan 26 12:28:34 mycomp wpa_supplicant[937]: TLS: Subject '/CN=myssid' did not > match with 'wrongdomain' > Jan 26 12:28:34 mycomp wpa_supplicant[937]: wlan0: > CTRL-EVENT-EAP-TLS-CERT-ERROR reason=5 depth=0 subject='/CN=myssid' > err='Subject mismatch' > Jan 26 12:28:34 mycomp wpa_supplicant[937]: SSL: SSL3 alert: write (local > SSL3 detected an error):fatal:internal error > Jan 26 12:28:34 mycomp wpa_supplicant[937]: OpenSSL: openssl_handshake - > SSL_connect error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed > Jan 26 12:28:35 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-EAP-FAILURE EAP > authentication failed > Jan 26 12:28:35 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-DISCONNECTED > bssid=11:11:11:11:11:11 reason=23 > Jan 26 12:28:35 mycomp wpa_supplicant[937]: wlan0: > CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="myssid" auth_failures=1 duration=10 > reason=AUTH_FAILED > Jan 26 12:28:35 mycomp wpa_supplicant[937]: dbus: wpa_dbus_property_changed: > no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/5 > Jan 26 12:28:48 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-SSID-REENABLED > id=1 ssid="myssid" > Jan 26 12:28:48 mycomp wpa_supplicant[937]: wlan0: SME: Trying to > authenticate with 11:11:11:11:11:11 (SSID='myssid' freq=2437 MHz) > Jan 26 12:28:48 mycomp wpa_supplicant[937]: wlan0: Trying to associate with > 11:11:11:11:11:11 (SSID='myssid' freq=2437 MHz) > Jan 26 12:28:48 mycomp wpa_supplicant[937]: wlan0: Associated with > 11:11:11:11:11:11 > Jan 26 12:28:48 mycomp wpa_supplicant[937]: wlan0: > CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 > Jan 26 12:28:48 mycomp wpa_supplicant[937]: wlan0: WPA: Key negotiation > completed with 11:11:11:11:11:11 [PTK=CCMP GTK=CCMP] > Jan 26 12:28:48 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-CONNECTED - > Connection to 11:11:11:11:11:11 completed [id=1 id_str=] > Jan 26 12:29:19 mycomp wpa_supplicant[937]: wlan0: CTRL-EVENT-SIGNAL-CHANGE > above=0 signal=-66 noise= txrate=58500 The second connection attempt (at 12:28:48) doesn't mention EAP, so perhaps you have multiple connections profiles for the same SSID, one using WPA-EAP and one using WPA-PSK? You can list the connection profiles with: nmcli connection and you can list the content of each of them with nmcli -o connection show Please verify if you have more than one connection for the SSID. > Further NM service restarts did not change verification - subject was still > accepted (shouldn't be). > > Then I've restarted WIFI connection using Gnome UI and next connections were > failing (on subject verification in wpa_supplicant logs). > > Further NM service restarts did not change verification - subject was > rejected (as it should). > > I've tested it further and it seems that adding > > > subject-match=wrongdomain > > > to connection file and restarting NM is not enough to apply this requirement > - one must restart connection using Gnome UI to have it applied. Is it bug > or something else should be done after subject-match was added to NM > connection file manually? After manually changing connection files, NM must be made aware of the changes with "nmcli connection reload". It's not necessary to restart the service. Please ensure that the modifications you did to the file were picked up by NM; to do that, check if the nmcli output contains the subject-match with: nmcli -o connection show Note that instead of changing the file manually and reloading connections, you can instead perform the change directly through nmcli with: nmcli connection modify 802-1x.subject-match "foobar" Instead of you can also use the connection name, but note that if multiple connections have the same name, only one of them will be updated. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing
Re: network-manager does not verify server certificate name on EAP-TLS WIFI connections
On Mon, Jan 25, 2021 at 09:27:55PM +0100, IB Development Team via networkmanager-list wrote: > network-manager does not verify server certificate name on EAP-TLS WIFI > connections: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981057 > > Please verify and consider fixing. Hi, with NM 1.14, just I tried to connect to a EAP-TLS Wi-Fi network with a wrong '802-1x.subject-match' and it failed complaining about the mismatch. I don't have the setup for 'altsubject-matches' and 'domain-suffix-match', I'll try to prepare one. Can you please verify if NetworkManager is passing to wpa_supplicant the right parameters? Try to connect, and then paste the output of: journalctl -u NetworkManager -e | grep "Config: added" It should be something like: NetworkManager[2749]: Config: added 'ssid' value 'wpa2-eap' NetworkManager[2749]: Config: added 'scan_ssid' value '1' NetworkManager[2749]: Config: added 'subject_match' value 'foobar' [...] Also, it would be useful to check wpa_supplicant logs for errors. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp: gracefully handle overlong host name values
On Wed, Nov 11, 2020 at 11:29:23AM -0500, Dusty Mabe wrote: > Hi all, > > I'd like to highlight a bug that was opened recently and see if we can start > some discussion on it in the ticket: > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/572 > > It's become a bit of a sticking point when trying to figure out the proper fix > for an issue we're having in the openshift OKD / Fedora CoreOS community. See > https://github.com/coreos/fedora-coreos-tracker/issues/649 > > We brought the issue to NM in an attempt to fix it at an appropriate point in > the stack, rather than propagating hacks in different places. > > Thanks for any discussion/consideration you put forward on this topic. Hi Dusty, I think NM is the appropriate place to sanitize an overlong host name from DHCP. I have opened a merge request for that. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Help with getting saved wireless networks passwords with libnm
On Mon, Nov 09, 2020 at 12:41:21AM +0100, Flavio Collocola via
networkmanager-list wrote:
> Hi all,
>
> I'm trying to port my Windows program WiFi Password Recovery to Linux.
> WiFi Password Recovery is a simple tool which scans all wireless networks
> stored on the device and then returns their info (such as SSID, Auth
> algorithm, *password...*).
> To keep portability I'm developing it in C++ using wxWidgets library. In
> particular on Linux I'm trying to use libnm to interface the program with
> NetworkManager. Before starting the port I decided to write a small C
> console program to learn libnm API and NetworkManager basis.
> I'm trying to get the passwords of all wireless networks saved on Ubuntu
> using libnm but when i call the function *nm_setting_wireless_security_get_psk
> *it returns null. It doesn't work with debug dump functions of libnm too. I
> think I should do something with NMSecretAgentOld but I don't understand
> what exactly and how. I also did not find any example on the Internet. I
> slightly modified a C example about using libnm available on internet and
> this is my current test code:
Hi,
the remote connection doesn't contain any secrets. You should use
nm_remote_connection_get_secrets() or
nm_remote_connection_get_secrets_async() [1] to get them. The returned
GVariant is a dictionary where each key indicates the setting name and
the value is another dictionary mapping property names to the secret
value; for example:
{'802-11-wireless-security': {'psk': <'my-password'>}}
Note that retrieving secrets for a connection requires Polkit
permissions. If the connection has an owner (connection.permissions
property), the owner needs the "settings.modify.own" permission to get
secrets. Otherwise, the caller needs the "settings.modify.system"
permission. You can check permissions for the current user with
command: "nmcli general permissions".
[1]
https://developer.gnome.org/libnm/stable/NMRemoteConnection.html#nm-remote-connection-get-secrets
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New "tc qdisc" options
On Mon, Oct 05, 2020 at 11:52:32AM -0400, Dave Collier-Brown wrote: > I can absolutely propose a patch/MR based on that example, but I'm > fallible (;-)) > > Do you prefer an MR in github or a git-format-patch via email? A MR on gitlab is the preferred way: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests Thanks, Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New "tc qdisc" options
On Mon, Oct 05, 2020 at 06:35:19AM -0400, Dave Collier-Brown via networkmanager-list wrote: > > > I see code in > > > > > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/master/libnm-core/nm-setting-tc-config.c > > > > > > which implements setting tc qdisc, and a brief mention in > > > > > > https://developer.gnome.org/NetworkManager/stable/ > > > > > > However the man pages do not mention tc. > > > > > > Can you provide a hint on setting, for example, /tc qdisc replace dev > > > enp0s25 root cake bandwidth 20mbit/ in network manager? > > "cake" is currently not supported. Until that is added, the intended > > solution is to use a dispatcher script. See `man NetworkManager`. > > Alas, that's the first place I looked (:-() > > Cake doesn't need to be supported in network manager, as I can work > around it's lack with fq_codel. > > However, I do need to discover the location and notation interpreted by > nm-setting-tc-config.c > > 1) can you help me with that? To configure fq_codel, you can use nmcli in this way: $ nmcli connection modify $myconnection tc.qdiscs \ "root fq_codel limit 2000 target 3000 interval 4" $ nmcli connection up $myconnection $ tc qdisc show dev $mydev qdisc fq_codel 8003: root refcnt 2 limit 2000p flows 1024 quantum 1514 target 3.0ms interval 40.0ms memory_limit 32Mb ecn > > 2) is adding (the name of) the cake qdisc on your backlog? Currently NM doesn't support configuring CAKE parameters. IOW, if you set "root cake bandwidth 100Mbit", you will see in the tc output that cake was set but with default parameters. Yes, I think it will be useful to have CAKE support in NM, but I can't say when it will be implemented. Of course, patches are always welcome; if anybody is interested in contributing it, please have a look at the work that was done to support SFQ: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/b22b4f9101b1cbfde49b65d9e2107e4ae0d817c0 Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Inconsistency in flags sent to GetSecrets() for VPN connections
On Thu, Aug 27, 2020 at 10:51:26PM +0300, Ionuț Leonte wrote: > Hello, > > I went back and tested again with TRACE logging enabled, here are the results: > > - GNOME on Fedora 32 (NM 1.22.14): > * activating via applet: https://pastebin.com/raw/ubLUSusH > * activating via settings page: https://pastebin.com/raw/jaR4EtuE > * activating via nmcli: https://pastebin.com/raw/jfJuq2zW > - KDE on my Gentoo desktop (NM 1.26.0): > * activating via applet: https://pastebin.com/raw/gsrtaiy4 > > In all cases EXCEPT the GNOME applet case SecretAgents are queried in reverse > registration order: > > [nmcli]->script->org.gnome.Shell.NetworkAgen/org.kde.plasma.networkmanagement > > In the GNOME applet case the order of the checks is reversed. The PID of the > process that sent the connection activation request does match with the PID > of gnome-shell. HOWEVER, in the KDE applet case the PID of the process that > activates the request is that of plasmashell but the order in which the agents > are queried is the 'correct' one (reverse registration order). It seems the opposite to me: - with GNOME Shell, the agent and the process performing the activation/deactivation are the same (176175): NetworkManager[164282]: [1598619148.2117] secret-agent[71d46805cd8d105d]: constructed: :1.30113/org.gnome.Shell.NetworkAgent/1000, owner="user" (unix-process[pid=176175, uid=1000, start=123260954]), unique-name=":1.28604", capabilities=vpn-hints $ ps -q 176175 176175 ? 0:12 /usr/bin/gnome-shell NetworkManager[164282]: [1598619276.5219] audit: op="device-disconnect" interface="enp8s0" ifindex=5 pid=176175 uid=1000 result="success" - with KDE plasma they are different. The agent is kded5, while operations are performed by plasmashell NetworkManager[164282]: [1598618060.2848] secret-agent[1563bf6e47b8e3f7]: constructed: :1.29823/org.kde.plasma.networkmanagement/1000, owner="user" (unix-process[pid=174878, uid=1000, start=123188141], unique-name=":1.28604", capabilities=none $ ps -q 174878 174878 ? 0:01 kded5 [kdeinit5] NetworkManager[164282]: [1598618534.6393] audit: op="connection-activate" uuid="83037490-1d17-4986-a397-01f1db3a7fc2" name="nat" pid=174931 uid=1000 result="success" $ ps -q 174931 174931 ? 0:57 /usr/bin/plasmashell > Also in the GNOME applet case the log for the GetSectet() calls with flags=5 > is weird - NM says: > > ... > > but that can't possibly be right because all I did was close the auth-dialog > window as soon as it popped up so I'm not sure what 'secrets' were returned > exactly. This is probably why my own GetSecrets() function is never called > with > flags=5 in this case - as far as NM is concerned the first secret agent it > queried told it that it had the secrets for the connection even though it > really didn't. That is probably a bug in the GNOME dialog. > > Is there any config option to disable the prefer-pid-of-the-activating-process > logic in NM? This seems like a really arbitrary thing to have in there. This behavior is what makes most sense to me. If the user activates a connection through an application X, then it is better to ask the secrets through the same application X the user is currently working on instead of spawning a dialog from an unrelated application Y. This behavior is useful for example when users activate connections in the terminal through "nmcli --ask connection up" or "nmtui", to avoid spawning graphical dialogs and ask secrets in the same application. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Inconsistency in flags sent to GetSecrets() for VPN connections
On Wed, Aug 26, 2020 at 09:03:12AM +0300, Ionuț Leonte via networkmanager-list wrote: > Hello, > > I have the following code: > > [...] > > It registers as a SecretAgent and prints the parameters that NetworkManager > sends to its GetSecret() method. > > With KDE - tested on Gentoo (NM version 1.26.0) and Kubuntu 20.04 (NM version > 1.22.10) - I see the following (correct?) behavior: > - when I go to System Settings > Connections and click on a VPN connection > (to see the settings of the connection) my GetSecrets() function gets > called once with flags=4 (ie. USER_REQUESTED - see [1]) > - when I try to activate a VPN connection (via nmcli OR from the connections > page in System Settings OR via the Plasma NetworkManager applet) my > function gets called twice - once with flags=4 then immediately after > with flags=5 (USER_REQUESTED | ALLOW_INTERACTION) > > With GNOME - tested on Fedora 32 (NM version 1.22.14) and Ubuntu 20.04 (NM > version 1.22.10) - I see the following (incorrect?) > behavior: > - when I go to Settings > Network and edit a VPN connection my function > gets called once with flags=4 (same as the KDE case) > - when I activate a VPN connection via nmcli or from Settings > Network my > function gets called twice - once with flags=4 and once with flags=5 > immediately after > - (!!) when I activate a VPN connection via the GNOME NetworkManager applet > however my function only gets called once with flags=4. After that the > default authentication dialog pops up and my function never gets called > again. Furthermore, when testing with an OpenConnect VPN, I can see that > nm-openconnect-auth-dialog gets run with the `-i` (interactive) parameter > even though my function gets called without ALLOW_INTERACTION set in flags If there are multiple agents registered, NM favors the one having the same PID of the process that is asking for secrets. So, if you are activating the VPN via the applet (which registers its own agent), NM will first ask flags=4 to the applet, then to yours. After that, since no agent could provide the secrets, it will try again them both in interactive mode (flags=5), in the same order. However, I think also the KDE applet or GNOME shell should behave in a similar way; I don't know why there is a difference. You should analyze NM logs as suggested by Thomas. Beniamino > I have tested with two types of VPN connection (OpenConnect and OpenVPN) and > I have seen this in both cases. > > Is this intended behavior? Seems to me like the GNOME applet is maybe missing > some fix that was applied to the Settings > Network page in GNOME. > > PS: On an older distribution (Ubuntu 18.04 with NM version 1.10.0) my function > always gets called with flags=4 so it looks to me like support for > ALLOW_INTERACTION was introduced only to some of the components. > > > [1] > https://lazka.github.io/pgi-docs/#NM-1.0/flags.html#NM.SecretAgentGetSecretsFlags > [2] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/introspection/org.freedesktop.NetworkManager.SecretAgent.xml > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PPPoE over VLAN again
On Sun, Aug 02, 2020 at 09:44:23AM -0700, Patrick Mansfield via networkmanager-list wrote: > I've been trying to directly use my linux system as the router / gateway with > my > CenturyLink ISP - it requires PPPoE and VLAN. > > Is PPPoE over VLAN supported by NetworkManager? > > I saw a response from 2017 that it was not supported, but can't tell if > that's still > the case. > > I'm using Fedora 31, I tried to get it working but so far have failed. Hi, PPPoE over VLAN is supported. Create a VLAN connection and then a PPPoE connection over it, for example in this way: nmcli connection add type vlan ifname vlan1 vlan.parent enp8s0 vlan.id 5 nmcli connection add type pppoe ifname pppoe1 pppoe.parent vlan1 username myusername password mypass Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: questions about changing NIC name
On Tue, Jun 23, 2020 at 11:07:52PM -0400, Dusty Mabe wrote: > Hi, > > While researching a bug reported against RHEL CoreOS I've decided to look a > bit deeper into > how a user would go about changing the name of a NIC on a machine to > something custom. In > this investigation I have some questions: > > - It seems as if nm-initrd-generator doesn't have support for the ifname= > karg. Is that >intentional? Yes, it's intentional; interface renaming is done by the 40-network module: https://github.com/dracutdevs/dracut/blob/050/modules.d/40network/ifname-genrules.sh > - If I specify the nic name and MAC as part of the ip= line the mac specified > gets set to > 'cloned-mac-address' rather than 'mac-address'. Is that right? > - i.e, > ip=192.168.122.111::192.168.122.1:255.255.255.0:initrdhost:nicname:none:0:52:54:00:00:00:0a > - > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/src/initrd/nmi-cmdline-reader.c#L583 It's right. The 9th field of an ip= option is the new MAC address to assign to the interface, and so cloned-mac-address is the right property to set. The old network module also uses that field to specify the new MAC. > - Is there a udev helper that parses NM keyfiles and sets up udev rules like > /lib/udev/rename_device > does for reading legacy network scripts in /etc/sysconfig/network-scripts/ ? > - > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/consistent-network-interface-device-naming_configuring-and-managing-networking#how-the-network-device-naming-works_consistent-network-interface-device-naming > - > https://github.com/fedora-sysv/initscripts/blob/master/src/rename_device.c I am not aware of such helper for NM keyfiles. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On Mon, Apr 27, 2020 at 11:35:47AM +0200, Thomas HUMMEL wrote: > On 4/27/20 11:13 AM, Thomas HUMMEL wrote: > > > I notices that > > > > hostnamectl --static set-hostname > > > > behavior was not the same according to the value of hostname-mode setting : > > > > - if set to 'none' : there's a delay for the transient hostname to be > > automatically set to the manually set static one > > > > - if set to 'dhcp' : the transient hostname is instantly aligned with > > the new static one. > > > > Is this expected ? > > Sorry, I cannot seem to reproduce this one I may have given you an incorrect > hint. > > Still the hostnamectl delay is a thing unexplained to me. I don't know the cause of the delay, it didn't expect it. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On Wed, Apr 22, 2020 at 08:18:24PM +0200, Thomas HUMMEL wrote:
> Hello,
>
> using NetworkManager-1.20.0-5.el8_1.x86_64 on CentOS 8.1 I tried to figure
> out the hostname-mode semantics beyond what the manual says (I've got
> another thread for this but somehow unrelated to the following question).
>
> In this post, I'd like to clarify this NetworkManager.conf(5) quote for
> default :
>
>
> "If not present, the hostname will be updated to the last one set outside
> NetworkManager."
>
> For what I saw when tracing, nm-policy reads the hostname-original and
> restores this hostname when the DHCP connection gets deactivated.
>
> Looking at the source, it seems to match this part in
> nm-policy.c:update_system_hostname() :
>
> if (!priv->default_ac4 && !priv->default_ac6) {
> /* No best device; fall back to the last hostname set
> externally
> * to NM or if there wasn't one, 'localhost.localdomain'
> */
> _set_hostname (self, priv->orig_hostname, "no default
> device");
> return;
> }
>
> Same kind of mechanism without default fallbacks for hostname-mode=dhcp
>
> What's not clear to me is : what if the transient hostname is changed
> outside NetworkManager after hostname-original gets read at NM start ?
> Let's say someone issues hostname foobar (instead of hostnamctl --transient
> set-hostname foobar) while the DHCP connection is still up : would that
> become the new set-out-of-NM hostname wich would be restored when the
> connection is deactivated ?
Yes, NM always re-reads the kernel hostname to detect whether it has
changed before trying to set a new one. When the DHCP connection gets
deactivated, NM should notice that the hostname was changed externally
and use it as the 'last one set outside NetworkManager' mentioned in
the man page.
> Technically NM could notice it directly issuing gethostname(3) but my
> understanding is that it would rather rely on systemd-hostnamed/dbus for
> that. The latter seems to have in some cases some delay to catch up with
> transient hostanme.
It uses systemd-hostnamed, and falls back to gethostname() in case of
failure [1].
[1]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.24-rc1/src/nm-policy.c#L550
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On Fri, Apr 10, 2020 at 07:44:51PM +0200, Thomas HUMMEL wrote:
> On 4/9/20 10:59 AM, Beniamino Galvani wrote:
> > > alking about D-Bus, I see this in the begining of all 3 (default, none,
> > > dhcp) traces :
> > >
> > > Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]:
> > > [1586350409.2521] policy: get-hostname:
> > > "maestro-1000.maestro.pasteur.fr" (from dbus)
> > > Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]:
> > > [1586350409.2521] policy: hostname-original: set to
> > > "maestro-1000.maestro.pasteur.fr"
> > >
> > > how is this hostname fully qualified who sets it ? The original hostname
> > > always seems to be this one.
> > I don't know, it is set before NM starts.
>
> Hello, again
>
> I tried to figure out the simplier case : hostname-mode=none.
>
> I guess the above fqdn hostname read from D-Bus is the transient hostname,
> correct ?
Yes.
> I don't think it can be set by dhcp if NM is the one which starts
> dhclient.
Correct. But I see that when NM starts, there are already dynamic
addresses configured on the interface:
Apr 08 14:53:28 maestro-1000.maestro.pasteur.fr NetworkManager[25235]:
[1586350408.9701] platform: (enp33s0f0) signal: address 4 added:
192.168.152.2/20 lft 43173sec pref 43173sec ...
and so probably DHCP was run before NM. Is this machine booting from a
network share? Are you passing any network-related command line to
kernel, like for example ip=... ? In such case, networking would be
configured in the initrd by dracut.
> As a matter of fact, I saw that dhconfig() from dhcpd-scripts
> /usr/sbin/dhclient-script can indeed set the transient hostname.
> The problem is that it sets the transient name only if hostname is needed,
> which, looking at the script is if transient hostname is empty or localhost
> :
>
> need_hostname ()
> {
> CHECK_HOSTNAME=$(hostnamectl --transient)
> if [[ "${CHECK_HOSTNAME}" = "(none)" ]] ||
>[[ "${CHECK_HOSTNAME}" = "localhost" ]] ||
>[[ "${CHECK_HOSTNAME}" = "localhost.localdomain" ]]; then
> return 0
> else
> return 1
> fi
> }
>
> which must not be the case because of the fqdn hostname we see BEFORE NM
> starts (I am assuming that dhclient is only started by NM of course here)...
The dhclient-script is not run when dhclient is started by NM.
> Or could that initial fqdn hostname come from systemd-hostnamed at boot
> which would fall back setting the transient hostname by reverse dns lookup
> of the ip address ?
No, I don't think it does. I think that DHCP is run before NM,
probably in initrd or by other services.
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On Thu, Apr 09, 2020 at 11:20:17AM +0200, Thomas HUMMEL wrote: > On 4/9/20 10:59 AM, Beniamino Galvani wrote: > > > > how is this hostname fully qualified who sets it ? The original hostname > > > always seems to be this one. > > > > I don't know, it is set before NM starts. > > Ok, I'll look into this but this is not related to my initial problem > indeed. > > > > In the 'none' log, the FQDN is set before NM starts > > Indeed (read from D-Bus by NM) > > > . Around 14:53:41 > > someone adds a new connection and activates it, disconnecting the > > previous DHCP connection. > > This can only be the postscript I mentionned creating the xcat- NM profile > > > At the same time the kernel hostname is > > changed externally to NM. I can't say who does this. > > Hmm this is odd. I may have missed something then. I'll look further into > it. > > > > - dhcp (end up with fqdn). > > > > In this case the short hostname got via DHCP is set by NM at > > 15:05:49. But later, somebody adds and activates a new connection > > 'xcat-enp33s0f0' with static addresses > > The postscript. > > > and so the DHCP hostname is > > removed, restoring the initial one. > > Ok but then you mean the one set BEFORE NM starts (again, the one read from > D-Bus at the begining) you mentionned above ? Because man said for > hostname-mode == dhcp that there is no fallback (like to reverse lookup the > ip address). Correct, no fallback to reverse lookup is done. NM keeps either the last hostname set outside of NM or the one present when NM was started. > I was initially confused by this : it LOOKED LIKE even in dhcp mode, NM was > performing a reverse lookup fallback as in fact it just reset to the one it > saw initially, correct ? Right. Beniamino ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On Wed, Apr 08, 2020 at 04:18:32PM +0200, Thomas HUMMEL wrote: > Hello, thanks for your answer > > On 4/8/20 10:25 AM, Beniamino Galvani wrote: > > >> - step2 (I guess) puts HOSTNAME=maestro-1000 in /etc/sysconfig/network > > > > AFAIK, NetworkManager doesn't do that. > > Although I saw that it was the postscript which wrote into this file, I > thought NetworkManager was considering it because it is mentionned in man 5 > nm-settings-ifcfg-rh Yes, the file is used for other variables but not for HOSTNAME. > > Yes, it uses the SetHostname D-Bus call of systemd-hostnamed, which > > changes the transient (kernel) hostname. > > Talking about D-Bus, I see this in the begining of all 3 (default, none, > dhcp) traces : > > Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]: > [1586350409.2521] policy: get-hostname: > "maestro-1000.maestro.pasteur.fr" (from dbus) > Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]: > [1586350409.2521] policy: hostname-original: set to > "maestro-1000.maestro.pasteur.fr" > > how is this hostname fully qualified who sets it ? The original hostname > always seems to be this one. I don't know, it is set before NM starts. > >> a) default : what's described above (fqdn) > >> b) none : hostname == short name > >> c) dhcp : same as a) (fqdn) > >> > >> I can elaborate on that like this : > >> > >> a) as man said NM sets hostname "with the one provided via DHCP", which > is > >> first the short one (step1) then as a static profile is activated, it > falls > >> back to "hostname from the reverse lookup of the IP address" (which DNS > >> resolves in the fqdn) > > > > Right. > > >> b) : NM just don't play with the transient name and sets a static > hostname > >> coming from /etc/sysconfig/network > > > > NM sets the transient host name. It doesn't know about > > /etc/sysconfig/network. The hostname is determined in this way: > > But man says "none: NetworkManager will not manage the transient hostname > and will never set it." > Makes me wonder what exactly is the transient hostname. It's the kernel hostname, the one used among other things in the journal. > Besides, trace for 'none' confirms hostname is "unmanaged" > > So where does the short hostname I see in this case b) come from if not dhcp > (none) neither the sysconfig/network file ? Good question. It is not NM that sets it. > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.20.0/src/nm-policy.c#L744 > > ok. But what does exactly "set outside of NetworkManager" mean ? > > > > No, it only takes the short hostname from DHCP. > > ok, makes sens as this is what's sent > > > > I don't know why it is setting the FQDN in your case. Could you please > > put level=trace in the [logging] section of > > /etc/NetworkManager/NetworkManager.conf, disabled journald > > ratelimiting, reproduce the issue and attach the journal log of a boot > > with hostname-mode=dhcp? > > Please find the 3 traces here: > > http://dl.pasteur.fr/fop/P3H6bSGV/NM-hostname-mode.tar.gz > > So basically, I still don't understand the 2 following cases > > - none (end up with short name) : if dhcp, NM seems to still manage the > hostname despite none In the 'none' log, the FQDN is set before NM starts. Around 14:53:41 someone adds a new connection and activates it, disconnecting the previous DHCP connection. At the same time the kernel hostname is changed externally to NM. I can't say who does this. > > - dhcp (end up with fqdn). In this case the short hostname got via DHCP is set by NM at 15:05:49. But later, somebody adds and activates a new connection 'xcat-enp33s0f0' with static addresses and so the DHCP hostname is removed, restoring the initial one. Beniamino ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On Tue, Apr 07, 2020 at 10:48:28PM +0200, Thomas HUMMEL wrote: > Hello, > > I'm trying to figure out how exactly my stateless HPC nodes (CentOS > 8.1/NetworkManager-1.20.0) get their hostnames. > > As a matter of fact, they can either get a "short" (non fqdn - something > like 'maestro-1000') hostname or a fqdn hostname > (maestro-1000.maestro.pasteur.fr). This is related to the process network is > configured according to the following procedure : > > 1. node PXE boots the stateless osimage and ends up having a dhcp NM profile > 2. a postscript is run on the node which uses NM to create an additional > profile with higher autoconnect priority which main goal is to statically > set the ip address retrieved in step 1. > > - if only step 1. is performed hostname == short name > - if step 1 + 2. are performed, hostname == fqdn > > Note : > > - DNS is configured on each node, both for forward and reverse zone > > - I checked with tcpdump that DHCP option 12 "Host-Name" always stores the > short name (and of course the domain 'maestro.pasteur.fr' in option 15) > > - step2 (I guess) puts HOSTNAME=maestro-1000 in /etc/sysconfig/network AFAIK, NetworkManager doesn't do that. > - node never have a /etc/hostname file > > - no hostname-mode is specified in NetworkManager.conf > > - finally, when step 1+2 are performed, I can see: > > Apr 07 20:13:19 maestro-1000 systemd-hostnamed[14516]: Changed host name to > 'maestro-1000' > Apr 07 20:13:33 maestro-1000.maestro.pasteur.fr systemd-hostnamed[14516]: > Changed host name to 'maestro-1000.maestro.pasteur.fr' > > which I reckon matches step1 then step2 > > Here are my questions : > > - I am assuming NetworkManager uses systemd-hostnamed when it is in charge > to set the hostname : is this correct ? Yes, it uses the SetHostname D-Bus call of systemd-hostnamed, which changes the transient (kernel) hostname. > - I am assuming what I see is related to hostname-mode setting as I didn't > see any hostname or hostnamectl et sethostname call in the postscript. > Playing with its possible valued in NM config, I experienced the following > after step 1+2 : > > a) default : what's described above (fqdn) > b) none : hostname == short name > c) dhcp : same as a) (fqdn) > > I can elaborate on that like this : > > a) as man said NM sets hostname "with the one provided via DHCP", which is > first the short one (step1) then as a static profile is activated, it falls > back to "hostname from the reverse lookup of the IP address" (which DNS > resolves in the fqdn) Right. > > b) : NM just don't play with the transient name and sets a static hostname > coming from /etc/sysconfig/network NM sets the transient host name. It doesn't know about /etc/sysconfig/network. The hostname is determined in this way: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.20.0/src/nm-policy.c#L744 > c) confuses me as the manual says NM > > "will update the transient hostname only with information coming from DHCP" > but with no fallback > So I was expecting after step 2 to have localhost.localdomain or only the > short name but not the fqdn > > Or maybe it builds a fqdn from host-name + domain coming from DHCP ? No, it only takes the short hostname from DHCP. I don't know why it is setting the FQDN in your case. Could you please put level=trace in the [logging] section of /etc/NetworkManager/NetworkManager.conf, disabled journald ratelimiting, reproduce the issue and attach the journal log of a boot with hostname-mode=dhcp? Beniamino > > Can you help me figuring out my misunderstanding ? > > Thanks for your help > > -- > Thomas HUMMEL signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Need help porting ifcfg-ppp0 config to NetworkManager
On Thu, Mar 26, 2020 at 09:09:36AM +, David Howells via networkmanager-list
wrote:
> Hi,
>
> I need some help porting an ifcfg-ppp0 config from my old internet gateway
> which was running to Fedora 16 to my new internet gateway which is running
> F31. Running "ifup ppp0" gives a message saying that this is deprecated and I
> should switch to NM.
>
> Unfortunately, I can't work out how to configure NM to do this. I can see
> options for connections of ppp, (a)dsl and pppoe type, but I seem to need some
> combination of these and that does not appear to be possible to configure with
> nmcli, plus some pppd options (such as "ipv6" and "holdoff") that aren't
> listed in the documentation.
>
> My (redacted) config is below.
>
> Thanks,
> David
> ---
> [root@gatekeeper ~]# cat /etc/sysconfig/network-scripts/ifcfg-ppp0
> BOOTPROTO=dialup
> DEFROUTE=yes
> DEMAND=no
> FIREWALL=NONE
> ONBOOT=yes
> PEERDNS=yes
> PERSIST=yes
> PIDFILE=/var/run/pppoe-adsl.pid
> PING=.
> SYNCHRONOUS=no
> TYPE=xDSL
> USERCTL=yes
>
> CONNECT_POLL=6
> CONNECT_TIMEOUT=3600
> DEVICE=ppp0
> ETH=enp4s0
> IPV6INIT=yes
> LCP_FAILURE=120
> LCP_INTERVAL=1
> LINUX_PLUGIN=rp-pppoe.so
> MRU=1492
> MTU=1492
> PPPOE_TIMEOUT=80
>
> PPPD_EXTRA="ipv6 , holdoff 1"
> IPADDR=
> USER=
Hi,
this should create a connection mostly equivalent to your
configuration:
nmcli connection add \
type pppoe ifname ppp0 pppoe.parent enp4s0 \
pppoe.user $myuser pppoe.password $mypw \
ppp.mru 1492 ppp.mtu 1492 \
ppp.lcp-echo-interval 1 ppp.lcp-echo-failure 120 \
ipv4.address $myip
'man nm-settings' shows all the properties supported by NM. I don't
think "holdoff 1" is needed as NM always waits some seconds before
reinitiating the connection. Also, I'm not sure IPv6 is supported. You
could try adding 'ipv6.method manual ipv6.addresses $myip6' but it
doesn't seem possible to specify a peer address.
Note that the connection has 'autoconnect yes' by default and so it is
started automatically at boot. If you want to activate it manually,
you should also set 'autoconnect no', and then control it with:
nmcli connection {up|down} pppoe-ppp0
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dns=dnsmasq, directing unqualified names to DHCP-provided-DNS-servers on a specific interface
On Thu, Jan 23, 2020 at 10:16:14AM +, Samuel Harmer wrote: > Dear List, > > Thoroughly enjoying NetworkManager (NM)! Just one thing I could not find an > obvious method to achieve so thought I would double-check. > > I am trying to work out how to define (in NM settings) an interface should > be used for unqualified lookups. Specifically *unqualified*, I can't make > use of search->fully-qualified as there are private web servers that expect > the browser to be requesting an unqualified hostname. I can't alter this > bizarre (imo) design choice. > > With pure dnsmasq I can use `[--]server=//192.168.n.n` and > `[--]server=/local/192.168.n.n` to specify a DNS server to send both > unqualified and private domain lookups to. > > With NM I can specify `nmcli [...] set ipv4.dns-search ~local` to have > private zones looked up via NM's dnsmasq (assuming `dns=dnsmasq`), but I > can't see a way to direct (all) unqualified lookups to the interface (or > rather the DNS server(s) provided by the DHCP server on the interface). > > The interface is not used as a default gateway, but I am guessing I could > fiddle around with adding back in `~.` and (misusing) ipv4.dns-priority so > all unqualified names go to a private DNS server(s) first, but this feels > like a cludge and would (I guess) still result in the unqualified names > being forwarded on to public DNS servers should one not exist in the > private DNS servers. > A less-cludgy inelegant alternative would be to `echo > "server-file=/etc/NetworkManager/unqualified.servers" > > /etc/NetworkManager/dnsmasq.d/unqualified`, then use a dispatcher to > populate unqualified.servers, followed by SIGHUP NetworkManager's dnsmasq > instance. > > Neither option feels right. > > Is this a missing feature or have I missed something? Hi, unlike dnsmasq, NM doesn't have a way to specify that unqualified domains should be handled differently. Usually, in such cases a search domain is used, which gets appended by the resolver to the unqualified name and then it is also used as a routing domain to direct the query to a specific interface. Does you private resolver also reply to queries for qualified names with a specific local domain? If so, you can add 'mydomain' to 'ipv4.dns-search', and then if you type 'webserver' in the browser the resolver will query 'webserver.mydomain' through that interface. If that doesn't work for you, the only workarounds I can think of are the ones you already described. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Collect agreement/disagreement to Relicense NetworkManager under LGPL-2.1+
On Thu, Jan 09, 2020 at 01:26:31PM +0100, Thomas Haller via networkmanager-list wrote: > Hi all, > > > Currently, we have some LGPL vs. GPL license issue in libnm. > This will be addressed by [1]. > > However, I'd like not only to fix that particular issue, but instead > collect agreement/disagreement of copyright holders of NetworkManager > code, to perform this and future such relicensing. > > I would ask everybody relevant to provide explicitl agreement or > disagreement. This is all explained and tracked in our git repository > [2]. > > I would very much appreciate if you could look at [2] and provide > feedback. > > [1] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/390 > > [2] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/master/RELICENSE.md Hi, I agree to the relicensing. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: global-dns not working
On Tue, Sep 10, 2019 at 03:48:34PM +1000, AP wrote: > Hi, > > Using NM 1.20.0 with Debian Buster (though this also happens with 1.14.6) and > am > trying to get the global-dns section to work so that I don't have to type it > in > for each and every connection I create. > > Alas, it's proving to be a pain and not doing what I want (ie working at > all). The > config, as NM sees it is as follows: Hi, you need a section for the default domain, as: [global-dns-domain-*] servers=1.1.1.1 As explained on IRC, the global DNS configuration must be completely defined and requires a name server for the default domain. Currently it is not possible to define partial (for example, only the search domain without servers) global configuration that is integrated at run time with the information from active connections (i.e. name servers). If the global configuration is defined, the rest is ignored. A mechanism to merge them seems a useful feature that we could implement. Beniamino > --- 8< --- > Read config: /etc/NetworkManager/NetworkManager.conf (lib: > no-mac-addr-change.conf) (etc: dns-resolv.conf, min-systemd.conf) > CONFIG: config-data[0x55b3773e11b0]: 5 groups > CONFIG: > CONFIG: [main] > CONFIG: plugins=ifupdown,keyfile > CONFIG: dns=default > CONFIG: rc-manager=symlink > CONFIG: systemd-resolved=false > CONFIG: > CONFIG: [global-dns] > CONFIG: searches=moo.cow > CONFIG: options=edns0 > CONFIG: > CONFIG: [ifupdown] > CONFIG: managed=false > CONFIG: > CONFIG: [logging] > CONFIG: level=TRACE > CONFIG: domains=ALL > CONFIG: > CONFIG: [device-mac-addr-change-wifi] > CONFIG: > match-device=driver:rtl8723bs,driver:rtl8189es,driver:r8188eu,driver:8188eu,driver:eagle_sdio,driver:wl > CONFIG: wifi.scan-rand-mac-address=no > config: state: successfully read state file > "/var/lib/NetworkManager/NetworkManager.state" signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works
On Fri, Aug 09, 2019 at 05:03:34PM +0200, Vincent Lefevre wrote: > On 2019-08-09 16:05:11 +0200, Beniamino Galvani wrote: > > in the traces I see that there are 3 servers and one of them > > advertises a subnet different from other two. This setup makes the > > behavior non-deterministic because clients can get an address either > > in the 10.0.1.0/24 or in the 140.77.12.0/23 network. Do you know if > > the network configured in this way on purpose? > > I think so, as there are 2 kinds of machines: those that are supposed > to have a fixed IP address on the main network, and the other machines, > which will be on a secondary network. My machine is in the former > class. I don't know how such machines are supposed to be identified > (probably with a weak identification), but I can see my machine > name in the DHCP Discover and DHCP Request packets. Ok, then this mechanism is not working since your machine is receiving offers for both networks and randomly takes one. I don't know how common this setup is, but the RFC seems to warn against it: Once the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects. > > Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11: > > [...] > > to which the internal client replies with a request. Note the > > server-id set to 140.77.1.11: > > [...] > > The DHCP server at 10.0.1.1 NAKs the request even if it had a > > different server-id; I don't think this is correct: > > > > [...] > > RFC 2131 says: "If a server receives a DHCPREQUEST message with an > invalid 'requested IP address', the server SHOULD respond to the > client with a DHCPNAK message and may choose to report the problem > to the system administrator." > > So this seems correct. Note that it does not say that the server must > check the server-id, and the fact that it says "a server" instead of > "the server" tends to make me think that this is how it works. > > BTW, if the server implicitly needs to check the server-id, why > doesn't the internal client do this too about the DHCPNAK response? This part of RFC 2131 is quite clear in my opinion: 3. The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and that MAY include other options specifying desired configuration values. [...] 4. The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. [...] So the behavior of server 10.0.1.1 seems not compliant to RFC. > > Also, RFC 2131 says that the "If the client receives a DHCPNAK > > message, the client restarts the configuration process", that is what > > the internal client does, until the ACK comes before or until > > timeout. dhclient apparently ignores the NAK, but I haven't found yet > > in the code where this is done and based on what. > > It seems that RFC 2131 has some contradictions in case of several > DHCP servers on several networks. IMHO, the client should be > tolerant and ignore DHCPNAK if the server-id is different. I checked again and the internal client doesn't do any filtering based on the server-id. In the dhclient log at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930#42 Aug 06 15:48:15 cventin NetworkManager[797]: [1565099295.6037] dhcp4 (enp0s25): dhclient started with pid 1052 Aug 06 15:48:15 cventin dhclient[1052]: DHCPREQUEST for 140.77.13.17 on enp0s25 to 255.255.255.255 port 67 Aug 06 15:48:21 cventin dhclient[1052]: DHCPREQUEST for 140.77.13.17 on enp0s25 to 255.255.255.255 port 67 Aug 06 15:48:21 cventin dhclient[1052]: DHCPNAK from 10.0.1.1 Aug 06 15:48:21 cventin NetworkManager[797]: [1565099301.7956] dhcp4 (enp0s25): state changed unknown -> expire Aug 06 15:48:21 cventin NetworkManager[797]: [1565099301.8037] dhcp4 (enp0s25): state changed expire -> unknown Aug 06 15:48:21 cventin dhclient[1052]: DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 4 Aug 06 15:48:21 cventin dhclient[1052]: DHCPOFFER of 140.77.13.17 from 140.77.1.12 Aug
Re: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works
On Fri, Aug 09, 2019 at 01:10:55PM +0200, Vincent Lefevre wrote: > On 2019-08-09 09:42:10 +0200, Beniamino Galvani wrote: > > On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote: > ... > > Could you capture DHCP packets with: > > > > tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68 > > > > when using dhclient and the failing internal client, and attach the > > files? > > dhcp-dhclient.pcap- using dhclient (success, though NAK came first) > > dhcp-int-failure.pcap - using the internal client (failures until > I stopped the capture; ACK never came first) > > dhcp-int-success.pcap - using the internal client (success after > several requests, once ACK came first) > Hi, in the traces I see that there are 3 servers and one of them advertises a subnet different from other two. This setup makes the behavior non-deterministic because clients can get an address either in the 10.0.1.0/24 or in the 140.77.12.0/23 network. Do you know if the network configured in this way on purpose? Looking at dhcp-int-failure.pcap, there is an offer from 140.77.1.11: 12:29:03.690421 94:f1:28:19:08:00 > 98:90:96:bd:7f:f7, ethertype IPv4 (0x0800), length 366: (tos 0x0, ttl 63, id 55318, offset 0, flags [DF], proto UDP (17), length 352) 140.77.1.11.67 > 140.77.13.17.68: BOOTP/DHCP, Reply, length 324, hops 1, xid 0xff001675, secs 2, Flags [none] Your-IP 140.77.13.17 Server-IP 140.77.14.50 Gateway-IP 140.77.12.1 Client-Ethernet-Address 98:90:96:bd:7f:f7 file "/lpxelinux.0"[|bootp] to which the internal client replies with a request. Note the server-id set to 140.77.1.11: 12:29:03.690539 98:90:96:bd:7f:f7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 340: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 326) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:90:96:bd:7f:f7, length 298, xid 0xff001675, secs 2, Flags [none] Client-Ethernet-Address 98:90:96:bd:7f:f7 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 98:90:96:bd:7f:f7 Parameter-Request Option 55, length 18: Subnet-Mask, Default-Gateway, Hostname, Domain-Name Domain-Name-Server, Time-Zone, MTU, BR Classless-Static-Route, Static-Route, YD, YS NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft Option 252, RP MSZ Option 57, length 2: 576 Server-ID Option 54, length 4: 140.77.1.11 Requested-IP Option 50, length 4: 140.77.13.17 Hostname Option 12, length 7: "cventin" The DHCP server at 10.0.1.1 NAKs the request even if it had a different server-id; I don't think this is correct: 12:29:03.691585 5c:96:9d:6d:9d:48 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 10.0.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0xff001675, secs 2, Flags [Broadcast] Server-IP 10.0.1.1 Client-Ethernet-Address 98:90:96:bd:7f:f7 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: NACK Server-ID Option 54, length 4: 10.0.1.1 MSG Option 56, length 31: "requested address not available" Also, RFC 2131 says that the "If the client receives a DHCPNAK message, the client restarts the configuration process", that is what the internal client does, until the ACK comes before or until timeout. dhclient apparently ignores the NAK, but I haven't found yet in the code where this is done and based on what. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works
On Thu, Aug 08, 2019 at 06:07:41PM +0200, Vincent Lefevre wrote: > On 2019-08-08 13:37:04 +0200, Michael Biebl wrote: > > Bringing Vincent into the loop here. > > > > Vincent, can you gather the information Beniamino is asking for? > > > > Am 08.08.19 um 09:51 schrieb Beniamino Galvani: > > > Would it be possible to capture a dump of DHCP packets for a success > > > and for a failure? > > Each time after DHCP Request, there are 1 NAK packet (from 10.0.1.1) > and 2 NAK packets (from 140.77.1.11 and 140.77.1.12), but not always > in the same order. > > With the internal DHCP client, this seems to be a success only if an > ACK packet comes first. There is no such issue with the external one. > > Do you need more information? Could you capture DHCP packets with: tcpdump -i enp0s25 -s 0 -w dhcp.pcap udp port 67 or port 68 when using dhclient and the failing internal client, and attach the files? Or, if you prefer, attach the decoded text output: tcpdump -vvenni enp0s25 udp port 67 or port 68 Thanks, Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Allow use of TPM2-wrapped keyfiles
On Mon, Jul 08, 2019 at 06:46:12PM +0200, Daniel Kobras wrote: > Hi all! > > Using either GnuTLS or one of the TPM2 engines for OpenSSL, it's > possible to use keyfiles that are encrypted with a wrapping key from a > TPM2 device. Implementations have started to use special PEM headers for > these files. If openconnect it can automatically invoke the necessary > magic to unwrap the key without any user interaction. A similar patch > for wpa_supplicant can be found at > http://lists.infradead.org/pipermail/hostap/2019-July/040318.html. > > Alas, these PEM files currently fail NM's header validation. The > attached patch just accepts these keys in NM, assuming further support > is present in the backend tools. Applied, thanks! Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager 1.10.14 - DNS regression
On Mon, Jul 01, 2019 at 04:48:14PM +0200, Till Kamppeter via networkmanager-list wrote: > Hi, > > I have a problem with network-manager 1.10.14. We have introduced this > version as a stable release update to Ubuntu 18.04 (Bionic) and fixing > several bugs of the old 1.10.6 it introduced regressions with DNS. It seems > to have problems with DNS priority. > > A regression report with appropriate logs is here: > > https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1829566 > > As the problems do not occur with Network Manager in later Ubuntu versions > (like Eoan) it seems that the problem got fixed somewhere in the upstream > code. > > Can someone help me which changes of the further upstream development I > should apply to 1.10.14 to get this fixed? Hi, the domain specification in the configuration reported on launchpad: [Resolve] Cache=no DNS=127.0.0.54 Domains=~.local.org.com is invalid: systemd-resolved[13415]: Failed to add search domain '~.local.org.com', ignoring: Invalid argument The correct form should be without the dot: Domains=~local.org.com Can you ask to fix that configuration error and try again? Otherwise, queries for the local.org.com domain are not routed to the local dnsmasq instance. Beniamino ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: spamming router with router solicitations
On Tue, Jun 25, 2019 at 10:20:54AM -0400, Brian J. Murrell wrote: > On Mon, 2019-06-24 at 08:52 +0200, Beniamino Galvani via > networkmanager-list wrote: > > > > Hi, > > Hi Beniamino, > > > I checked again the log you sent and I see the problem now. When NM > > receives a RA, it checks whether the parameters > > Which parameters exactly? Because I might be able to shed some light > on this now that this is known. Basically everything in the RA. See how the 'changed' variable is set in: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/1.18.0/src/ndisc/nm-lndp-ndisc.c#L110 > > changed compared to > > the previous RA and if so it applies the new configuration. When it > > does so, it also reapplies the token; this triggers a new router > > solicitation from kernel due to: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c?h=v3.10#n4336 > > Interesting. > > > The new RA received is: > > > > neighbor discovery configuration changed [R]: > > dhcp-level none > > gateway fe80::6eb0:ceff:fef5:1e4a pref high exp 1799.2317 > > address 2001:123:ab:123::2 exp permanent > > route 2001:123:ab:123::/64 via fe80::6eb0:ceff:fef5:1e4a pref > > high exp permanent > > dns_server fd31:aeb1:48df::2 exp 7199.2317 > > > > Note the "changed [R]" part which means that routes changed. This is > > strange because according to log there was no change from previous > > RA. This causes the reapply of token, a new RS, a RA and so on ... > > Here is what an RA from my router looks like: > > [...] > > But three things that the above is not saying: > >1. Until yesterday, the Router Lifetime of one of those RAs was 0 and > the other was 1800 (I don't recall which was which). >2. Until the last week or two, the first prefix was being advertised > with a Router preference of high and the other was medium. >3. Each of those two RAs come in two different packets, one for each > prefix rather than them both being in the same RA which I think is > the typical behaviour. I think all these should be handled well. But perhaps older versions of NM had issues with the 0 lifetime of point 1. > > Apart from this, I think NM should not apply the token when it's > > already set; > > That seems reasonable. This is now fixed in master: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/e4ce9bd7af6a39677ff1a1380906d18062abb24a and stable branches nm-1-18, nm-1-16. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: spamming router with router solicitations
On Fri, Jun 21, 2019 at 01:03:11PM -0400, Brian J. Murrell wrote: > On Fri, 2019-06-21 at 17:58 +0200, Beniamino Galvani via > networkmanager-list wrote: > > > > Sounds ok. > > Thanks. > > > Which kernel version do you have on the EL 7.6 machine? > > 3.10.0-957.21.2.el7.x86_64 Hi, I checked again the log you sent and I see the problem now. When NM receives a RA, it checks whether the parameters changed compared to the previous RA and if so it applies the new configuration. When it does so, it also reapplies the token; this triggers a new router solicitation from kernel due to: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c?h=v3.10#n4336 The new RA received is: neighbor discovery configuration changed [R]: dhcp-level none gateway fe80::6eb0:ceff:fef5:1e4a pref high exp 1799.2317 address 2001:123:ab:123::2 exp permanent route 2001:123:ab:123::/64 via fe80::6eb0:ceff:fef5:1e4a pref high exp permanent dns_server fd31:aeb1:48df::2 exp 7199.2317 Note the "changed [R]" part which means that routes changed. This is strange because according to log there was no change from previous RA. This causes the reapply of token, a new RS, a RA and so on ... If you are not able to reproduce the problem with a newer NM version, this means that probably the wrong comparison of RAs was fixed in the meantime. I don't see any commit that seems to directly fix that, though. Apart from this, I think NM should not apply the token when it's already set; and also I'm not sure why it keeps the accept_ra sysctl enabled these days, that allows the kernel to send RAs in parallel with NM. I will check if this can be improved. Thanks, Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: spamming router with router solicitations
On Tue, Jun 18, 2019 at 02:24:09PM -0400, Brian J. Murrell wrote: > On Mon, 2019-06-03 at 14:17 -0400, Brian J. Murrell wrote: > > > > I think I had it set to DEBUG. Let me see if I can reproduce with it > > set to TRACE. > > I have to correct myself. It was set to TRACE. > > > It goes up quite a bit. More indication that it is NM. > > CPU is pegged between NM, journald and one other unrelated process. I > assume without the latter, NM and journald would monopolize the CPU. > > So I don't really know what's going on here. > > But really, given all of the time I have spent on this, the path of > least resistance is probably just rate-limiting the RSes at the router. > > What's a reasonable number of RSes to allow in a given time-frame? > > 1/sec burst 5 seems to be keeping things under control on both the > router and the machine suffering this NM problem. Sounds ok. Which kernel version do you have on the EL 7.6 machine? B. signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: spamming router with router solicitations
On Sat, May 25, 2019 at 03:47:37PM -0400, Brian J. Murrell wrote: > On Sat, 2019-05-25 at 08:52 +0200, Beniamino Galvani via > networkmanager-list wrote: > > > > Hi, it is not NM sending those RS. > > But they stop as soon as I stop NM. > > > If it were, you would see in the > > journal messages like: > > > > ndisc[0x55a43c15e0e0,"ens9"]: router solicitation sent > > I'm not in a position to argue that point, but if the storm can be > stopped and started by stopping and starting NM, that's pretty strong > evidence that NM is doing it, wouldn't you agree? Are you sure you don't have other daemons like systemd-networkd or something else active which are racing with NM? From logs it is pretty clear that NM is sending exactly one router solicitation at: May 25 15:42:55 server.example.com NetworkManager[10973]: [1558813375.1729] ndisc[0x55a336c550e0,"enp2s0"]: router solicitation sent However it could be that NM is configuring the kernel in a wrong way. > > I see from the log that you set a IPv6 token; can you please try > > without it if it makes any difference? > > But that machine needs to have a predictable, easily remembered > address, which it does not get without a token. > > In any case, as a debugging step, I did disable it and restart NM and > the storm did not start up with it. When I re-enabled the token again > and restarted NM, the storm started when it started, so it does seem to > be related to using a token. > > > Also, please attach a log from > > the beginning of the profile activation. > > There is no "profile activation" because this is a headless server, > hence the reason for the token. I'll attach the NM log from the time > it is started up. Hopefully that provides what you are looking for. Yes, it is ok. Note that you can force a new activation of a connection with: nmcli connection up $con_name where $con_name if the name of the connection obtained through: nmcli connection show In your case the connection name is equal to the device name - enp2s0. The reactivation is useful to apply changes after modifying a connection without the need to restart NM or reboot. Can you also attach the output of nmcli connection show enp2s0 ? Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: spamming router with router solicitations
On Sun, May 12, 2019 at 10:41:28AM -0400, Brian J. Murrell wrote: > On Sat, 2019-05-11 at 17:46 -0500, Ian Pilcher via networkmanager-list > wrote: > > > > Presumably you've told NetworkManager to auto-configure the interface > > for IPv6. If you don't want it to do that, set it to link-local > > only. > > But surely NM doesn't need to send dozens of RS's per second to do > that, yes? Hi, it is not NM sending those RS. If it were, you would see in the journal messages like: ndisc[0x55a43c15e0e0,"ens9"]: router solicitation sent I see from the log that you set a IPv6 token; can you please try without it if it makes any difference? Also, please attach a log from the beginning of the profile activation. Thanks, Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can't create OVS bridge - device is strictly unmanaged
On Tue, May 07, 2019 at 02:00:00PM -0500, Ian Pilcher via networkmanager-list wrote: > I am trying to switch from using old-style ifcfg files to NetworkManager > to set up an OVS bridge on my (Fedora 30) laptop. Because this is a > laptop, no physical interface is connected to the bridge; all VM traffic > to the outside world is "NAT'ed" by iptables. Also, for reasons that I > can't even remember, the NAT'ed network is on VLAN 122 on the OVS > bridge. > > If I were setting this all up manually, I would use the following > commands: > [...] > Hmm. Maybe I need to bring the interface up? > > # nmcli conn up ovs0-int-iface > Error: Connection activation failed: Connection 'ovs0-int-iface' is not > available on device ovs0 because device is strictly unmanaged Do you have any special configuration that makes the device unmanaged? Can you paste the output of 'NetworkManager --print-config'? Also, if you run 'nmcli general logging level trace', repeat the nmcli commands above and grep the journal for 'unmanaged:' you should see more details about why ovs0 is considered unmanaged. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Implementing a SecretAgent
On Fri, Nov 30, 2018 at 09:08:41AM +0100, Damien Cassou wrote: > Hi, > > I would like to implement a secret agent. The first thing I'm trying is > to start a `nmcli agent secret` process and watch for its output > stream. When `nmcli agent` gets a request for a password, it prints > > password (vpn.secrets.password): > > on stdout. How do I know which VPN connection requires a password? > Is this information available through D-Bus or something else? Hi, as you can see in the nmcli/nmtui secret agent implementation at [1], the secret agent must look into the connection and have some logic to decide which secrets are needed. In my opinion this is far from optimal as it requires secret agents to reimplement similar duplicated code, so I think it is an aspect that will need to be improved in future versions of NM. Beniamino [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/clients/common/nm-secret-agent-simple.c?h=nm-1-14#n447 signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager D-Bus API Reference: Device.Wireless: The "Bitrate" property should be "BitRate"
On Thu, Sep 06, 2018 at 04:40:23PM -0400, Joseph Conley via networkmanager-list wrote: > Hello, > > I wanted to point out a small error in the NetworkManager D-Bus API Reference. > Under org.freedesktop.NetworkManager.Device.Wireless, The "Bitrate" > property should be "BitRate". I have verified this using python. The > documentation is incorrect with 1.12.2, as well as 1.13. > > The file that this needs correcting is > /introspection/org.freedesktop.NetworkManager.Device.Wireless.xml Hi, the correct name of the property is 'Bitrate' as documented in the API reference. It was accidentally changed to 'BitRate' during the 1.12 release cycle after a code rework. This means that releases 1.12.0 and 1.12.2 export the property with the wrong name. This is fixed now on master: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/c882633d48ad70d5c92ce0566a0f46dcbb5c51b3 The fix was also backported to the nm-1-12 branch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/3a2c6f81f6b0a8dd38d45aa89fa7d6d1f897f149 and will be available in the next minor release of the stable version, that is 1.12.4 (and of course it also be available in the next major release 1.14). Thanks for reporting this and sorry for the inconvenience! Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Update settings on a NM.RemoteConnection with python
On Sat, Aug 18, 2018 at 12:20:53AM +, infirit via networkmanager-list wrote:
> Hi,
>
> I found that there is NM.RemoteConnection.replace_settings that takes a
> GLib.Variant but I can't figure out what it needs to contain.
>
> Take the below SimpleConnection for a bluetooth dun connection how would
> I update for example the apn?
>
> conn = NM.SimpleConnection()
> sett_conn = conn_sett = NM.SettingConnection(type='bluetooth', id='someid')
> sett_bt = NM.SettingBluetooth(type='dun', bdaddr='bdaddr')
> sett_gsm = NM.SettingGsm(apn='apn', number='number')
>
> conn.add_setting(sett_conn)
> conn.add_setting(sett_gsm)
> conn.add_setting(sett_bt)
>
> #add connection with client
>
> remote_conn = client.get_connection_by_id('someid')
> remote_conn.replace_settings(???)
>
> What is the correct format string for the GLib.Variant and could you
> give an example for updating the apn?
Hi,
if you are trying to update a property of a connection, you can use
something like this:
c = client.get_connection_by_id(id)
s_gsm = c.get_setting_gsm()
s_gsm.set_property(NM.SETTING_GSM_APN, "xyz")
try:
c.commit_changes(True, None)
print("The connection profile has been updated.")
except Exception as e:
sys.stderr.write("Error: %s\n" % e)
See some examples here [1], especially the update-ip4-method.py one.
Beniamino
[1]
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/gi
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] device: fix order of params in nm_match_spec_device prototype
On Fri, Jul 06, 2018 at 02:35:33PM +0200, Olivier Gayot via networkmanager-list
wrote:
> The following commit:
>
> b869d9cc0 device: add spec "driver:" to match devices
>
> added two parameters ("driver" and "driver_version") to the
> nm_match_spec_device() function.
>
> However, the definition of the function and its declaration are not
> consistent.
Applied to master, thanks! (Removed the Signed-off-by: tag since we
don't use it, and added the Fixes: one).
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC PATCH v3 3/3] platform: add support for WireGuard links
On Sun, Jun 17, 2018 at 12:34:58PM +0100, Javier Arteaga wrote:
> Add support for a new wireguard link type to the platform code. For now
> this only covers querying existing links via genetlink and parsing them
> into platform objects.
> ---
>
> Notes:
> Changes in v2->v3:
>
> * Changed peers/allowedips from CList to arrays-of-structs
> (GArray wrappers are used during genl parsing stage to handle reallocs)
> * Wrote proper cmp/hash methods for peer objects
> * Split off two patches not really specific to WireGuard
> * Corrected WireGuard uapi identifier names
> * Addressed a few other comments on v2
>
> libnm-core/nm-core-types-internal.h | 25 +++
> src/nm-types.h | 2 +
> src/platform/nm-linux-platform.c| 315
> src/platform/nm-platform.c | 124 +++
> src/platform/nm-platform.h | 15 ++
> src/platform/nmp-object.c | 219 +++
> src/platform/nmp-object.h | 10 +
> 7 files changed, 710 insertions(+)
>
> diff --git a/libnm-core/nm-core-types-internal.h
> b/libnm-core/nm-core-types-internal.h
> index 4d43aaf45..f95652fa2 100644
> --- a/libnm-core/nm-core-types-internal.h
> +++ b/libnm-core/nm-core-types-internal.h
> @@ -31,6 +31,31 @@ typedef struct {
> guint32 to;
> } NMVlanQosMapping;
>
> +typedef struct {
> + NMIPAddr ip;
> + guint8 family;
> + guint8 cidr;
Just a nitpick, feel free to ignore, but perhaps 'mask' would be a
better name than 'cidr'.
> [...]
> @@ -7103,6 +7416,8 @@ constructed (GObject *_object)
> g_assert (!nle);
> _LOGD ("Generic netlink socket established: port=%u, fd=%d",
> nl_socket_get_local_port (priv->genlh), nl_socket_get_fd (priv->genlh));
>
> + priv->wireguard_family_id = _support_genl_family (priv->genlh,
> "wireguard");
> +
Since the genl family id is already determined when needed (i.e. in
wireguard_get_link_properties()), I don't think we need to do it here
too.
> +void
> +nm_platform_lnk_wireguard_hash_update (const NMPlatformLnkWireguard *obj,
> NMHashState *h)
> +{
> + nm_hash_update_vals (h,
> + obj->private_key,
> + obj->public_key,
> + obj->listen_port,
> + obj->fwmark);
> +}
This gives the following compile error here:
CC src/platform/src_libNetworkManagerBase_la-nm-platform.lo
In file included from ./shared/nm-default.h:292,
from src/platform/nm-platform.c:21:
src/platform/nm-platform.c: In function ‘nm_platform_lnk_wireguard_hash_update’:
./shared/nm-utils/nm-hash-utils.h:121:57: error: initialization of ‘unsigned
char’ from ‘const guint8 *’ {aka ‘const unsigned char *’} makes integer from
pointer without a cast [-Werror=int-conversion]
#define _NM_HASH_COMBINE_VALS_val_x_4( y, ...) ._v4 = (y),
_NM_HASH_COMBINE_VALS_val_x_3 (__VA_ARGS__)
because private and public keys are guint8[]; I think you should use
nm_hash_update() for them.
The rest LGTM, thanks.
Beniamino
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
