Some units connect to local wifi and are operating as AP at the same time

[giig1967g]

Hi,
I have installed ESP_Easy_mega-20191104_normal_core_260_sdk222_alpha_ESP8266_4M1M.bin in all my units and I am experiencing the following problem since:

I have 9 units all connected to my local wifi router, but strangely 3 of them are also operating as APs. All units are operating correctly.
See screenshot (my unit number 3 is connected to my SSID=Varazze, but is also creating the AP=ESPT3_3. Same for units 8 and 10):

[TD-er]

The AP mode should be disabled after a minute, unless some client is still connected to the AP.
So this sounds like a bug.

[giig1967g]

The strange thing is that only 3 out of 9 have this behavior.

[giig1967g]

Anyone else experiencing this?
I would suggest to treat is a serious security bug, as all my neighbors for the last 24 hours have seen this new AP and might have try to connect.

[TD-er]

Well, the security level depends highly on the tech-savvy level of your neighborhood, but I see what you mean.

[giig1967g]

you are right, but just for curiosity one could try to see what a new SSID called ESPT3_3 is...

[Tom-Bom-badil]

Confirm that behaviour on one of my nodes. Nothing new - after the fix of the "daily reboot issue", I updated all nodes somewhen in March this year, then last week again. The AP issue was already there in March. Checked twice all settings, but never found the reason for it. Didn't see a major problem in this, just felt it to be a bit strange, so I left it as it is.
/tom

[Tom-Bom-badil]

Correction: 2 nodes showing the behaviour.

ESPEasy:

Router's WiFi list:

/tom

[s0170071]

@TD-er What about making all that ESPEasy specific wifi handling optional ? Per define.
You went through so much trouble fixing things that were often core related are maybe fixed already by the core folks. This could also save some ROM.

I have just tried the simple webserver example. It even automatically reconnects when I restart the router. Looks pretty solid to me.
ESPEasy does that only if you check Restart WiFi Lost Conn. Whats the use of that option anyway? Who wouldn't want that ?

[TD-er]

The label of that option is perhaps not the best descriptive one.
It means it will switch off the WiFi and turn it back on and then try to reconnect.
The default is to just reconnect and no power-cycle of the WiFi.

[blb4github]

Hi All,

I see this behaviour also with 2 of my nodes.

[Sasch600xt]

one of five devices is also shown up as AP.

[clumsy-stefan]

I experience the same thing, about 4 out of 40 nodes also open an AP (randomly, mainly slower ones/smaller ones eg. 1M units). But never considered this a problem, I thought it's probably missing a rekey or reconnect and opens an AP for a short time until it reconnects again.

Could be somehow related to weak RSSI?!

[TD-er]

Could be somehow related to weak RSSI?!

It is possible, but then the unit should reconnect a lot.
Or we have an issue where the detection of an existing connection is again/still broken. (the main reason why our WiFi code has become so complicated)

[Tom-Bom-badil]

Out of the 2 nodes with that behaviour, sh.klima.schuppen is indeed an outside device (D1mini Pro with external antenna). While the second one (sh.klima.eg) is at the ground floor almost next to the router and shows perfect RSSI ...
/tom

[ghtester]

I wish the AP mode could be disabled permanently by some option...

[ghtester]

It looks to me that the issue when a node connected as client is also visible as AP could be related to warm ESP node reboot.
In several recent firmware versions I encountered the node can't reconnect after a warm reboot. The main reason is a bad WiFi reception but when I perform a cold reboot, the node connects immediately even the WiFi signal is still weak. Issuing a WIFISCAN does show that after a warm reboot the node sensitivity (to WiFi as client) is worse than after a cold reboot. I think it could be due to combined WiFi mode activated after a warm reboot and the node is visible as AP in this case... Just my opinion... :-)

[TD-er]

@ghtester In your other issue, I noticed the very strange logs where it was not possible to switch WiFi modes. (search for multiple !!! in your logs)

[ghtester]

Yes, perhaps "the core" does some WiFi related "hidden" tasks after a warm reboot and does not allow to set up the WiFi mode properly...

[giig1967g]

in my case I have done several cold reboots (removing the power supply) and still one unit shows AP and is connected to Wifi.

[ghtester]

@giig1967g Are there any reconnects in your case after a cold reboot? Or the node with AP+STA mode was connected to WiFi at first attempt?

[giig1967g]

From sysinfo page:

Connected: | 1d02h07m
-- | --
Last Disconnect Reason: | (201) No AP found
Number Reconnects: | 0

[TD-er]

It was apparently before the first successful connect, given the number of reconnects is 0.

[s0170071]

uncommenting line 291 in ESPEasy.ino fixed the issue for me.

// setWifiMode(WIFI_STA);

@TD-er this rings a bell ?

[TD-er]

Well, that's called before the plugins are being initialized.
If that does help in finding more APs, then it looks like there is some interference between active processes and performing the RF calibration.

Or, it may be that this does offer some more time between switching on the WiFi and actually connecting.
It is also possible the actual state of the AP/STA mode is incorrect at (warm)boot.
The command you quote here does set it to STA only.
What I do when connecting to WiFi is just activate the STA bit in the mode.
Before that I switch the WiFi off, which may not be exactly the same as switching both AP and STA bits off?

[s0170071]

You have to switch AP mode off or it will resurface. Those settings are pretty resilient.
I have a unit that opens an AP with no initialization at all. Just looping for(;;) delay(1)
It used to be , however, be an AP in a previous life. With a previous programming.

[ghtester]

That's why I'm prying for an option to disable AP mode permanently... In my case AP mode makes only troubles, no advantage at all...

[TD-er]

Would it be an improvement to make the AP mode less active by using these:

• Only start AP mode if no connection made withing the first N minutes after boot.
• Stop AP mode when no client is connected to it every minute and re-evaluate the need for AP mode.

