WPA2-Enterprise with RADIUS Authentication (IEEE 802.1X)

[hheinreich]

I'm trying to add support for WPA2-Enterprise with RADIUS Authentication (IEEE 802.1X). I can make the ESP32 connect to such a network with everything hard coded as in the attached example. main.zip

If you do not have time to add this functionality, I understand. I'm trying to modify the AUTOCONNECT_URI_CONNECT section to add additional inputs for EAP_ANONYMOUS_IDENTITY, EAP_IDENTITY, EAP_ANONYMOUS_IDENTITY.

I think it would be possible to add an enable WPA2-Enterprise checkbox similar to enable DHCP and when enabled three additional input become available (EAP_ANONYMOUS_IDENTITY, EAP_IDENTITY, EAP_ANONYMOUS_IDENTITY).

What do you think?

Thanks for your time!

[Hieromon]

@hheinreich Thank you for your wonderful suggestions. I either had predicted that it would come a time to support authentication in the WPA2 enterprise.

But in my experience, the ESP8266 SDK failed in combination with some RADIUS servers. I don't know what's going on with the latest SDK, so my understanding is that there is still something missing in the SDK.

As far as the current SDK is used, it seems to fit WAP2 Enterprise by relying on the following sequences:

ESP8266

const char* identity = "foo@bar.com";
const char* username = "username";
const char* password = "password";
wifi_station_set_wpa2_enterprise_auth(1);
wifi_station_clear_cert_key();
wifi_station_clear_enterprise_ca_cert();
wifi_station_clear_enterprise_identity();
wifi_station_clear_enterprise_username();
wifi_station_clear_enterprise_password();
wifi_station_clear_enterprise_new_password();
wifi_station_set_enterprise_identity((uint8*)identity, strlen(identity));
wifi_station_set_enterprise_username((uint8*)username, strlen(username));
wifi_station_set_enterprise_password((uint8*)password, strlen(password));

ESP32

#define EAP_IDENTITY "foo@bar.com"
#define EAP_USERNAME "username"
#define EAP_PASSWORD "password"
esp_wifi_sta_wpa2_ent_set_identity((uint8_t *)EAP_IDENTITY, strlen(EAP_IDENTITY));
esp_wifi_sta_wpa2_ent_set_username((uint8_t *)EAP_USERNAME, strlen(EAP_USERNAME));
esp_wifi_sta_wpa2_ent_set_password((uint8_t *)EAP_PASSWORD, strlen(EAP_PASSWORD));
esp_wpa2_config_t config = WPA2_CONFIG_INIT_DEFAULT();
esp_wifi_sta_wpa2_ent_enable(&config);

As you can see, it's basically equivalent to your implementation code for ESP32. It doesn't make much difference on the ESP8266 either. Nevertheless, I can not be sure about these implementation sequences. How tested is the certainty of the code you provided?

Also, here we have three things to examine. It is also necessary to consider them to ensure backward compatibility.

1. User interface of the Config NEW
   This is not difficult.
   However, it seems that it is not necessary to equip two buttons like your suggestion.

2. AutoConnectCredential enhancement
   This could also be implemented.
   However, AutoConnect needs to be aware of the credentials saved in previous versions. It's a little tricky and requires some ingenuity

3. What happens to the current specification that is "if the 1st-WiFi.begin fails" ?
   The first WiFI.begin is an important specification for the AutoConnect. It guarantees a connection to the last AP, but the traditional WiFi.begin with PSK and the WiFi.begin for WPA2 Enterprise have different parameters. With PSK-based authentication, the SDK uses its own memory to try to connect by WiFi.begin() without the parameters, but AutoConnect must be WiFi.begin(LAST_SSID) for WPA2 enterprise support. (Of course with wpa2 pre-configuration) Therefore, AutoConnect needs to know that the last connection was a WPA2 enterprise.
   Please refer to the documentation of Inside AutoConnect::begin. How do you think the sequence of the AutoConnect::begin can be modified to complete WPA2-enterprise compliance?

[hheinreich]

Thank you for considering my suggestion. The WPA2 enterprise code has been tested at various locations around the world at Universities and additions to the code have come from suggestions of other WPA2 enterprise users. You may already be aware of the github project for Eduroam https://github.com/martinius96/ESP32-eduroam

EAP_IDENTITY "username@bar.com"
EAP_USERNAME "username"
EAP_PASSWORD "password"

