[Kde-hardware-devel] Wifi interface

Will Stephenson wstephenson at kde.org
Thu Sep 21 17:17:40 CEST 2006


On Wednesday 16 August 2006 18:05, Stefan Winter wrote:

> > 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).

Good project, reminds me of Mobile IP a bit, and I see your motivation for a 
connectivity check on AP switch.  I've made a TODO to investigate adding this 
to NetworkManager.  Look forward to meeting you again at akademy :).

Will


More information about the Kde-hardware-devel mailing list