0

I am having terrible trouble connecting to my school WPA2 PEAP MSCHAPV2 wifi. I've tried Network Manager, wicd and connman and most recently I am connecting via wpa_supplicant.

The school does not require a CA certificate. I know this is ill-advised but I don't have responsibility for that. The connection works immediately in Windows, with which I dual boot, so I know the hardware is working.

I have included dmesg output, wpa_supplicant.conf, wpa_supplicant -dd debug output, and relevant wireshark packets in this Google doc:

https://docs.google.com/document/d/1HawjC5BS5BHBb5zxFUcWR4TInAhZXVDdt7ReGW0LiKg

The problem occurs after the Client Hello when the AP disconnects because of a handshake failure.

I have been working for days on this and have tried the system-ca-certs=false workaround. Any pointers would be gratefully received.

Update:

I notice that Wireshark says that the client hello is TLS version 1.0. I believe this is deprecated now? Does anyone know how to force the use of TLS 1.1 or 1.2 in the handshake? I will keep researching.

This post suggests that there are servers that will drop the connection if the client doesn't specify a TLS version higher than 1.0.

https://security.stackexchange.com/questions/29314/what-is-the-significance-of-the-version-field-in-a-tls-1-1-clienthello-message

New update:

Looking at the Wireshark packets from my Ubuntu laptop, which connects successfully, I can see that server negotiates a cipher suite (tls_rsa_with_3des_ede_cbc_sh) that Debian doesn't support. I originally thought this could be the problem, but oddly, when Windows connects the server negotiates a different cipher suite that Debian does support.

  • Would you mind being more specific? I don't see how there are three protocol directives. Perhaps you missed the fact that all but one of them are commented out. I will change the file to clarify. – retrosnob Apr 13 '18 at 4:47
  • As you prevented people copying from your doc, I suggest you post the relevant tidbits in the question. I wont be losing time trying to circumvent that. – Rui F Ribeiro Apr 13 '18 at 13:16
  • Ok. Thanks for the suggestion. I have enabled copying and highlighted what I think are the most relevant parts in red, although someone who knows more than I do may see other parts as relevant. – retrosnob Apr 15 '18 at 5:51
0

Try a more minimal WPA Supplicant configuration. The one I use is given here: https://chiraag.nataraj.us/wireless/index.php (specifically under the WPA-EAP subsection)

Almost certainly, the issue is with the WPA Supplicant config.

  • That looks like a great article. Thanks. I'll go through it and post any results. I've tried totally minimal wpa_supplicant configs and I know pretty well now what the defaults are. The reason that I think it's almost certainly not a wpa_supplicant problem is that I have configured my Debian machine in exactly the same way as my Ubuntu laptop, both using Network Manager, and Ubuntu connects and Debian doesn't. Anyway, I'll keep hammering away. – retrosnob Apr 18 '18 at 22:44
  • I would also try using Wicd or systemd-networkd + wpa_supplicant instead of Network Manager - I know I used to have a ton of problems back when I used it. – Chiraag Apr 20 '18 at 0:50
  • I've tried everything with respect to network manager, wicd, connman and wpa_supplicant on its own. I get a handshake failure at the client hello stage. I have added details to the question. – retrosnob Apr 27 '18 at 1:53
  • Which cipher suite does Windows use? You might be able to force that option in the WPA Supplicant configuration. – Chiraag Apr 28 '18 at 2:35
  • If they have a common cipher suite they should find it, no? In any case, I don't see a way of forcing the cipher suite in WPA Supplicant. – retrosnob May 6 '18 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.