1. You are correct that two inputs are not necessary. My thought for changing the interface was creating an input for EAP_IDENTITY since EAP_USERNAME can be parsed from it and EAP_PASSWORD could be stored in the passphrase field. So basically only one additional string is required for the connection.

   1.A Add in AutoConnectLabels.h
   // Page config text: Enable WPA2ENTERPRISE #ifndef AUTOCONNECT_PAGECONFIG_ENABLEDWPA2ENTERPRISE #define AUTOCONNECT_PAGECONFIG_ENABLEDWPA2ENTERPRISE "Enable WPA2 Enterprise" #endif // !AUTOCONNECT_PAGECONFIG_ENABLEDHCP

   1.B Add in AutoConnectPage.cpp
   "<li>" "<label for=\"wpa2enterprise\">" AUTOCONNECT_PAGECONFIG_ENABLEDWPA2ENTERPRISE "</label>" "<input id=\"wpa2enterprise\" type=\"checkbox\" name=\"WPA2-Enterprise\" value=\"en\" checked onclick=\"vsw(this.checked);\">" "</li>"

   1.C In AutoConnectCredential.h modify to include new field(s) and use it similar to the way you use uint8_t dhcp; (0:DHCP,1:Static IP)

    station_config_t;
    `uint8_t wpa2enterprise;   /**< 0: PSK, 1:WPA2 Enterprise */`
   
    AC_CREDTBODY_t;
    `uint8_t wpa2enterprise;   /**< 0: PSK, 1:WPA2 Enterprise */`
   

   1D. AutoConnect.cpp
   bool AutoConnect::begin(const char* ssid, const char* passphrase, const char* eapidentity, unsigned long timeout)

   1E. Losts of other code changes not yet considered........

2. If we are only storing one additional item EAP_IDENTITY can backward capability be achieved by handling it in the second WiFi.begin?

3. If the "1st-WiFi.begin fails" and eap is true, use the second one with the extra parameter WiFi.begin(c_ssid, c_password, c_eapidentity). If eap is false, then use it as is WiFi.begin(c_ssid, c_password).

There might be additional problems that I have not seen. It will be very interesting to hear your response. Thank you for your hard work.

[Hieromon]

If the API sequence for WPA2-Enterprise is what we envision, I can work generously on its implementation.

The layout of the Configure new AP page

I will add a new checkbox to enable WAP2-Enterprises according to your suggestion. If the EAP_IDENTITY input field appears according to the state of the checkbox, there will be less operational discomfort.

AutoConnectCredential backward compatibility

Ensuring backward compatibility of stored credentials must meet the requirements that the credential data stored by the previous version (which is stored in EEPROM or NVS) should be able to be read by the new version of AutoConnect without any problems. Otherwise, if the users recompile and upload the existing sketch with the new AutoConnect library version, they will not be able to reconnect using saved credentials.
I would like to enhance the current AutoConnectCredential structure as follows to ensure backward compatibility.

• uint8_t dhcp you mentioned gave me a hint. It will probably be split by a bit slice for EAP flag.
• eap_username and eap_identity are optional fields that grow to fit the actual string length.

However, this fix changes the declaration of station_config_t and may result in compilation errors in older sketches of users. But it guarantees that the old version of AutoConnectCredentail will work in the new AutoConnect version as well. I hope they will accept it.

typedef struct {
  uint8_t ssid[32];
  uint8_t password[64]; /**< Shared with PSK and EAP */
  uint8_t bssid[6];
  struct _sup {
    uint8_t dhcp  :1;
    uint8_t eap   :1;
    uint8_t       :6;
  } sup;  /**< criteria of supplicant */
  union _config {
    uint32_t  addr[5];
    struct _sta {
      uint32_t ip;
      uint32_t gateway;
      uint32_t netmask;
      uint32_t dns1;
      uint32_t dns2;
    } sta;
  } config;
  uint8_t eap_identity[0];  /**< EAP_IDENTITY */
  uint8_t eap_username[0];  /**< EAP_USERNAME */
} station_config_t;

