Closed mlord closed 2 years ago
can you make a PR?
Sorry, no. I'm not a git person.
Can you give me a short sample code for verifying.
I'll see about some sample code for testing -- it's all currently part of a much larger codebase. But here is the simple patch I am using to correct it.
Thanks for responding!
Here is a test program for seeing the bug, and verifying the fix. This one has enough verbose output to show when a connection is established, and when it disconnects again.
Load the sketch onto any Arduino with a W5500 connected, and open the serial monitor (115200). Then "telnet -8 xx.xx.xx.xx 23" to connect to it without sending data. The sketch will not display any output. Then hit enter in the telnet session, and the sketch will only then say "connected".
Repeat the test with the fix applied, and now one should see "connected" immediately upon establishment of the telnet session.
testEthernet2.ino.txt (updated the sketch to remove a stray flush() call leftover from something different)
You use the Ethernet2 library, not the Ethernet3.
Same bug, exact same line of code. I'll pull down Ethernet3 and recheck it.
Re-tested, re-verified, exact same bug, exact same place, exact same fix. Thanks.
So.. closed but no intent to apply the fix, or what?
If this is supposed to somewhat follow the official API then there should be two separate functions. Server.available() waits for data and Server.accept() doesn’t.
The examples and fixes use the Ethernet2 library not the Ethernet3. If it persists make a PR.
As already noted above, the examples and fixes apply equally to both Ethernet3 and Ethernet2. Problem still persists.
This bug has been around forever. EthernetServer::available() is used to get a new inbound connection on a socket. But it won't actually return the new connection unless/until the remote end SENDs data to the socket. This causes trouble for several situations, including stuff I have ported from Ethernet and EthernetENC libraries.
Simple fix: get rid of the incorrect check of client.available() in there, which currently causes the connection attempt to be ignored unless data is available() from the remote end.