does not connect any more to Hidden SSID

[_Cyber_]

Hi,

I updated to ESP_Easy_mega_20240822_normal_ESP8266_4M1M (from 20240414) and now I can't get it connecting to my Hidden SSID.

Hidden SSID is checked
tried "Hidden SSID Slow Connect" ticked and not ticketd - does not matter.

with setup I cleared wifi credentials and re-entered - did not help.

downgrade to 20240414 and it immediately connected again.

is there something broken?

on the SSID I have NOT enabled "802.11k/v Roaming"

[TD-er]

Do the hidden SSID's show up when performing a scan?

[TD-er]

Which channel is the hidden SSID on?
If this is above channel 11, can you also try setting it to a different channel or uncheck "Passive WiFi Scan" ?

[_Cyber_]

the strongest (and configured as #1) is:
SSID: KlinglAIRDMZOG (62:45:97:F9:04:46)
Channel: 12
(Channel 12 is set manually on AP to have less overlaps)

the second one (and configured as #2 - config is the same, ) is:
SSID: KlinglAIRDMZEG (62:F4:97:F9:00:F5)
Channel: 7
(Channel 7 also set manually on this AP)


the #12 shows up in hidden list, yes. the #7 not
funnily, the not-hidden #7 shows up in scanlist as well (also there the #12)

where is "passive WIFI scan" setting? cannot find it, neither in network, nor in advanced...

[TD-er]

Ah then this passive scan may have been only present on ESP32...?
I just checked at the advanced options of a node I have running here which is running a build of July this year, so the feature should be present in the August build (unless it is an ESP32-only feature of course...)

Problem with hidden SSID is that you cannot connect to it using passive scan if it is at a channel > 11.
The switch for "Passive/Active" WiFi scan was added for this use case.

And on some APs you cannot try to connect using some kind of broadcast like "Hello, AP bladiebla, I like to connect, here is the password" but you really must address the AP directly using the BSSID and channel.
Especially Mikrotik and some Fritzbox demands this. For this the "Hidden SSID Slow Connect" was introduced.

For some access points, you need to add an extra wait after the initial connect attempt or else the connect attempt will be considered as failed.
The "Extra Wait WiFi Connect" does toggle this extra wait.

There is always something with those hidden SSIDs.
I start to understand why Tasmota decided not to support it.

[_Cyber_]

yay, to make it clear, if the SDK would be able to just fulfill requirements which were defined and working decades back in the past, it would just be maybe more than a tinker product. so sad.

I need to spin up different SSIDs per floor, as the same SDK always connected not to the strongest AP with the same SSID, but always the one with the lowest channel number. really awful.

BTT:
even if i change the channel to 11 it does not connect.
and, it looks like there is also a prefer of configured #1 SSID - if it does not connect (which happens neither on channel 12 nor on 13) it does no fallback.
configuring the #2 SSID as #1 SSID it connects to the (there also hidden, on chan #7) SSID immediately.

interestingly, the "not connecting" case maybe has another reason - I can see the DHCP Discover and the offer is sent. but then nothing else happens.

My AP's are Zyxel NWA1123-ACv2 - working flawless for all clients (stupid webradios, old windows phones, notebooks, android devices, iOS devices, raspberry PI (zero1, zero2, 3, 4), tasmota devices) flawless. only ESPs give me always a headache with not clearly reproduceable glitches.

tasmota works with the same hidden SSIDs. I have only three of them, two ESP8266 based which connect to #7 hidden SSID flawless and one ESP32 based which is also on #7 hidden ssid.

[TD-er]

Have you also tried forcing b/g mode?

[_Cyber_]

yes, does not help.

Sep 3 12:43:02 Router dhcpd[210984]: DHCPDISCOVER from e8:68:e7:81:13:cb (SZLichtTuere) via br2
Sep 3 12:43:03 Router dhcpd[210984]: DHCPOFFER on 192.168.10.141 to e8:68:e7:81:13:cb (SZLichtTuere) via br2

12:43:02.726815 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from e8:68:e7:81:13:cb (oui Unknown), length 308
12:43:03.731857 IP 192.168.10.1.bootps > 192.168.10.141.bootpc: BOOTP/DHCP, Reply, length 300

vs.
Sep 3 12:59:36 Router dhcpd[210984]: DHCPDISCOVER from e8:68:e7:81:13:cb (SZLichtTuere) via br2
Sep 3 12:59:37 Router dhcpd[210984]: DHCPOFFER on 192.168.10.141 to e8:68:e7:81:13:cb (SZLichtTuere) via br2
Sep 3 12:59:37 Router dhcpd[210984]: reuse_lease: lease age 12428 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.10.141
Sep 3 12:59:37 Router dhcpd[210984]: DHCPREQUEST for 192.168.10.141 (192.168.10.1) from e8:68:e7:81:13:cb (SZLichtTuere) via br2
Sep 3 12:59:37 Router dhcpd[210984]: DHCPACK on 192.168.10.141 to e8:68:e7:81:13:cb (SZLichtTuere) via br2

12:59:36.425198 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from e8:68:e7:81:13:cb (oui Unknown), length 308
12:59:37.425966 IP 192.168.10.1.bootps > 192.168.10.141.bootpc: BOOTP/DHCP, Reply, length 300
12:59:37.432406 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from e8:68:e7:81:13:cb (oui Unknown), length 308
12:59:37.444497 IP 192.168.10.1.bootps > 192.168.10.141.bootpc: BOOTP/DHCP, Reply, length 300

[TD-er]

OK, have to check this also (along with issues regarding WiFi on ESP-IDF5.3 for ESP32-C3/C6)

When do the WiFi issues stop?

The only closed-source part of all ESP chips and the one part giving me the most headaches.

[_Cyber_]

either unhiding the SSIDs
or a step-back to 20240414

what looks strange to me: I always can see more than one DHCP request in unhidden case, and also the log on the AP looks like it does connect, disconnect, and connect again (sse the count=2)

Zyxel-Log-NotHidden-working.jpg (102.28 KiB) Viewed 8581 times

while in hidden (not working) case = can see only one connect and also only one DHCP request arriving:

Zyxel-Log-Hidden-notworking.jpg (90.35 KiB) Viewed 8581 times

besides this, the log on the AP looks identical.

with 20240414 I can also see two DHCP requests, but the AP log looks different. it does not distinguish between hidden / unhidden SSID at all:

Zyxel-Log-working_20240414.jpg (58.01 KiB) Viewed 8581 times

[TD-er]

Multiple DHCP calls is not uncommon as for example the DNS server entry is not among the standard fields in the reply.
No idea though why it would try to authorize twice.

[_Cyber_]

I had to revert another device to 20240414

I know tihs one has weak signal - it's near to the AP named at the end UG (configured as first one, served on channel 2) and has there normally -72dbi
to AP with ending EG is connectable but with -91dbi (nevertheless configured as second one, served on channel 6).

neither the first, nor the second is hidden.

with 20240414 the connection is stable to UG until power loss or hostapd restart (...UG is a linux hostapd served AP with an Atheros card 802.11n)

since 20240822 the ESP is most time offline, I get on reconnect rule-emails, they look like (you can see the uptime and connected AP):

Resets.PNG (81.06 KiB) Viewed 8347 times

other units to the UG AP connected, but stronger signal and different settings, are stable.

the config of this unit is different caused by the known weak signal:

Advanced.PNG (28.86 KiB) Viewed 8347 times

I did not change the config after update. this unit is well hidden below a thermostate - I am eager to not disassemble / reassemble it. luckily the firware downgrade went trough.

other units with stable connection config to the same AP:

stable-advanced.PNG (32.63 KiB) Viewed 8347 times

[TD-er]

Just to be sure, those problematic units are ESP8266?

[_Cyber_]

Yes.
I have only one esp32 in place and about 15 esp8266

[TD-er]

I think I may have found something rather fishy in the changes since april build.

In order to reduce the binary size of the builds, I have replaced some union structs with just bit-wise structs.
However those will not be copied if the compiler generates a default copy constructor.

So I am now looking into this to see if I should revert this change or make a proper copy constructor.
For example something like this:

Code: Select all

WiFi_AP_Candidate& WiFi_AP_Candidate::operator=(const WiFi_AP_Candidate& other)
{
  // All members other than ssid can be mem-copied
  memcpy(this, &other, sizeof(WiFi_AP_Candidate));

  // Make sure ssid isn't some kind of valid String with heap allocated memory
  memset(&ssid, 0, sizeof(ssid));
  // Now copy the ssid String
  ssid = other.ssid;
  return *this;
}

[TD-er]

Can you try this test build:
https://github.com/letscontrolit/ESPEas ... 0758798363

Preferrably on a node which is good reachable when things go wrong.

[_Cyber_]

did not help.
so, connecting to a hidden SSID (independend of channel >11 or <=11) seems is not possible.

same behavior as in viewtopic.php?p=70844#p70844 described.

[TD-er]

Hmm that's odd, I don't see (yet) what else might have changed which could have changed this behavior as I have looked into changed files which are related to WiFi between those 2 builds.

[TD-er]

Can you check something in the AP configuration?

I have been working on this hidden SSID for the past 2 days and finally got it to work here.

There are 2 issues with hidden SSID networks:
- Connecting to channels > 11 (see explanation here: https://github.com/letscontrolit/ESPEas ... 2457592392 )
- Connecting to hidden SSID networks on channels <= 11

On my Mikrotik AP I was not able to have any ESP32 (not tested with ESP8266, will likely also not work) connect to it when hidden SSID was checked.
As soon as I unchecked it, the ESP would immediately (re)connect to it, so the credentials are OK and since my test code used BSSID and channel, I also know those are correct.

What made it finally work was to set the AP to B/G/N or G/N.
With "N-only" it was not possible to connect to it with "hidden SSID" enabled.

And the really funky part is that when it now finally connects, the connection is in N-mode.

So I honestly have no idea what is the reason the ESP will not connect to it when in N-only mode.

Can you please check if your AP is maybe also set to N-only mode?

[_Cyber_]

sorry for late reply - did not get an notification.

my ap is already in b/g/n
there is no option to set it to g/n

bgn.png (19.79 KiB) Viewed 3507 times

[TD-er]

b/g/n is fine.
Or b/g if the access point is only used for these kinds of devices.

What you're setting with this is the list of allowed protocols.
So if ESPEasy is forced to use b/g mode, it will try to connect using 'g' mode and if that doesn't work it will fall back to 'b' mode.
However if your AP is set to 'n'-only, a client searching for 'b/g' mode cannot connect to the AP.

N.B. "a/n" mode is also not including b/g. But since "a" is for 5 GHz and "n" can be both on 2.4 and 5 GHz, I am not sure what is meant with it as it suggests "5 GHz only".

[_Cyber_]

I also was wondering in the list about the a mode, as the radio profile is set for 2.4GHz only, and the configuration mask for the 5GHz bands differs anyway.

what I also tried is setting the Channel Width to 20MHz - did also not have any effect.

btw, here is the complete profile, I did not try any advanced settings yet.

all_AP_settings.png (58.92 KiB) Viewed 3327 times

[TD-er]

Quite a lot of settings possible which are not available on lots of other devices.
(I might get back to you one day regarding the Multicast Transmission Mode setting to try something....)

I don't see what might be wrong there.
What options are available regarding the Channel Width? Not sure if 20 MHz is a valid option for 802.11g. It for sure isn't for 802.11b.

[_Cyber_]

channel width offers 20MHz or 20/40MHz
I guess it takes then 40MHz if available (I chose in the past 1 / 6 / 11 but since here and channel 11 issues now 1 / 6 / 10 ) to have no channels overlapping in 20MHz.

[TD-er]

No, I specifically disabled the 40 MHz when connecting, as it does make matters worse.
With 40 MHz bandwidth, you have effectively 2 "channels" which are quite wide. (the mentioned channel is the center frequency)
On 2.4 GHz WiFi, you typically only have channel 1, 6 and 11 which will not overlap with eachother when using 20 MHz bandwidth.
For 40 MHz you will use 2 of these (or at least channel offset of 5) and thus use about 2/3rd of the total available spectrum.
This will more than double the chance of 'collisions' with other WiFi traffic and make the connection less reliable.
The speed-increase on an ESP board is often negative.

So when setting the channel to "1" and 40 MHz bandwidth is used, you effectively use channels 1 and 6 (upto channel 8)
And even worse, if you were to use channel 3, you would be covering the frequencies of channels 1 ... 5 for 20 MHz bandwidth with as center channel 3 and center channel 8 which covers the frequencies of channel 6 ... 10.
So you will see interference from just about any traffic using 802.11n, thus achieving about the worst-case scenario possible.