> Just a minute! Solid itself isn't a background process, it's just a > library that wraps a backend. In the case of NetworkManager there is a > daemon that runs all the time and Solid uses for information.
Ah, ok. Hm, my understanding is if you want to do anything WPA-related, even WPA-PSK, you will always need to have something running constantly in the background, because of re-keying issues etc. So, even if Solid is just a library that passes things onto a backend, this backend needs to do the job of keeping the WiFi connection up. Or better put, every backend that claims to be able to handle WiFi must have a daemon that takes care of the ongoing connection. In an earlier post I wrote what I think is a way out for this: Solid could provide a slot testConnectivity(), where backend implementations do their stuff to find out if the connection still works (which means doing a ping in IP networks, but it could be anything else on other networks). If you now add some signal to inform of changes on ISO/OSI layer 2 (in the WiFi case: APChanged() or similar), and connect the two together, you're through: whenever something on the MAC layer changes, Solid asks the backend to check if things still work alright. If not, either the backend or Solid take action. > Could you explain what it is that you want it to achieve and that pissed > off your research project (coming from another ex wlan researcher)? The idea of the project is to provide seamless roaming in [academic] WLAN networks with strong authentication and encryption, i.e. WPA1/2-Enterprise with mutual authentication methods like EAP-TLS, EAP-TTLS, PEAP-MSCHAPv2. This in itself is already pretty hard to configure for a user. To keep the barrier as low as possible, we'd like to have the user configure the stuff only _once_ and then forget about it, but that requires that the SSID is the same on each PoP (encryption and auth properties are tied to the SSID and if the user would discover a new SSID he would have to go through the entire stuff again). I.e. the goal is to just open the laptop and wherever you are on the world, you'll get an instant connection, just like you are used to with your cell phone. [If you're curious, the credential verification is done with a hierarchy of RADIUS servers and the usernames contain realms that enable us to route your auth request to your home, wherever you are]. This is all fine and good and mostly works, but we face one problem: when two of the eduroam PoPs are close to each other (but independent, i.e. different IP subnets), and both emit "eduroam" as SSID, the client may jump back and forth but will keep its IP address, subnet and default gateway because the IP layer doesn't notice (or care) that something chagned. Connectivity is lost if he's at the "wrong" PoP, and his client won't issue a new DHCP request until it's lease has expired. And this is where testConnectivity() would jump in, make the backend detect that something's wrong and issue a new DHCP request (but that's of course the backend's job). To get back to "what pissed us off": it took a time to realize that a) some of our clients get really BAD connectivity, or none at all b) to get around it we have to set non-obvious SSIDs on places where PoPs overlap. Our current policy is that one of the overlapping sites can keep eduroam as SSID, all others in the vicinity need to go to "eduroam-institutionname" which is highly unsatisfactory for both users (need to reconfigure) and admins (need to explain). Greetings, Stefan -- The K Desktop Environment - Stefan Winter - Areas of Activity: kdenetwork/wifi (KWiFiManager) kde-i18n/de (German translation)
pgpswLbMENYf7.pgp
Description: PGP signature
_______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel