Hi Arend, >> If the wdev object has been created (via NEW_INTERFACE) with >> SOCKET_OWNER attribute set, then limit certain commands only to the >> process that created that wdev. >> This can be used to make sure no other process on the system interferes >> by sending unwanted scans, action frames or any other funny business. > > The flag is a good addition opposed to having handlers deal with it. However, earlier motivation for SOCKET_OWNER use was about netlink multicast being unreliable, which I can agree to. However, avoiding "funny business" is a different thing. Our testing infrastructure is doing all kind of funny business. Guess we will need to refrain from using any user-space wireless tools that use the SOCKET_OWNER attribute, but how do we know? Somehow I suspect iwd is one to avoid ;-) I have yet to give iwd a spin, but this SOCKET_OWNER strategy kept me from it. Maybe iwd could have a developer option which disables the use of the SOCKET_OWNER attribute. when running iwd, we expect reproducible behavior. Meaning we need to ensure that nobody else is messing with our interfaces behind our back. A testing infrastructure that does that is really no good in the first place since you yourself are introducing unclean behavior. When testing with iwd, we are testing the D-Bus API of iwd and you can at the same time take PCAP traces with iwmon. If we are able to store trace-cmd information also in the same PCAP file, we can extend iwmon to do exactly that. So far iwmon allows you to grab the netlink communication and the PAE communication which means you can easily analyze what was happening without having ask nl80211. If you require extra debug information or triggers, then this has to happen via a D-Bus debug interfaces. However I see no benefit of not using SOCKET_OWNER. As I said above, if the testing uses different options than the real environment, what good is the testing. Regards Marcel