NOTE
I chose to keep the EAP_IDENTITY and EAP_USERNAME separate, but I'm not sure if this is an appropriate way. The same is true on the Configure New AP page.
I'm not sure how these two functions in the SDK (esp_wifi_sta_wpa2_ent_set_identity and esp_wifi_sta_wpa2_ent_set_username) are associated with each EAP method (MD5, LEAP, EAP-FAST, TLS, TTLS, PEAP). I have read the ESP-IDF documentation but could not find a clear description. In the example sketch of ESP32, specify the same value for esp_wifi_sta_wpa2_ent_set_identity and esp_wifi_sta_wpa2_ent_set_username. After all, I'm not sure which authentication in the EAP methods are supported.
Does it mean that esp8266sdk and ESP-IDF only support some methods while saying EAP? Do you have any idea about this?

1st-WiFi.begin behaivor

I think the AutoConnect::begin interface specification will be met by your recommendations. Thank you.
However, the question still remains, "How can AutoConnect know that the AutoConnect::begin call of this time is required WPA2-Enterprise authentication?"

Now, I would like to consider a typical user sketch using AutoConnect. (A part of the setup section)

AutoConnect portal;
void setup() {
  portal.begin();
}

This API call causes AutoConnect to attempt WPA2-Enterprise authentication in the following sequence:
(It is partly written in pseudocode to make it easier to see.)

// Inside `AutoConnect::begin(void)`
WiFi.disconnect(true);
WiFi.mode(WIFI_STA);

// 1st-WiFi.begin. If the last connected AP has a PSK, it will connect fine, but was WPA2-Enterprise, it always fails.
WiFi.begin();

WAIT_FOR_CONNECT_WITH_TINEOUT();
if (WiFi.status() != WL_CONNECTED) {
  String ssid = SCAN_SSID(); // It scans broadcasted SSID.
  station_config_t& station_config = SEARCH_CREDENTIAL(ssid); // It finds a matching credential in the saved credentials.
  if (station_config.sup.eap == 1) { // for EAP
    esp_wifi_sta_wpa2_ent_set_identity(station_config.eap_identity, strlen((const char*)station_config.eap_identity));
    esp_wifi_sta_wpa2_ent_set_username(station_config.eap_identity, strlen((const char*)station_config.eap_identity));
    esp_wifi_sta_wpa2_ent_set_password(station_config.password, strlen((const char*)station_config.password));
    esp_wpa2_config_t config = WPA2_CONFIG_INIT_DEFAULT();
    esp_wifi_sta_wpa2_ent_enable(&config);
    WiFi.begin(station_config.ssid);
  }
  else { // for PSK
    WiFi.begin(station_config.ssid, station_config.password);
  }
}

If the last connected AP was WPA2-Enterprise, the 1st-WiFi.begin always fails. Is the above pseudo code as you expected?
If the 1st-WiFi.begin wants to detect WPA2-Enterprise authentication, the logic after SCAN_SSID() needs to proceed before that. It's very inefficient for users unrelated to WPA2-Enterprise

[hheinreich]

"How can AutoConnect know that the AutoConnect::begin call of this time is required WPA2-Enterprise authentication?"
I completely agree with maintaining backward compatibility with AutoConnectCredential. I also do not like the 1st-WiFi.begin always failing with WPA2 enterprise. Your pseudo code example is what I was thinking could be a solution. A credential check done earlier in the AutoConnect::begin logic sequence might be a better solution. I think it would make sense to do it immediately after the Load Current Config has completed. This way we should be able to avoid the first WiFi.begin failing, correct?

Does it mean that esp8266sdk and ESP-IDF only support some methods while saying EAP? Do you have any idea about this?
Extensible Authentication Protocol (EAP) methods are peap, tls, ttls, pwd, sim, aka, aka_prime
Phase2 methods are pap, mschap, mschapv2, gtc

You have probably already read the espressif documentation, but in case other people are reading this here is a link to it:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html#wpa2-enterprise

According to https://github.com/espressif/arduino-esp32/blob/master/tools/sdk/include/esp32/esp_wpa2.h
wpa2 enterprise authentication can only support TLS, PEAP-MSCHAPv2 and TTLS-MSCHAPv2 method.

> I chose to keep the EAP_IDENTITY and EAP_USERNAME separate, but I'm not sure if this is an appropriate way.
Keeping EAP_IDENTITY and EAP_USERNAME separate is a very good idea because they are NOT always the same.

SECRET_EAP_ID = "my-Enterprise-ID"                      // EAP_ID (typically the same as EAP_USERNAME, e.g. domain\\my-Enterprise-UserName) 
SECRET_EAP_USERNAME = "domain\\my-Enterprise-UserName"; // Username for authentification (typically the same as EAP_ID); consider trying also username@yourdomain.com
SECRET_EAP_PASSWORD = "my-Enterprise-Password";         // Password for authentication

