[Kde-hardware-devel] Wifi interface

[Stefan Winter]

> 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060816/12eb5f35/attachment.pgp