ESP32 WiFi encryption
Moderators: grovkillen, Stuntteam, TD-er
-
- Normal user
- Posts: 531
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
ESP32 WiFi encryption
ESPEasy_ESP32_mega-20211224
ESP32 module shows [Encryption Type: open]. Does it mean that the transmission to the AP is not encrypted?
The WiFi scan in the ESP Easy menu shows that the AP has WPA/WPA2/PSK encryption turned on.
This is shown in the first screenshot.
Interestingly, the ESP8266 module shows WPA/WPA2/PSK encryption tuned on, as in the attached second picture.
So how is it with encryption?
ESP32 module shows [Encryption Type: open]. Does it mean that the transmission to the AP is not encrypted?
The WiFi scan in the ESP Easy menu shows that the AP has WPA/WPA2/PSK encryption turned on.
This is shown in the first screenshot.
Interestingly, the ESP8266 module shows WPA/WPA2/PSK encryption tuned on, as in the attached second picture.
So how is it with encryption?
- Attachments
-
- Screenshot_20220104_173324.png (87.22 KiB) Viewed 7012 times
Re: ESP32 WiFi encryption
I think this is a bug.
The encryption is determined when performing a WiFi scan.
However if you reboot (no power cycle) and was connected before, there is no scan and the ESP just reconnects.
The default value is the same as the enum value of "no encryption".
The encryption is determined when performing a WiFi scan.
However if you reboot (no power cycle) and was connected before, there is no scan and the ESP just reconnects.
The default value is the same as the enum value of "no encryption".
-
- Normal user
- Posts: 531
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: ESP32 WiFi encryption
Look at WiFi scan below. The AP`s I talking about are the first two. Both are WPA/WPA2/PSK.
So You think (as I understand) that [Enchyption: open] statement is a bug and transmission is encrypted?
So You think (as I understand) that [Enchyption: open] statement is a bug and transmission is encrypted?
- Attachments
-
- Screenshot_20220104_180731.png (112.01 KiB) Viewed 7004 times
Re: ESP32 WiFi encryption
Nope, that's a result of a scan.
If that isn't showing any form of encryption, then it is perhaps some captive portal entry, where you can connect without passkey and then have to accept some terms and conditions probably on a page that will pop up if you connect to it.
Or... it is some encryption type I have not seen in the list of supported protocols and thus not given a name to it.
So 2 situations:
- Immediately reconnected at boot -> no scan -> encryption unknown.
- The access point truly does not use (or specify) any encryption protocol, or one we know.
If that isn't showing any form of encryption, then it is perhaps some captive portal entry, where you can connect without passkey and then have to accept some terms and conditions probably on a page that will pop up if you connect to it.
Or... it is some encryption type I have not seen in the list of supported protocols and thus not given a name to it.
So 2 situations:
- Immediately reconnected at boot -> no scan -> encryption unknown.
- The access point truly does not use (or specify) any encryption protocol, or one we know.
-
- Normal user
- Posts: 531
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: ESP32 WiFi encryption
THX for answer.
I think It is the first situation.
I think It is the first situation.
-
- Normal user
- Posts: 531
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: ESP32 WiFi encryption
I checked how ESP32 and ESP8266 behave after power cycle and after soft reset, connected to the same AP with WPA/WPA2/PSK enabled (without open).
ESP32 shows [Encryption Type: open] in both cases, while ESP8266 always shows WPA/WPA2/PSK encryption.
ESP32 shows [Encryption Type: open] in both cases, while ESP8266 always shows WPA/WPA2/PSK encryption.
Re: ESP32 WiFi encryption
I think the latest changes on ESP32 do always perform a WiFi scan as there is an issue on ESP32 (not 100% sure it doesn't happen on ESP8266) when performing a scan while connected.
What does happen is this:
If (on ESP32) the channel has to be changed, for example to perform a WiFi scan, then the active channel is not returned to the channel of the access point you're connected to (if connected that is of course)
So WiFi performance is then absolutely terrible and the only way to fix it is to reconnect.
Another issue on ESP32 is that making an immediate connection without the time needed to perform a WiFi scan, results in multiple disconnects from the access point.
Thus the actual time between boot and getting connected is no less than when you perform a WiFi scan.
For this reason, I have effectively disabled the checkbox (on ESP32) to reconnect to the last known AP from the data stored in RTC. (tools->Advanced, near the bottom of the page)
One thing I am not 100% sure about is whether or not that has been merged already into the code of the last build.
Another thing on the ESP32...
The RTC data (I also store the last known time and the last task values in there, to be restored at boot) on the ESP32 is less reliable compared to the ESP8266.
Where the ESP8266 almost never looses this data (or have corrupted data) as long as the power remains, this data on ESP32 is not always present anymore after a warm reboot.
I am not entirely sure what is causing this, but I think it also has to do with how the board design does reset the ESP.
The reset on the ESP32 is quite different from the ESP8266.
If the RTC data is no longer present (or checksum does not match) then the last known WiFI connection is not restored at boot and thus the unit must perform a new scan.
What does happen is this:
If (on ESP32) the channel has to be changed, for example to perform a WiFi scan, then the active channel is not returned to the channel of the access point you're connected to (if connected that is of course)
So WiFi performance is then absolutely terrible and the only way to fix it is to reconnect.
Another issue on ESP32 is that making an immediate connection without the time needed to perform a WiFi scan, results in multiple disconnects from the access point.
Thus the actual time between boot and getting connected is no less than when you perform a WiFi scan.
For this reason, I have effectively disabled the checkbox (on ESP32) to reconnect to the last known AP from the data stored in RTC. (tools->Advanced, near the bottom of the page)
One thing I am not 100% sure about is whether or not that has been merged already into the code of the last build.
Another thing on the ESP32...
The RTC data (I also store the last known time and the last task values in there, to be restored at boot) on the ESP32 is less reliable compared to the ESP8266.
Where the ESP8266 almost never looses this data (or have corrupted data) as long as the power remains, this data on ESP32 is not always present anymore after a warm reboot.
I am not entirely sure what is causing this, but I think it also has to do with how the board design does reset the ESP.
The reset on the ESP32 is quite different from the ESP8266.
If the RTC data is no longer present (or checksum does not match) then the last known WiFI connection is not restored at boot and thus the unit must perform a new scan.
-
- Normal user
- Posts: 531
- Joined: 07 Jun 2018, 06:47
- Location: Gdynia/Poland
Re: ESP32 WiFi encryption
THX for explanation!
Who is online
Users browsing this forum: Ahrefs [Bot] and 24 guests