does not connect any more to Hidden SSID
Moderators: grovkillen, Stuntteam, TD-er
does not connect any more to Hidden SSID
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"
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"
Re: does not connect any more to Hidden SSID
Do the hidden SSID's show up when performing a scan?
Re: does not connect any more to Hidden SSID
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" ?
If this is above channel 11, can you also try setting it to a different channel or uncheck "Passive WiFi Scan" ?
Re: does not connect any more to Hidden SSID
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...
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...
- Attachments
-
- Networks.jpg (109.29 KiB) Viewed 4123 times
Re: does not connect any more to Hidden SSID
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.
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.
Re: does not connect any more to Hidden SSID
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.
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.
Re: does not connect any more to Hidden SSID
Have you also tried forcing b/g mode?
Re: does not connect any more to Hidden SSID
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
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
Re: does not connect any more to Hidden SSID
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.
When do the WiFi issues stop?
The only closed-source part of all ESP chips and the one part giving me the most headaches.
Re: does not connect any more to Hidden SSID
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) while in hidden (not working) case = can see only one connect and also only one DHCP request arriving: 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:
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) while in hidden (not working) case = can see only one connect and also only one DHCP request arriving: 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:
Re: does not connect any more to Hidden SSID
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.
No idea though why it would try to authorize twice.
Re: does not connect any more to Hidden SSID
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): 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: 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:
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): 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: 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:
Re: does not connect any more to Hidden SSID
Just to be sure, those problematic units are ESP8266?
Re: does not connect any more to Hidden SSID
Yes.
I have only one esp32 in place and about 15 esp8266
I have only one esp32 in place and about 15 esp8266
Re: does not connect any more to Hidden SSID
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:
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;
}
Re: does not connect any more to Hidden SSID
Can you try this test build:
https://github.com/letscontrolit/ESPEas ... 0758798363
Preferrably on a node which is good reachable when things go wrong.
https://github.com/letscontrolit/ESPEas ... 0758798363
Preferrably on a node which is good reachable when things go wrong.
Re: does not connect any more to Hidden SSID
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.
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.
Re: does not connect any more to Hidden SSID
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.
Re: does not connect any more to Hidden SSID
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?
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?
Who is online
Users browsing this forum: Ahrefs [Bot] and 0 guests