On Thu, 2021-05-27 at 21:40 +0300, Emmanuel Grumbach via networkmanager-list wrote:
Disclaimer: This feature is available only on vPRO Platforms. Question to the NM maintainers: Would you consider merging patches that would implement this?
Definitely. The most important property for implementing a feature is that the underlying dependencies are also open soure and merged upstream. In this case, the requirement is that (upstream) kernel and (upstream) wpa_supplicant can support this feature -- or at least, there is a real possibility that it will support it in the future. That you need a special hardware is fine. It however poses a practical problem if upstream contributors cannot test/contribute to it. It basically means that those contibutors who care about this feature (and can test it) need to carry more burden than usual.
Do you see any blocker to implement this?
Maybe the handling of RFKILL in NetworkManager requires some cleanup first. That would be in `src/core/nm-manager.c` and `src/core/rf-kill- manager.c`. Your description is very detailed. Thank you. It does not sound entirely trivial to me however :). NetworkManager is mostly about having connection profiles and activating them. It's not clear to me how this ATM fits with that model. Would the user still configure a connection profile? Should a connection profile be auto-generated (there are cases where wo do that, for example for bluetooth paired devices).
Any recommendation for the implementation?
NetworkManager does talk relatively little nl80211 to kernel. Mostly it only configures wpa_supplicant. And most things happen when "activating" a profile in NetworkManager. I don't have concrete suggestions. Did you look at NetworkManager alraeady? Maybe we can find first "simpler" steps and break this down? best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part