networkmanager: ensure Wi-Fi VIFs are created before NM activates con…

[WeiZhang-stone]

networkmanager: ensure Wi-Fi VIFs are created before NM activates connections

The wireless driver typically creates only the base STA interface
(e.g., wlP4p1s0) at probe time. NetworkManager does not create
Wi-Fi interfaces - it only manages existing ones. In multi-VIF
deployments (e.g., AP+AP+STA), the connection profiles reference
VIFs that do not exist at boot, causing NM to fail activating
these connections.

Add a systemd oneshot service to create the required VIFs before NM
activates the connections. The service is not enabled by default.
When enabled, it tries to wait for the STA to connect first before
creating AP VIFs, avoiding mutual interference between AP operation
and STA's scanning/association process on the shared radio.

[lumag]

• Drop Gerrit tag
• Describe the problem you are trying to solve first, before describing the solution.

[ricardosalveti]

Drop this and add SDPX / Copyright.

[WeiZhang-stone]

Sure，will update in v2.

[ricardosalveti]

networkmanager: ensure Wi-Fi VIFs are created before NM activates connections

Add a systemd oneshot service and helper script to create Wi-Fi virtual interfaces based on NetworkManager profiles.

The service waits for the base STA interface to be connected and creates additional VIFs in a controlled order, avoiding race conditions during NetworkManager startup.

Why is this needed? Please explain the issue that caused this change to be proposed.

[WeiZhang-stone]

Thank you for the review.

Describe the problem you are trying to solve first, before describing
the solution.

Why is this needed? Please explain the issue that caused this change
to be proposed.

Sure, here is the background:

On ath11k/ath12k platforms, the wireless driver only creates the base
STA interface (e.g., wlP4p1s0) at probe time — no additional virtual
interfaces are created automatically. NetworkManager itself does not
create Wi-Fi interfaces either; it only manages interfaces that
already exist in the system.

In multi-interface deployments such as AP+AP+STA, the AP connection
profiles under /etc/NetworkManager/system-connections/ reference
additional VIFs (e.g., wlP4p1s1, wlP4p1s2) that do not exist at
boot. When NM starts, it fails to activate these profiles because the
required interfaces are missing.

This systemd oneshot service fills the gap by creating the required
VIFs before NM activates the connections. Since ath11k/ath12k supports
a maximum of two concurrent channels, STA and AP sharing a channel is
a common scenario. The service tries to ensure the STA connects first
before creating the AP VIFs, to avoid the STA's full-channel scan
disrupting the AP's beacon transmission if the AP were brought up
first, and also to minimize the impact of a running AP on the STA's
scanning, authentication and association process, which could
otherwise lead to connection failures.

I will update the commit message accordingly in v2.

[ricardosalveti]

Change-Id is still there.

[ricardosalveti]

Can we restrict this only for ath11k/ath12k?

[WeiZhang-stone]

Can we restrict this only for ath11k/ath12k?

The issue this service addresses is not specific to ath11k/ath12k.
Creating multiple VIFs is a user-space decision, and the fact that
VIFs referenced by NM connection profiles do not exist before NM
starts is a general scenario that applies to any wireless driver.

The typical use case is: the user configures multiple VIFs and
connections (e.g., STA+AP+AP) at initial setup. After a reboot,
NetworkManager already has these connection profiles stored and
should be able to re-activate them automatically — just like a
regular PC reconnects to a saved Wi-Fi network without user
intervention. However, since the additional VIFs do not survive a
reboot, NM cannot find the interfaces and the connections fail.

This service is not enabled by default — it is an opt-in option.
Users who already have their own apps or scripts to recreate VIFs
on every boot can simply leave it disabled. For users who prefer
the system to handle this automatically, they can choose to enable
it. Our current customers have requested this behavior.

Keeping it generic would allow any platform to benefit from it,
rather than limiting a driver-agnostic solution to specific hardware.

Thanks,
Stone

[WeiZhang-stone]

I will update the commit message in v3 to remove the ath11k/ath12k
specific wording and reflect the driver-agnostic nature of this service.

Thanks,
Stone

[ricardosalveti]

If really generic this should not be qcom specific change, so it would be material for either NM or meta-oe.

[WeiZhang-stone]

If really generic this should not be qcom specific change, so it would be material for either NM or meta-oe.

Apologies for the misleading description earlier. Let me clarify:

Creating VIFs for NetworkManager before it starts is a general
need — NM only manages existing interfaces and does not create
them. This applies to any wireless driver, not just ath11k/ath12k.

The script contains logic driven by ath11k/ath12k interface
combination constraints. For example, ath11k/ath12k does not
allow creating three STA-mode interfaces simultaneously, so when
two additional VIFs are needed, the script must create the AP-mode
interface as the second one. This VIF creation order and mode
selection logic is tied to the driver's combination rules.

Thanks,
Stone

[ricardosalveti]

If really generic this should not be qcom specific change, so it would be material for either NM or meta-oe.

Apologies for the misleading description earlier. Let me clarify:

Creating VIFs for NetworkManager before it starts is a general need — NM only manages existing interfaces and does not create them. This applies to any wireless driver, not just ath11k/ath12k.

The script contains logic driven by ath11k/ath12k interface combination constraints. For example, ath11k/ath12k does not allow creating three STA-mode interfaces simultaneously, so when two additional VIFs are needed, the script must create the AP-mode interface as the second one. This VIF creation order and mode selection logic is tied to the driver's combination rules.

Thanks, Stone

Then explain this as part of the commit message and also add a comment inside the script explaining the logic and the reasoning for the script.

[lumag]

If really generic this should not be qcom specific change, so it would be material for either NM or meta-oe.

The script contains logic driven by ath11k/ath12k interface combination constraints. For example, ath11k/ath12k does not allow creating three STA-mode interfaces simultaneously, so when two additional VIFs are needed, the script must create the AP-mode interface as the second one. This VIF creation order and mode selection logic is tied to the driver's combination rules.

Both ath11k and ath12k cards can be found on non-Qualcomm platforms. The script should be generalized and pushed upstream.