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 1555 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 1555 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 1555 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 1321 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 1321 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 1321 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.