Description
Basic Infos
- This issue complies with the issue POLICY doc.I have read the documentation at readthedocs and the issue is not addressed there.I have tested that the issue is present in current master branch (aka latest git).I have searched the issue tracker for a similar issue.If there is a stack dump, I have decoded it.I have filled out all fields below.
Platform
-
Hardware: ESP-12
-
Core Version:
SDK:2.2.1(cfd48f3)/Core:win-2.5.0-dev/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-7-g2b827f8)
SDK:2.2.1(cfd48f3)/Core:win-2.5.0-dev/lwIP:1.4.0rc2
SDK:2.2.1(cfd48f3)/Core:win-2.4.1/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1)
SDK:2.2.1(cfd48f3)/Core:win-2.4.1/lwIP:1.4.0rc2 -
Development Env: Arduino IDE
-
Operating System: Windows
Settings in IDE
- Module: NodeMCU 1.0
- Flash Mode: dio
- Flash Size: 4MB
- lwip Variant: v2 Lower Memory OR v1.4
- Reset Method: nodemcu
- Flash Frequency: 40Mhz
- CPU Frequency: 80Mhz
- Upload Using: SERIAL
- Upload Speed: 115200
Problem Description
In the latest master branch, the station in the file ClientConnectedBug.ino (download below) seems to randomly loose connection to the AP server while waiting for curr_client.available()
to indicate a server response (WiFiClient class is used to create a TCP connection to the server, so curr_client
is the server here). This was not the case in Arduino core for ESP8266 version 2.4.1 and 2.3.0. The problem seems to be that !curr_client.connected()
at line 50 in ClientConnectedBug.ino now sometimes evaluates to true, whereas before it did not.
Instructions for reproducing bug:
- Download and unzip the .ino files in ClientConnectedBug.zip
- Make sure you are using Arduino core for ESP8266 version 2.4.1.
- Use lwIP2 or lwIP1.4.
- Add AP1.ino to one ESP8266 and ClientConnectedBug.ino to another.
- Observe serial output from ClientConnectedBug.ino.
- Update Arduino core for ESP8266 to latest master branch.
- Restart IDE and re-upload ClientConnectedBug.ino.
- Observe serial output from ClientConnectedBug.ino.
Activity
d-a-v commentedon May 17, 2018
This behaviour (sometimes yes, sometimes not) is expected.
With this added in your sketch,
I get this message always displayed
It is expected because the server sends its data, then
flush()
meaning it ensures that the data are received by its client, then immediately closes. By the time the client gets the data, the server may already have closed the connection, so technically the client is not anymore connected.And yes, this behavior was not encountered with previous versions.
That's because of #4626 which changes
connected()
to the way described above.You should test
available()
to know whether data is to be read, andconnected()
to know whether peer is still connected (= we can send data to server). The connection is to be discarded when(available() || connected())
is false.devyte commentedon May 18, 2018
@aerlon I am not familiar with our mesh lib, except for glancing at the code in passing, but it is possible that the code could need updatiing due to the previous comment. In that case, please continue discussion in the mesh update pr.
Closing this one.
Update of mesh network library. (#4718)