802.1X connection debugging

[rallysmith]

I have another device connecting to a EAP 802.1X access point successfully with the following wpa_supplicant configuration:

Code: Select all

network={
  ssid="myTestSSID"
  scan_ssid=1
  key_mgmt=WPA-EAP
  group=CCMP TKIP
  eap=TLS
  identity="user"
  ca_cert="/etc/wpa_supplicant/ca-chain.cert.pem"
  client_cert="/etc/wpa_supplicant/cert.pem"
  private_key="/etc/wpa_supplicant/key.pem"
}

However, if I try and connect from a ESP32 doing the esp_wifi_set_*() setup calls (derived from the esp-idf/examples/wifi/wpa2_enterprise example) using the information from above that I can provide via that API (e.g. pem files, "user", SSID) I get:

Code: Select all

I (1216) wpa: WPA2 ENTERPRISE VERSION: [v2.0] enable
I (10496) wifi: n:7 2, o:7 0, ap:7 2, sta:7 0, prof:7
I (10506) wifi: state: init -> auth (b0)
I (10506) wifi: state: auth -> assoc (0)
I (11516) wifi: state: assoc -> init (4)
I (11516) wifi: n:7 0, o:7 2, ap:7 2, sta:7 0, prof:7

and the association fails with "reason 4". There does not seem to be any output from the hostapd acting as the access point to indicate that authentication against that AP has started.

Is there any documentation covering deciphering the WiFi supplicant output from the binary-blob-library that would shed some light on what the actual failure is?

[rallysmith]

From some packet capturing it seems the system does not proceed past the initial Authentication/Association packets. This looks to be because the ESP32 Association packet has tag 221 00:50:F2 type 1 entry with the AuthKeyMgmt type set to PSK (2) and not type WPA (1) as needed by the access point.

So, am I missing something obvious in the exposed libwpa2.a library API that would enable the authentication to proceed with the correct WPA (1) setting? or is it a known limitation of the current supplied ESP32 binaries?

[rallysmith]

(FYI: I cannot change the access point side configuration since in the field I have no control or influence over those access point setups; and the new ESP32 product needs to connect to an already rolled out set of access points. I cannot downgrade or change the security of the installed AP units; and if I cannot connect from the ESP32 then the product design is dead in the water. Just wanted to avoid any suggestions that may or may not be forthcoming suggesting a different AP setup )

So the initial test access point I was using is definately unhappy with the ESP32 code using AuthKeyMgmt type set to PSK (2) and the association would not proceed.

So I tried a completely different manufacturer access point using with the same EAP-TLS world (certificates, et-al) as required and usefully that implementation does allow the handshaking to continue even though the ESP32 code is stating PSK (2) instead of WPA (1). HOWEVER the ESP32 unfortunately SEGVs with a bad memory access during the x509 certificate checking. Irrespective of the certificate contents the code should not fault.

It looks like a bad pointer for the base is passed into the crypto_mod_exp() function (which is one of the few pieces of source available) so I could add some diag output to dump the passed pointers:

Code: Select all

crypto_mod_exp: base 0x00000001 power 0x3FFCF8F0 modulus 0x3FFC8274
Guru Meditation Error: Core  1 panic'ed (LoadProhibited)
. Exception was unhandled.
Core 1 register dump:
PC      : 0x4012bdc1  PS      : 0x00060330  A0      : 0x8012cafc  A1      : 0x3ffc8170  
0x4012bdc1: mp_read_unsigned_bin at /mnt/md0/jsmith/work/external/esp32/local_test/esp-idf/components/wpa_supplicant/src/crypto/libtommath.h:990

A2      : 0x3ffc5bac  A3      : 0x00000001  A4      : 0x3ffcf8ec  A5      : 0x3ffcf8eb  
A6      : 0x00000000  A7      : 0x3ffc80db  A8      : 0x8012bdbf  A9      : 0x3ffc8150  
A10     : 0x00000000  A11     : 0x00000008  A12     : 0x3ffc5bac  A13     : 0x00000000  
A14     : 0x3ffc80d9  A15     : 0x00000020  SAR     : 0x00000018  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000001  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000  

Backtrace: 0x4012bdc1:0x3ffc8170 0x4012caf9:0x3ffc8190 0x4012b56a:0x3ffc81b0 0x4010dd35:0x3ffc81f0 0x4010df2f:0x3ffc82a0 0x4010abca:0x3ffc8370 0x4010afc1:0x3ffc83b0 0x4010a22d:0x3ffc8430 0x40109c96:0x3ffc8480 0x40109cf9:0x3ffc84c0 0x401082a8:0x3ffc84e0 0x401088c9:0x3ffc8520 0x40105f41:0x3ffc8570 0x401062a5:0x3ffc85b0

The base pointer 0x00000001 looks very suspicious.

The backtrace for anyone inside Espressif that may be able to check their implementation without me having to trawl through an objdump disassembly to narrow down the actual failure:

Code: Select all

wpa2Task + 313
eap_sm_process_request + 201
eap_peer_tls_phase2_nak + ?
eap_peer_tls_process_helper + 120
tls_connection_handshake + 13
tls_connection_handshake2 + 54
tlsv1_client_handshake + 401
tlsv1_client_process_handshake + 893
tlsv1_client_set_cred + ?
x509_certificate_chain_validate + 263
x509_certificate_check_signature + 613
crypto_mod_exp (.../esp-idf/components/wpa_supplicant/src/crypto/crypto_internal-modexp.c:40)
bignum_set_unsigned_bin (.../esp-idf/components/wpa_supplicant/src/crypto/bignum.c:114)
mp_read_unsigned_bin (.../esp-idf/components/wpa_supplicant/src/crypto/libtommath.h:990)

Is there actually anyone inside Espressif monitoring this forum? with access to the relevant sources that can confirm how to affect the AuthKeyMgmt value so that WPA (1) can be set? and who may also be able to shed light on the memory de-reference bug?