stopAll() in WiFiGeneric causes currently in progress webServer transmission to stop.

[adrian-dybwad]

This line:

Arduino/libraries/ESP8266WiFi/src/ESP8266WiFiGeneric.cpp

Line 224 in eea9999

WiFiClient::stopAll();

causes a currently in session webServer send to stop. Before I make an MCVE, can anyone share why this stopAll exists?

If, while the web server is sending a chunked response, a WiFi event occurs, the chunked response is abandoned and the web browser gives an error. Commenting it out appears to fix the problem but maybe there was a reason for it and something else would be broken after removing it?

It may also have some bearing on an older issue: #1554

[TD-er]

I can imagine it would be useful to enter sleep mode as soon as possible and leave in a known state.

[d-a-v]

@adrionics This is history and legacy.
I guess every tcp connection should not be stopped if AP is active with ongoing tcp connections.
Also if STA is reconnected soon enough, ongoing connections should be able to go on.
Is that what you want to show with an MCVE ?

I currently can't think of anything that would prevent the removal of stopAll(). Ongoing connections would just timeout or have connected() set to false (this has to be verified).

I can imagine it would be useful to enter sleep mode as soon as possible and leave in a known state.

Agreed, then stopAll() would need to be explicitly called at that time

[adrian-dybwad]

My feeling is stopAll() should always be user initiated and if you are going to sleep, call it if you need to.

My issue was happening in AP_STA mode, while not connected to WiFi as a STA, but with a client connected to the AP and downloading a web page from the ESP. The AP client stays connected, just the web browsers TCP connection is interrupted when the ESP attempts to connect to a non existent network and that fails. Looking at the code, any WiFi event would cause this though.

Do you want an MCVE?

[devyte]

@adrionics the method must be called if an interface goes down, e. g. the STA disconnects, for cleanup purposes. In that case, it is up to the user app layer to restart services, usually by implementing the restart in a wifi event callback.
If this happens in the middle of sending/receiving, it is up to the app layer to handle that. There are no low level retries or continues for a communication that gets broken in such a way.

@d-a-v I do believe we currently have a single list of sockets for both AP and STA. We could split the list, but we would need to have one per interface (e. g. loopback, Ethernet_lwip, etc). We could then close only those relevant to the interface that went down.

[d-a-v]

We could then close only those relevant to the interface that went down.

TCP connections must be closed before the interface goes down.
We don't need to have separate lists for AP and STA. What would be needed is to check for which interface each connection of the unique linked list is made and close if that interface is supposed to be shut down.

The question arisen in this issue is to remove core-initiated calls to WiFiClient::stopAll() and let user deal with them (the opened connections). I think that's still relevant.