esp8266arduino-esp8266esp8266wifi

ESP8266 chips using different encryption for softAP


I've got this curious case which I'm trying to make sense of. I use ESP8266 boards in a particular project of mine. There are smaller boards and larger boards, with other modules on them, purchased from different vendors. I don't think this plays much of a role, but fyi.

Now, the project itself involves the usage of ESP's softAP capabilities. A PC app of mine is built to connect and interact with the ESP when it is in softAP mode. I use the ESP8266 Arduino core on both board types, and I assume that the underlying Espressif SDK used is also the same. However, when I launch softAP on one board type, it uses AES encryption, whereas the other board type uses TKIP encryption. I know this because I have connected to both via Windows and then taken a peek at their Wi-Fi profiles. Sure enough, the ESP chip on one uses AES, while the other uses TKIP.

What I'm trying to determine is:

  1. What determines what encryption the chip uses?
  2. Is there a way to switch the encryption used? The Arduino core guys have said that they do not cover that in their core (here) and consulting the non-OS docs doesn't really provide any means of manipulating this. Section 3.5 mentions that AES is supported in softAP mode, and also states that "for the group key, only TKIP is supported" (docs here). I am not sure what this latter part means, if anyone could please clarify, but it doesn't seem like a concern seeing how one of my board types creates AES-encrypted connections, no problem. The only thing that one can provide when opening softAP is the authMode, which is simply a choice between WEP, WPA, WPA2, etc. Looking at the Arduino Core code, WPA2 is used. However, there is no obvious function/struct argument that manipulates the encryption used...

What options are there to change the behavior of the TKIP boards and force them to use AES when setting up a soft AP? Any suggestions or pointers (pun not intended) would be greatly appreciated!

Edit 1:

A day of tinkering later has allowed me to narrow the problem down. I am now using only one board. However, compiling and uploading different projects with identical configurations and Arduino core still causes different encryption types to be used by the softAP. Briefly, there are 2 projects:

  1. My main project which is too large to post here. It activates softAP when I press a physical button.
  2. A simple sketch that immediately turns on softAP and just loops without doing anything other than delay()-ing for several seconds to allow ESP to do its thing (see snippet below).
    #include <Arduino.h>
    #include <ESP8266WiFi.h>
    void setup()
    {
        unsigned long softApFlag = 0;
        IPAddress localIP(0x0201A8C0), gatewayIP(0x0101A8C0), subnet(0x00FFFFFF);
        Serial.begin(115200);
        delay(10000);
        Serial.printf("\nBEGIN***************");
        if ((WiFi.softAPConfig(localIP, gatewayIP, subnet)) == true) {
            softApFlag = 1;
            if ((WiFi.softAP((char*)"Big_SoftAP_Test", (char*)"1234567890")) == true)
            {
                softApFlag = 2;
            }
        }
    Mloop:
        printf("softAP flag = %d\x0d\x0a", softApFlag);
        delay(3000);
        goto Mloop;
        return;
    }
    void loop(){
    }

3 scenarios have been observed:

  1. My large project in its "natural" state causes softAP to use TKIP.
  2. The test sketch always uses AES in softAP mode.
  3. If I take the code from sketch 2, paste it at the very beginning of the large project and prevent the rest of the large project code from executing (I don't comment it out or remove it, but loop without doing anything as in the sketch), then I see 2 things. -- At first, I could not connect to the softAP from Windows. At all. A quick look at the Windows Event Viewer WLAN-AutoConfig records show it attempting to connect using AES, then using TKIP, but ultimately failing. Is there a 3rd encryption algorithm that's possible? Idk. -- After this, by removing excess bits of the large project that had accumulated over the past months, I managed to connect to this version's softAP via AES. I thought I'd cracked it, but removing the small sketch code and restoring the logic of the large project did not, however, retain this behavior, and the softAP started to use either TKIP, or stay unreachable once again...

It really is a messy case and my descriptions probably make little sense, but that's the long and the short of it.

Edit 2:

The problem still persists, but a couple of additional observations: on rare occasions, I do manage to connect to the softAP, if the Event Viewer is to be trusted. This only lasts a few seconds before the PC automatically disconnects.

Also, for some reason, my Android smartphone is much more reliable at locating the network and staying connected to it...


Solution

  • So, after a short while, it seems like the most satisfying conclusion that I could come up with is that there is simply something faulty about the board in question and attempts at pinpointing what it is were not really successful. After acquiring exactly the same board from a different vendor (which was also of visibly better quality), all of my tests/software worked smoothly from the get-go, and none of the issues I described above ever appeared, so it seems like there was something wrong with the hardware of the original board.