negativekelvin
commented
3 years ago Turn on debug logging for wpa supplicant
Closed jmgraeffe closed 3 years ago
negativekelvin
commented
3 years ago Turn on debug logging for wpa supplicant
sagb2015
commented
3 years ago @jmgraeffe As @negativekelvin you can turn of wpa debug logs and also the sniffer capture will help!
jmgraeffe
commented
3 years ago Damn, I thought the log above has it enabled already but clearly I saved the wrong thing.
I've an old part of a log which does contain the same error, but the esp-idf version used with that is pretty old: wpa2_failed.txt
Will do fresh logs on Monday and try to capture air traffic as well. But maybe the problem is known or you can find it in the old log already.
kapilkedawat
commented
3 years ago Hi @jmgraeffe
Please enable supplicant logging and mbedtls logging before you try to do fresh logs. We have moved to mbedtls based EAP client which provides better cipher supports in the latest IDF.
jmgraeffe
commented
3 years ago Hey, thanks so far. Here is the fresh log + tcpdump capture:
I'm starting to believe again that this is an infrastructure-related problem when wpa_supplicant is used. Some time ago, I tried the "non-working" credentials on Ubuntu 20.04 (no wpa_supplicant, I suppose) and they worked fine. Tested today again on a Debian system with wpa_supplicant and it didn't work, even though the "always-working" credentials worked fine...
sagb2015
commented
3 years ago Hi @jmgraeffe, from the logs its clear that the failure is during phase2 challenge-response phase of MSCHAPv2. This typically fails due to wrong credentials but there may be other reasons for it. So yes, this may be very setup specific, but to narrow down we will need more information. I am guessing it will not be possible for you to provide server side logs. In that case it will help to have wpa_supplicant logs in working case with Ubuntu (non-working credentials). Can you clarify what you mean by not having wpa_supplicant on ubuntu? One of the thing we want to check is that if authentication schemes are same in both the cases.
jmgraeffe
commented
3 years ago Can you clarify what you mean by not having wpa_supplicant on ubuntu?
I think I used the GUI on Ubuntu to connect, so maybe NetworkManager did not use wpa_supplicant as the backend. But we will try on Ubuntu again because it seems like the GUI is kind of unreliable/bugged. It might have never worked, because the NetworkManager might not have applied the saved settings and used the working credentials.
Sorry if this is really a login credential thing. The uni data center says it works, we can't get it to work, back and forth... ^^
sagb2015
commented
3 years ago @jmgraeffe If you are using GUI, please make sure to forget the network and then add the new credential after scanning the network. Also, when the credential is wrong, typically GUI front-end such as nm-applet takes time to reflect the exact status because it just relies on the association events rather than enterprise/4-way authenticated events. The right way to confirm, is to run some data traffic and see if the connection really happened. As mentioned before, mostly this is a credential issue but we can not be 100% sure unless we get the ubuntu logs. Btw, you can run the supplicant on ubuntu manually to see what is happening. Steps to do it -
1) Stop network-manager
2) Kill any background wpa_supplicant daemon running in background.
3) Start wpa_supplicant in foreground (-dd enables logging for supplicant).
wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf -dd
You may need to refer to wpa_supplicant manual for configuring for enterprise authentication (sample is typically present in default conf under comments). Let us know if you face any issues.
jmgraeffe
commented
3 years ago Not on Ubuntu but on an old Debian machine:
debian_wpa_supplicant_failure.txt
The working login credentials work fine with the exact same configuration file, which looks like this:
network={
ssid="OvGU-802.1X"
scan_ssid=1
key_mgmt=WPA-EAP
identity="miotr010"
password="<pass>"
eap=PEAP
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}@jmgraeffe The debian observation matches with ESP32 observation (phase2 failure). I was suggesting to repeat the experiment with ubuntu as well through command line instead of GUI, so we know why there is inconsistency.
EAP-PEAP: received Phase 2: code=1 identifier=14 length=11
EAP-PEAP: Phase 2 Request: type=33
EAP-TLV: Received TLVs - hexdump(len=6): 80 03 00 02 00 02
EAP-TLV: Result TLV - hexdump(len=2): 00 02
EAP-TLV: TLV Result - Failure Okay, after some testing it seems that PEAP+MSCHAPv2 does not work on any computer with the special accounts, while other accounts work. I think it's an infrastructure-related issue, which will be given to our data center and we'll see.
But it's getting more crazy now. The special accounts do work with TTLS+PAP on wpa_supplicant: debian_ttls_pap_success.txt
network={
ssid="OvGU-802.1X"
scan_ssid=1
key_mgmt=WPA-EAP
identity="miotr006"
password="<pass>"
eap=TTLS
phase2="auth=PAP"
}They do not work on the ESP32 with TTLS+PAP though: esp32_ttls_pap_failure.txt
jmgraeffe
commented
3 years ago It is confirmed that PEAP+MSCHAPv2 not working with some accounts is infrastructure-related. Apparently there are two Kerberos systems with each one serving a different protocol (PEAP+MSCHAPv2 and TTLS+PAP). The special accounts were only added to one of them by mistake.
However, this does not explain why TTLS+PAP does not work. But I found the following log entries in the esp32_ttls_pap_failure.txt and also logs where I used student accounts which worked from the beginning:
...
I (44134) wpa: TLS: Unsupported Phase2 EAP method 'PAP'
...
D (5040) wpa: EAP-PEAP: Start (server ver=0, own ver=1)
D (5050) wpa: EAP-PEAP: Using PEAP version 0
...This seems to indicate that PEAP is used instead of TTLS+PAP because PAP is not supported. Thus, the problem that caused PEAP to not work applied with TTLS+PAP chosen in idf.py menuconfig too.
Is this expected behavior? If yes, it may be better to just remove it from the example.
jmgraeffe
commented
3 years ago Since the last problem is not really related to the original issue anymore and this issue seems to be abandoned already, I created a new issue for it: #7011
But thanks for the help! I really appreciated it.
Environment
git describe --tagsto find it): // v4.4-dev-744-g1cb31e509xtensa-esp32-elf-gcc --versionto find it): // xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0Problem Description
Expected Behavior
Connection to WPA2 Enterprise network (at university but not eduroam) can be established successfully with any valid login credentials using PEAP MSCHAPv2.
Actual Behavior
Weirdly, connecting works only with certain login credentials / accounts (personal uni accounts work but not special ones issued for a specific project) even though using the non-working username/password on Ubuntu 20.04 or Android works perfectly fine with same settings.
This could very well be a problem related to the infrastructure at place, but I don't have the knowledge nor time to figure that out.
Steps to reproduce
idf.py menuconfigand do all example-related settings, enter login credentialsidf.py build flash monitorNothing is connected to the ESP32 itself and it's powered over USB.
Code to reproduce this issue
Example in
examples/wifi/wpa2_enterprisewas used.Debug Logs
Actual log (while using valid username/password not working on ESP32)
Expected log (while using valid username/password which are indeed working on ESP32)
Other items if possible
[x] sdkconfig file (attach the sdkconfig file from your project folder)
sdkconfig.txt
[ ] elf file in the
buildfolderDue to "in-production" passphrases this is not possible right now. But I guess it's not needed anyway since it's just the example code with the provided
sdkconfig.[ ] coredump (This provides stacks of tasks.)
Can do on request in PM or so.
If you need anything else, like some packet sniffing with Wireshark, no problem.