sstaub / Ethernet3

Ethernet library for Arduino and Ethernetshield2 / WIZ550io / WIZ850io / USR-ES1 with Wiznet W5500 chip
Other
76 stars 34 forks source link

EthernetServer::available() won't connect unless remote end SENDS something #42

Closed mlord closed 2 years ago

mlord commented 3 years ago

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.

sstaub commented 3 years ago

can you make a PR?

mlord commented 3 years ago

Sorry, no. I'm not a git person.

sstaub commented 3 years ago

Can you give me a short sample code for verifying.

mlord commented 3 years ago

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!

Ethernet2_connect_fix.patch.txt

mlord commented 3 years ago

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)

sstaub commented 3 years ago

You use the Ethernet2 library, not the Ethernet3.

mlord commented 3 years ago

Same bug, exact same line of code. I'll pull down Ethernet3 and recheck it.

mlord commented 3 years ago

Re-tested, re-verified, exact same bug, exact same place, exact same fix. Thanks.

mlord commented 2 years ago

So.. closed but no intent to apply the fix, or what?

vjmuzik commented 2 years ago

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.

sstaub commented 2 years ago

The examples and fixes use the Ethernet2 library not the Ethernet3. If it persists make a PR.

mlord commented 2 years ago

As already noted above, the examples and fixes apply equally to both Ethernet3 and Ethernet2. Problem still persists.