calling ESP8266WiFiMesh::deactivateAP() doesn't fully disable wifi and corrupts SSID

[rorosaurus]

Basic Infos

• [x ] This issue complies with the issue POLICY doc.
• [ x] I have read the documentation at readthedocs and the issue is not addressed there.
• [x ] I have tested that the issue is present in current master branch (aka latest git).
• [ x] I have searched the issue tracker for a similar issue.
• [ x] If there is a stack dump, I have decoded it.
• [ x] I have filled out all fields below.

Calling ESP8266WiFiMesh::deactivateAP() in the example HelloMesh program produces a Wifi network with this result, after refreshing wifi on my phone:

I would have expected the wifi network to be shut off completely, not remove password, SSID, etc.

[rorosaurus]

Maybe this is expected behavior? But I didn't expect to need to call WiFi.mode(WIFI_OFF); after calling ESP8266WiFiMesh::deactivateAP()

[devyte]

CC @aerlon

[aerlon]

Interesting. Neither my phone, nor my laptop can detect the WiFi once ESP8266WiFiMesh::deactivateAP() is called, but other ESP8266 nodes are able to do it. It seems as though an AP with an empty SSID is created. The intended result is to completely shut down the AP, as you guessed, so this is a bug.

This problem is caused by the use of WiFi.mode(WIFI_AP_STA); as the default WiFi mode in the library. It seems that the node will automatically set up an AP in this WiFi mode, even though WiFi.softAP() is never called. You can try this yourself by adding delay(30000); after meshNode.begin(); in HelloMesh, an AP will be created even though we have never called activateAP().

@devyte Is it expected behaviour that just having the ESP8266 enter WiFi.mode(WIFI_AP_STA); will cause an AP to be created (even if we never call WiFi.softAP()), or is this a bug in the core WiFi code?

If this is not a bug in the core code, the default WiFi mode of the mesh library will have to change. This should be possible, but I will need to do some testing.

@rorosaurus ESP8266WiFiMesh::deactivateAP() requires a slight change to fix the bug you found. Changing WiFi.softAPdisconnect(); to WiFi.softAPdisconnect(true); in the method seems to fix it, at least till the node re-enters the WIFI_AP_STA mode. We cannot use WiFi.mode(WIFI_OFF); in ESP8266WiFiMesh::deactivateAP() because deactivating the node AP would then also disconnect any active WiFi station the node may have. (you can of course use WiFi.mode(WIFI_OFF); as a work around for now, I'll include the fix for this bug in my intermediate release which should be ready within a week)

[devyte]

My guess is that of you change mode to ap_sta, then an ap will be brought up with whatever parameters possible. I would expect some default if nothing has been set up, but I'm just guessing.
My own policy is to always specify every parameter myself, and not rely on sdk defaults or whatever. That means that I do something along the lines of:
If newmode is sta or sta_ap
Set up sta with my parameters
If newmode is ap or sta_ap
Set up ap with my parameters
Change mode to newmode

(Sorry for lousy pseudo code, I'm travelling with just my phone).

[aerlon]

Yes, after reviewing the core source code it seems as though WiFi.mode() is always in charge of actually enabling and disabling the AP. All other WiFi methods dealing with this functionality just wrap the WiFi.mode() method in different ways. I'll modify the mesh library to take this into account.

[aerlon]

@rorosaurus There were a few more complications than expected, but now the intermediate mesh update is done and merged to master. Among other things it should fix all the bugs we have discussed and also allow you to choose the number of stations that can connect to each AP (between 0 and 8).

Would it be possible for you to verify that the AP deactivation problem is fixed in the latest master and, if true, close this issue? That would help keep the number of open issues down.

[aerlon]

I should probably add that uint64ToString and stringToUint64 are now stand-alone functions, so if your code used the old class methods you will probably need to #include <TypeConversionFunctions.h> and change the function call signature a bit. The updated HelloMesh example can be used as a reference for this.

[devyte]

Reference: #6280