I think forward progress is being made. If a full copy of IEEE 802.1X standard is required, let me know.

[Hieromon]

It seems I couldn't convey well to you my question about the proper logic sequence of the wap2 APIs that ESP-IDF has. I'm sorry, not good at English.

My question, again

My question stems from the determination of the specification of the UI design on the Configure NEW AP page. Initially, I thought it was enough to specify WPA2-Enterprise using a checkbox and a username.
However, I remembered that it was not enough for some authentication methods, and came up with the idea of what APIs sequence the combination of protocols and authentication methods supported by ESP-IDF should be translated.

The sample sketch you sent me is basically the same as the example sketch that comes with the Arduino-esp32, but this assumes a RADIUS server configured with PEAP + MSCHAPv2, I think. (maybe for Eduroam?, In the first place, there is no standard in PEAP. Only Microsoft or Cisco methods exist) How correct is my understanding?
On the other hand, AutoConnect supports simple OTA, which allows users to uploading a regular file into the ESP32's file system using AutoConenctOTA with a local network segment. Its file should be possible even with a client certificate. Therefore, it may be possible to support authentication methods that require a client certificate. (eg. EAP-TLS)

The example code attached to the ESP-IDF presents an API for handling CA and client certificates, which is embedded directly in the TXT block of the compiled binary.
If the user's environment is TTLS, which requires a client certificate, the example lacks a way to supply the certificate as an external file.
In addition, the identification of EAP identity and EAP username is ambiguous. I think that the environment in which authentication is possible with the combination of methods presented in the ESP-IDF example is limited.

So I was wondering, "Does it mean that esp8266sdk and ESP-IDF only support some methods while saying EAP?" (ESP-IDF documentation says "EAP-TLS: This is certificate based method and only requires SSID and EAP-IDF.", but How limitation?, What a API specification?)
I feel your knowledge will make up for my shortage.

So, the second candidate of the Configure New AP page

The choice of WPA2-Enterprise may need to have some hierarchical structure (to handle the esp-idf API properly)
Or, drop the certificate import from the AutoConnect WPA2-Enterprise feature. That is, it means that if the user omits entering the EAP username, the same value as the EAP identity will be used. I'm not sure how good it is.

[hheinreich]

The sample sketch you sent me is basically the same as the example sketch.......

You are correct about the example I provided. I used it as a quick way to test connecting using ESP32 to Eduroam at the University where I work. Eduroam is used globally and is combing with other companies forming The Wireless Broadband Alliance (WBA).

The pioneering companies – members of WBA – supporting the WBA OpenRoaming standards include: Airmesh, Airties, Aprecomm, American Tower, Aptilo, AT&T, Boingo Wireless, Broadcom Inc, Cisco, Cityroam, Comcast, Commscope, Deutsche Telekom, Eduroam, Eleven Software,GlobalReachTechnology, Google, GoZone Wi-Fi, Hub One, Hughes Systique Corp, Intel Corporation, IT&E, m3connect, Nomosphere, Orange, Purple Wi-Fi, Radiator Software, Samsung, Single Digits, Sun Global, Veniam, WifiCoin and Zephyrtel. Together these companies provide Wi-Fi services that reach billions of people and things.

It seems I couldn't convey well to you my question about the proper logic sequence of the wap2 APIs that ESP-IDF has. I'm sorry, not good at English.

No need to apologize because your English is good and more importantly your code is beautiful. My initial thought was mainly for enabling Eduroam support (RADIUS server configured with PEAP + MSCHAPv2) and that would be a good addition. It looks like the certificate support will be more difficult, but since Eduroam has joined the WBA OpenRoaming adding support for certificates "could" be considered a requirement.

Maybe first step will be a non-elegant solution forcing the end user add the certificate to their code manually like this example. A nicer solution would be to modify AutoConnect support for OTA and use it to allow users to upload a certificate file into the ESP32's file system.

The second candidate of the Configure New AP page

An additional configuration page might be needed for the WPA2-Enterprise and certificate options and another addition to the declaration of station_config_t with something like eapca to enable or disable certificate usage.

