Re: [RFC] dbus: expose per-BSS security capabilities

Hi,

On 7/11/26 1:07 PM, Алексей wrote:
> Hi,
>
> NetworkManager cannot currently distinguish WPA2-Personal, WPA3-Personal,
> and WPA2/WPA3 transition networks when using its iwd backend.
>
> iwd has the required information internally.  scan_bss stores the WPA and
> RSN information elements, and scan_bss_get_rsn_info() exposes the parsed AKM
> and cipher information.  However, the stable D-Bus API reduces all of these
> personal network variants to Network.Type="psk".  BasicServiceSet currently
> exports only Address.
>
> This causes a concrete integration failure.  NetworkManager maps an iwd
> Network with Type="psk" to NM_802_11_AP_SEC_KEY_MGMT_PSK.  A saved NM profile
> with 802-11-wireless-security.key-mgmt="sae" then fails the normal AP/profile
> compatibility check and is removed from Device.AvailableConnections, even
> while iwd is successfully connected to the same network using SAE.
>
> Observed with NetworkManager 1.56.1 and iwd 3.12 on a WPA2/WPA3 transition
> network:
>
>    NM profile key-mgmt:       sae
>    iwd negotiated security:  WPA3-Personal + FT
>    NM AP RsnFlags:           0x188 (CCMP + PSK, no SAE)
>    NM AvailableConnections:  empty
>
> Would it be acceptable to extend net.connman.iwd.BasicServiceSet with stable
> WPA/RSN security capability information?
>
> The information needs to include at least:
>
>    - advertised AKM suites (PSK, FT-PSK, SAE, FT-SAE, and so on)
>    - pairwise and group ciphers
>    - management frame protection capability and requirement
>
> Per-BSS properties seem preferable to a Network-level value because BSSs in
> the same ESS may advertise different capabilities.  A consumer such as
> NetworkManager can aggregate the capabilities when presenting the iwd
> Network as one logical AP while leaving BSS selection and roaming to iwd.
>
> One possible API shape would be an extensible read-only RSN dictionary on
> BasicServiceSet, similar to:
>
>    RSN = {
>        "KeyManagement": ["psk", "sae", "ft-sae"],
>        "Pairwise": ["ccmp"],
>        "Group": "ccmp",
>        "ManagementFrameProtection": "optional"
>    }

Extending the BasicServiceSet interface to include these properties 
seems perfectly reasonable to me.

>
> The exact representation is the main subject of this RFC.  Raw suite
> selectors, separate properties, or an aggregate Network property may fit
> iwd's API conventions better.
>
> A corresponding NetworkManager change would consume these capabilities
> instead of synthesizing PSK-only RsnFlags from Network.Type.  Separately, NM
> should preserve an SAE-only profile policy in the generated iwd profile by
> using:
>
>    [Settings]
>    TransitionDisable=true
>    DisabledTransitionModes=personal
>
> Related reports and downstream investigation:
>
>    https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1489
>    https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1693
>    https://invent.kde.org/plasma/plasma-nm/-/merge_requests/571
>
> There was prior discussion indicating that additional BasicServiceSet
> properties are welcome when the data already exists in scan_bss:
>
>    https://lore.kernel.org/iwd/[email protected]/
>
> If this direction is acceptable, I can follow up with the D-Bus
> documentation, implementation, and tests after agreeing on the property
> format.
>
> Regards,
> Aleks
>
Thanks,

James