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 _______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel