On Mon, Oct 03, 2022 at 09:04:47PM +0000, 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:


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:


> 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 



> -----Original Message-----
> From: Beniamino Galvani <bgalv...@redhat.com> 
> Sent: Monday, October 3, 2022 1:13 AM
> To: Charles Lohr <charl...@valvesoftware.com>
> Cc: 'networkmanager-list@gnome.org' <networkmanager-list@gnome.org>
> Subject: Re: Preventing network scans once connected via libnm
> On Sat, Oct 01, 2022 at 12:46:24AM +0000, 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-
>  ("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

Attachment: signature.asc
Description: PGP signature

networkmanager-list mailing list

Reply via email to