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.

3
  • 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, 2018 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. Apr 13, 2018 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, 2018 at 5:51

1 Answer 1

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.

6
  • 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, 2018 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, 2018 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, 2018 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, 2018 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, 2018 at 22:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .