See #3960 for more details of the problem and the solution. I only implemented what was proposed in this ticket, as it solves my problem, which was the same as in this ticket. Credits for the code going to @etrinh ;-)
This also is a more consistence behaviour compared to esp8266, where it also is possible to restart the wifiserver immediately on the same port.
* Change check for CONFIG_BT_ENABLE to really be a check for CONFIG_BLUEDROID_ENABLED
Which is really what should have been tested. This allows use of
the Arduino layer with the newer Nimble stack for those that don't want
to use Bluedroid.
In support of https://github.com/meshtastic/Meshtastic-device/issues/266
* Change check for CONFIG_BT_ENABLE to really be a check for CONFIG_BLUEDROID_ENABLED
Which is really what should have been tested. This allows use of
the Arduino layer with the newer Nimble stack for those that don't want
to use Bluedroid.
In support of https://github.com/meshtastic/Meshtastic-device/issues/266
* wifi prov changes
* merge fixes
Co-authored-by: geeksville <kevinh@geeksville.com>
Real DNS resolving timeout used by lwip library is 14[s] (7[s] for DNS1 + 7[s] for DNS2). Function WiFiGenericClass::hostByName() has timeout set to lower value (only 4[s]), so callback function may be called after this low timeout and it may overlappe stack memory used now by other function.
Fixes#3722
1. WiFiProv.ino sketch is added that allows arduino users to do provisioning via SoftAP or BLE. WiFi.beginProvision( ) API is designed for provisioning in Arduino.
2. In WiFiProv.h provisioning class is defined.
3. WiFiProv.cpp contains implementation for provisioning class.
4. README.md file is added which contains detail information for working.
* std::shared_ptr Memory Leak
clientSocketHande and _rxBuffer are std::shared_ptr, the stop() call was not correctly releasing them and the operator= had similar problems fix for #3679
* operator= second attempt
* operator= third time
WiFiClient.connected() was hanging thinking there was still a connection when the remote had already closed. The one-liner in this patch addresses recv() returning 0 and errno==128. I couldn't find the corresponding errno for 128 but its caught by the case statement which includes EPIPE, ENOTCONN, ECONNRESET and ECONNABORTED so I assume its one of those. Broken pipe maybe?
```c
[D][WiFiClient.cpp:511] connected(): Disconnected: RES: 0, ERR: 128
```
EDIT: added comment to reflect that recv() can set errno when it returns 0.
fixed the connected() function so that it only checks errno if recv returns a value of -1.
"in the even of an error, errno is set to indicate the error" --manpage
This fixes the ESP32 Webserver when dealing with a modern webserver with a slow SD card.
This event name was missing in the list:
d5e2bb12ca/tools/sdk/include/esp32/esp_event_legacy.h (L43)
E.g., it was giving
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 24 - ETH_GOT_IP
When it should have been
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 24 - ETH_DISCONNECTED