typedef struct {
  uint8_t ssid[32];
  uint8_t password[64]; /**< Shared with PSK and EAP */
  uint8_t bssid[6];
  struct _sup {
    uint8_t dhcp  :1;
    uint8_t eap   :1;
    uint8_t eapca :1;    
    uint8_t       :5;
  } sup;  /**< criteria of supplicant */
  union _config {
    uint32_t  addr[5];
    struct _sta {
      uint32_t ip;
      uint32_t gateway;
      uint32_t netmask;
      uint32_t dns1;
      uint32_t dns2;
    } sta;
  } config;
  uint8_t eap_identity[0];  /**< EAP_IDENTITY */
  uint8_t eap_username[0];  /**< EAP_USERNAME */
} station_config_t;

The added configuration page could resemble something similar to the following images:

[Hieromon]

This comment describes the policy regarding WAP2-Enterprise support in AutoConnect for ESP8266 platform.

I have tried to communization the API provided by AutoConnect between ESP8266 and ESP32 as much as possible but will give up the standardization of WAP2-Enterprise support in ESP8266.
Inspired by your suggestions, I checked the status of WPA2-Enterprise support on the ESP8266 Arduino core, and my perception had seemed a bit old.

Espressif has suspended WPA2-Enterprise support on the non-os SDK. And in the ESP8266 Arduino core based on it, it is unlikely that WPA2-Enterprise authentication will succeed no matter how Sketch uses any APIs currently. esp8266/Arduino#5784

And Espressif claims to focus on the ESP8266 RTOS SDK due to human resource limitations. (Refs) So as long as the ESP8266 Arduino core is based on the current non-os SDK, there is no way to WAP2-Enterprise authentication correctly. Therefore, AutoConnect focuses WAP2-Enterprise authentication support on the ESP32 only.

[Hieromon]

@hheinreich

I laid out the Configure New AP page with changes as follows to allow users to specify WAP2-Enterprise:

Collapsed	Expanded

I have placed the following restrictions on the WPA2-Enterprise configuration using the above page. I look forward to your advice on them.

• Only PEAP and EAP-TTLS can be selected with the EAP method:
  This limitation is due to AutoConnect not supporting certificate embedding for the time being. Therefore EAP-TLS is not supported. Also, you cannot import the client certificates, CA certificates as optional for other EAP methods.

• The validity of Phase 2 Authentication:
  Supports specifying Phase 2 authentication, as seen in the selection box on the laid out page above. It valid only for EAP-TTLS is selected. And AutoConnect does not check the validity of those combinations.

• EAP Identity field has dropped:
  It seems that ESP-IDF WPA2 enterprise support uses its ID as an anonymous ID for Phase 1 authentication after all. In this interpretation, it may be more appropriate to change the label for ID to User name. So, I may not have reached an accurate understanding. What do you think?

[hheinreich]

It looks good and I can test it on ESP32 at the University and provide debugs logs if you would like assistance. Will you be posting updated code?

[Hieromon]

@hheinreich
I'm working on implementing AutoConnect for WPA2 Enterprise, but the declaration header of esp_wifi_sta_wpa2_ent_set_ttls_phase2_method function for notifying IDF of Phase 2 authentication is not included in the ESP32 Arduino core distribution. Do you know where it is?
I might have been thinking a little easier about implementing WPA2 Enterprise. I've gone deep into the ESP32 Arduino core, but there's no sign that Phase 2 authentication is supported without embedding CA.
I feel that the current ESP32 Arduino core supports virtually limited to Eduroam. If so, we do not need to select the EAP method. What do you think about this?

[Hieromon]

I have staged the WAP2 Enterprise support on the development branch as enhance/wpa2e. Could you start the evaluation?
It has some restrictions for the evaluation as follows:

