Hi, > You are right, if network managers run both on the host and the guest, they may > conflict. In our scenario, since we focus on highly integrated VM (such as Windows > Subsystem for Linux), we avoid the issue by disabling network management in the > guest. This leave us with only connection requests from programs targeting > specific networks coming from the guest. Right, I guess that makes sense. Though I don't know if there even are any common APIs in Linux, you'd probably have APIs for NetworkManager and other connection managers, but I'm not aware of a common API that applications would use. In fact, I know of very few *applications* that try to do WiFi related things, mostly those are network managers of sorts. Maybe some would show scan results, wireshark can set monitor mode and switch channels, etc. but still... Are there any specific applications you're thinking of? > I guess other policies could also be implemented by the host component, > depending on the degree of control one want the guest to have: either disabling > the host network manager, or defining some priority and dropping unwanted > requests... Right. > Your initial understanding was correct, network selection in Windows is mostly > implemented in a OS service (wlansvc), not an application. However, the proxy > host component is just an application that calls this service public API. So, > from the point of view of wlansvc and the host OS, the guest is "just" another > application as far as the Wi-Fi control path is concerned. Right, makes sense. > Thanks for explaining for in details, I think I understand better your idea. > All nl80211 messages being forwarded to the host would indeed add a lot of > complexity to the host device implementation, a lot of the processing done by > cfg80211 would likely have to be re-implemented. The good thing is there *isn't* a lot of processing in cfg80211 to start with :) OK, there's more now with the 6E scan processing, but still. > I imagine it would give more freedom to the host device implementation, too. Agree. > This could be an interesting alternative if a full-mac based implementation > ends up being too restrictive. Well it's kind of "full-MAC" either way - I was just thinking we could save some code on the guest side :) But, TBH, it's probably better integrated if we do have a proper driver there and actually see what's going on and how it interfaces with nl80211, rather than hiding all those bits in the host (device) implementation. > Based on the discussion, your recommendations concerning our initial questions seem to be: > - we should create a new driver, rather than modifying virt_wifi Yes, for sure, I don't think virt_wifi makes sense. > - netlink could be used as a protocol to communicate with the host That was just a thought really. I've done it before for hwsim's wmediumd virtio abstraction, and it's not all that bad, but you could just as well declare structs for communication and go that simple way. Might over time end up with more compatibility code on the device side though (assuming you want to keep old Linux kernels running) Ultimately, it doesn't really matter to us - I'd think of it as a device, and people come up with all kinds of strange hardware all the time ;-) (I even once briefly considered ASN.1 for communication with the Intel NICs :-) ) johannes
