2012/11/13 Balint Reczey <rbal...@gmail.com>: ... >>> In an eduroam environment (which is basically WPA-Enterprise), I can >>> confirm disconnects without the possibility to reconnect when using >>> wpa_supplicant wit network-manager. Killing and restarting >>> wpa_supplicant allows a temporary reconnect. Please try to collect the capture file using wireshark about the issue happening and post the releavant part. It seems there are multiple issues merged together.
>> >> This is >> http://w1.fi/bugz/show_bug.cgi?id=447 >> respectively >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668612 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561081 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574714 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579297 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667706 >> >>> When researching the problem, I found this posting: >>> >>> https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/429370/comments/19 >>> >>> It states that the problem may be actually an openssl bug which lets the >>> rekeying >>> process fail permamently, and recommended recompiling with gnutls instead >>> of >>> openssl. I did this: >> >> […] >> >> The problem with this suggestion and the according patch, is that it >> switches from one (known) set of bugs to another (unknown) one. While >> linking to gnutls is supported upstream, none of the major >> distributions (not even Ubuntu) actually does so, which makes it pretty >> much untested in practice. Even if we wanted to switch to gnutls, doing >> so simply isn't possible at this stage of Debian's release process and >> in freeze*. >> >> *) However technically speaking, we can't switch to gnutls anytime >> soon, because gnutls doesn't provide an udeb, which is needed for >> using wpa_supplicant by the Debian installer (d-i). While your >> package build against gnutls succeeded, you have most likely ended >> with an unsatisfiable (in the d-i/ udeb context) dependency on >> libgnutls26-udeb for wpasupplicant-udeb_*.udeb (dpkg-gensymbols >> employs very crude heuristics to construct the dependencies for >> udeb packages without actually having access to a udeb context). >> >> […] >>> >>> and have been testing the modified package for about a month now, the >>> frequent disconnects have completely disappeared. >>> >>> The right place for a real fix would probably be openssl, but the >>> problem does not seem to be addressed or sufficiently researched there, >>> so the workaround by using gnutls instead of openssl gnutls seems to be >>> the best option for now. >> >> […] >> >> At this moment it is not obvious to me if wpa_supplicant is broken, or >> if some popular commercial wlan installations used for eduroam >> institutions are to blame. While, given the ubiquity and prevalence of >> this issue in academic environments, it might be possible that >> wpa_supplicant may need to work around the problem, however this would >> best be fixed at wpa_supplicant's upstream. Unfortunately none of the >> current wpa maintainers for Debian has access to an affected wlan setup >> in order to try to reproduce the problem, nor has enough information to >> recreate an affected EAP/ PAP setup for debugging, which significantly >> reduces our abilities to help. Therefore it's probably best to engage >> with wpa_supplicant upstream to get this fixed once and for all. >> >> Regards >> Stefan Lippers-Hollmann > > Hi, > > Please see the attached patch fixing the problem while not breaking other > use cases. > > The fix turns off listing the SessionTicket TLS extension in every second > hello packet allowing broken servers to accept the connection. > > Log: > 1 0.000000000 Apple_ee:ee:ee -> Procurve_aa:aa:aa EAP 30 Response, Identity > 3 0.060381000 Procurve_aa:aa:aa -> Apple_ee:ee:ee EAP 60 Request, Protected > EAP (EAP-PEAP) > 4 0.060918000 Apple_ee:ee:ee -> Procurve_aa:aa:aa SSL 249 Client Hello > 5 0.111778000 Procurve_aa:aa:aa -> Apple_ee:ee:ee TLSv1 60 Alert (Level: > Fatal, Description: Bad Certificate) > 6 0.112140000 Apple_ee:ee:ee -> Procurve_aa:aa:aa EAP 24 Response, Protected > EAP (EAP-PEAP) > 7 0.163244000 Procurve_aa:aa:aa -> Apple_ee:ee:ee EAP 60 Failure > 8 0.745350000 Procurve_aa:aa:ab -> Apple_ee:ee:ee EAP 60 Request, Identity > 9 0.745615000 Apple_ee:ee:ee -> Procurve_aa:aa:ab EAP 30 Response, Identity > 10 0.809622000 Procurve_aa:aa:ab -> Apple_ee:ee:ee EAP 60 Request, Protected > EAP (EAP-PEAP) > 11 0.810101000 Apple_ee:ee:ee -> Procurve_aa:aa:ab SSL 245 Client Hello > 12 0.901729000 Procurve_aa:aa:ab -> Apple_ee:ee:ee EAP 918 Request, > Protected EAP (EAP-PEAP) > 13 0.901942000 Apple_ee:ee:ee -> Procurve_aa:aa:ab EAP 24 Response, > Protected EAP (EAP-PEAP) > > > As you can see the first hello is longer due to the extension and has been > rejected by the buggy server. > The second connection attempt has not listed the extension and has been > accepted by the buggy server - which happens to run on a different host. > > Please forward the patch upstream as well, I did not want to register to > their bugzilla for this single patch. > > IMO this fix is needed in Wheezy, but I did not want to push the priority > higher on my own. Klaus pointed out correctly in a private email that the fix covers only PEAP. It definitely fixed the issue for me, but please see the fix covering all methods using TLS attached. Cheers, Balint
tls-fallback-session-ticket-disable.patch
Description: Binary data