• PageBuilder v1.5.0 is required. Clone the repository to your local repository and activate enhancement/v150.
• Comment out line 46 in the PageBuilder.h header to enable the #define PB_USE_SPIFFS directive. LittleFS is not yet supported by the core for the Arduino ESP32.
• It has been Dropped the EAP method and Phase 2 authentication specifications on the Config New page. The ESP32 Arduino framework distribution does not include the esp_wifi_sta_wpa2_ent_set_ttls_phase2_method API required for Phase2 authentication. Therefore, its implementation is effectively limited to RADIUS authentication. (I can't tell how useful this is, maybe just for Eduroam after all)

Thank you for your contribution.

[hheinreich]

Thank you for all your efforts. I can test this change and see if Eduroam will function.

[Hieromon]

There is one thing I was missing to tell you.
You must define the AC_USE_WPA2E macro to enable WPA2 enterprise authentication with AutoConnect. Currently, its implementation exists in AutoConnect.h.

AutoConnect/src/AutoConnect.h

Lines 28 to 30 in e12855b

	#ifdef AC_USE_WPA2E
	#define AUTOCONNECT_USE_WPA2E
	#endif

Please insert the define directive as #define AC_USE_WPA2E after line 25 of AutoConnect.h.
Or, If you assume PlatformIO, you can define the directive with platformio.ini contains build_flags=-DAC_USE_WPA2E.

Also, WPA2 Enterprise support by the ESP-IDF has larger object sizes than expected. it will grow huge BIN size and may exceed the limit of the default partition. Please you consider changing the partition table to allow the object size.

[dumarjo]

Hi, This is very interesting,

I need this feature also. I will give it a try soon.

[dumarjo]

Hi @Hieromon ,

I tried the branch for the WPA2 enterprise and it's not working. something is missing in the workflow.

The major problem, is the credentials need to be saved in the preference before triyng to connect to the AP.

this line of code is not using the begin dispatcher, so it's impossible to be able to connect to WPA2.
https://github.com/Hieromon/AutoConnect/blob/enhance/wpa2e/src/AutoConnect.cpp#L520

Next thing is when I replace this line of code with this:

if (_wl.begin(ssid_c, password_c, ch) != WL_CONNECT_FAILED) {

The new method, read from NVS the config to call the correct begin for wpa2.
https://github.com/Hieromon/AutoConnect/blob/enhance/wpa2e/src/AutoConnect.cpp#L1575

Since _induceConnect (https://github.com/Hieromon/AutoConnect/blob/enhance/wpa2e/src/AutoConnect.cpp#L1197) don't save the config, the inv.load (https://github.com/Hieromon/AutoConnect/blob/enhance/wpa2e/src/AutoConnect.cpp#L1578) is failing and thus normal begin is called.

I'm not sure why the save of the creds is only done when the connect is successful. some time is good to pre-configure a device and then when the device is on the range of the AP it will work. So I thing the save creds is not very correct for now.

Do you have an Idea of how I can fix the save/load of creds to get this working ?

Regards,

Jonathan

[Hieromon]

@dumarjo Thank you for your testing. Your point below is justified. And I did it intentionally.

The major problem, is the credentials need to be saved in the preference before triyng to connect to the AP.

The question I had to solve was "How does AutoConnect know in advance that the authentication used to connect is WAP2ENT?" I couldn't find a reasonable answer to that. It was intended to coexist with non-WPA2ENT, but as a result, I chose "in the case of WPA2ENT, the method of intentionally failing the first WiFi.begin".

I fully understand that this is not the best way, but do you have any ideas on how to coexist with non-WPA2ENT? That method should pre-trigger the esp_wifi_sta_wpa2 configuration logic sequence.

[dumarjo]

with this PR, i'am able to get passed the need of saving the credentials. #370

But mabe I broke something else. I'm not enough experienced with your code for now.

[Hieromon]

@dumarjo OK. After completing the enhancement work for ESP8266 3.0.0 core conformance, I will try to merge your PR to master. It will come with a build switch to separate WPA2ENT and will be aimed at the degeneracy of BIN size.

[dumarjo]

Hi @Hieromon, Do you plan to add this feature to 1.3.0?

[Hieromon]

Hello @dumarjo, Well, actually, I'm still wondering if it should be included in v1.3.0.
I'm not confident in this implementation, also feel that ESP32 SDK's WAP2-Ent authentication is virtually exclusively focused on the eduroam.
For now, I plan to release ESP8266 Arduino 3.0.0 and ESP32 Arduino 2.0.0 compatible versions first. Officially support for WPA2-ENT will be planned after that.

[dumarjo]

hello @Hieromon any plan for 1.3.4 ?

I think most of the use of this is in college/university. So, this is very useful.

Regards,

[brooksbUWO]

I am wondering if WPA2-Enterprise has been added to your current version?

[brooksbUWO]

It looks like others have made progress connecting to WPA2-Enterprise and Eduroam.
For example please see:
https://github.com/martinius96/ESP32-eduroam
https://github.com/JeroenBeemster/ESP32-WPA2-enterprise
https://www.wolfssl.com/docs/espressif/

This will be very useful if it can be used with AutoConnect.