The first one does not allow the AP mode to be automatically started after the first N minutes and still gives a good escape route to redefine wifi config when you had to change routers for example.
The second one makes sure the AP mode will not be kept active forever as long as you're not connected to it with your mobile for example.

The stopping of the AP mode is already implemented, but it looks like the WiFi.mode call is broken at the moment. So I have already implemented a number of retries to get the mode set.

Also what is a good value for N? 5 minutes?

[TD-er]

Ah found also a logic error in the timerAPoff.
The timer should be set as soon as the timer to start the AP is also set.
Otherwise you have no guarantee the AP will be disabled again.

[ghtester]

Yes I believe 5 minutes would be OK for now, I'll be glad if there's a permanent AP disable option in future.
So I suppose the test recommended above is not necessary anymore...

[TD-er]

So I suppose the test recommended above is not necessary anymore...

Nope, it wasn't enough to fix this.
I will perform some tests here and probably merge it this evening for a new build tomorrow.

[ghtester]

Thanks a lot for a great job! :-)

[ghtester]

FYI the annoying issue after a warm (re)boot the WiFi STA sensitivity is low is still there. Hopefully the core lib 2.6.1 could help to fix that...

[TD-er]

There has been no nightly rebuild, which I had hoped for.
Were you testing using your own Vagrant build?

[ghtester]

Yes with the latest sources.

Firmware

Build:⋄ | 20104 - Mega
System Libraries:⋄ | ESP82xx Core 2_6_0, NONOS SDK 2.2.2-dev(bb83b9b), LWIP: 2.1.2 PUYA support
Git Build:⋄ | My Build: Nov 19 201904:54:59
Plugins:⋄ | 37 [Normal]
Build Md5: | f0b6b7017c7516310fde820bdfdcdd3
Md5 check: | passed.
Build Time:⋄ | Nov 19 2019 04:56:27
Binary Filename:⋄ | ESP_Easy_20191119_vagrant_custom_ESP8266_4M1M.bin

When the new official build is created, I'll test on another ESP node to confirm if the issue is the same like on my Vagrant customized.

[TD-er]

If it is, can you then open a new issue about that, since it is a different issue (not about opening AP mode)

[ghtester]

Yes I'll do it if the issue doesn't vanish. Thanks again for your great work!

[blb4github]

First result is very promising: I have installed the latest version (ESP_Easy_mega-20191119_test_core_260_sdk3_alpha_ESP8266_4M1M.bin) on all 5 modules last night and they are all up and running without AP issue and also without any reboot. Also the once with low signal strength.

[ghtester]

OK, thanks for the info, I'll try to rebuild with my Custom.h if I find what to change to use 260_sdk3_alpha core.

[Sasch600xt]

confirm that ESP_Easy_mega-20191119_test_core_260_sdk3_alpha_ESP8266_4M1M.bin works for me also at a weak RSSI Device.

[ghtester]

Great, ESP_Easy_mega-20191119_test_core_260_sdk3_alpha_ESP8266_4M1M.bin from official build works for me as well. I tried to edit build flags in platformio.ini under Vagrant environment to use sdk3.0.0. instead of default 2.2.2 for compilation with my specific Custom.h but I failed. :-( The output
binary still compiled with sdk 2.2.2.
Gijs, could you please update the Vagrant scripts to use sdk 3.0.0 by default for the custom build if possible?

[TD-er]

@ghtester Is SDK 3 working better with wifi compared to sdk 2.2.2?

[ghtester]

From my perspective yes, tested quickly with official build specified above but it's missing IRRX which I need together with plugins that are missing in official builds containing IRRX. And so far I was not able to understand the Vagrant scripts sufficiently to self compile with sdk3. I would like to perform a more thorough tests with my preferred set of plugins including IRRX.

[TD-er]

@ghtester
I added an extension to Vagrant's build script.
You can add a file named pio_envlist.txt next to the Custom.h in which you define what PIO environment you want to build.
One per line (no empty lines in the file please)

It will be included in this PR: #2744

[ghtester]

Thanks a lot, I'll give it a try when ready.

[ghtester]

Just tested a Vagrant fresh build with my Custom.h. The output bin looks like this:

Firmware

Build:⋄ | 20104 - Mega
System Libraries:⋄ | ESP82xx Core 2_6_1, NONOS SDK 2.2.2-dev(bb83b9b), LWIP: 2.1.2 PUYA support
Git Build:⋄ | My Build: Nov 21 201914:52:55
Plugins:⋄ | 37 [Normal]
Build Md5: | eedbe4bcc88dc6fd5d4ba71fbfc2e5c
Md5 check: | passed.
Build Time:⋄ | Nov 21 2019 14:54:22
Binary Filename:⋄ | ESP_Easy_20191121_vagrant_custom_ESP8266_4M1M.bin

So the re's core 2.6.1 but sdk 2.2.2 and the WiFi issue after a warm boot is there. I have also encountered a wdt reboot so it looks it won't be a best possible combination and sdk3.0 is perhaps a must.

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v482516e3
~ld
▒#$ s▒nlph▒U69 : Info :

INIT : Booting version: My Build: Nov 21 201914:52:55 (ESP82xx Core 2_6_1, NONOS SDK 2.2.2-dev(bb83b9b), LWIP: 2.1.2 PUYA support)

Could you please provide me with a pio_envlist.txt structure? I have no idea what exactly I should put there and I did not found any example in sources or an info in the README.txt file.
Thanks a lot for your effort!

[TD-er]

I added a sample which you have to place next to the Vagrantfile (it is now called pio_envlist.txt.sample)
See:
https://github.com/letscontrolit/ESPEasy/blob/mega/tools/vagrant/pio_envlist.txt.sample