While monitoring communication between Chrome browser and a W5500 I see a SYN packet from Chrome followed by an RST, ACK from the W5500 about 14 usecs later. I see two additional SYN packets from Chrome on the same source port, each about 0.5 secs apart and the W5500 replies to each with an RST, ACK about 10 usecs later. I don’t see any other SYNs during this time interval.
Based on log data surrounding (but not exactly at) this time, it appears that I have 3 available sockets, though I don’t have insight yet into what their status is. I suspect they were in a state that rendered them unavailable because I don’t see another SYN from Chrome get ACK’d until after a FIN, ACK sequence.
My question is: are there conditions other than lack of available sockets that will cause the W5500 to send a RST packet in response to a SYN?
Usually caused by no available sockets in listening state. I hit this issue with Chrome when designing web browser for W5100. Now I recommend using Firefox which has the setting to limit number of sockets it is going to use.
I think my problem occurs due to the length of time between the W5500 ACKing a SYN packet on the socket on which it’s listening and the time the driver notices this and starts listening on another socket. The ideal solution would be to generate an interrupt when a new connection is made so an idle socket could be set to LISTEN immediately, but I don’t see any way to do that on a system based on an Arduino + shield connected via SPI.
Have you ever tried listening on the same port on multiple sockets? Seems like that would work if the W5500 just assigns incoming SYN packets to the first socket matching the requested port.
Of course! It is normal way to function. When SYN comes, W5x00 automatically selects next available socket listening on the port.
Usually your goal is to serve request, disconnect, close and reopen for listening as fast as possible. I think it is possible to perform using interrupts, and server is going to “master” the connection deciding when connection is done.
Hi~
If you set on the same port on multiple socket, Socket numbers are connected in the order of lowest.
So, if you set the TCP Server on the same port about Socket 1 and Socket3, it will connect the Socket 1 and you will show the RST packet about socket 3.
I tested this and found that the second socket does continue listening after the first connects. I also monitored network traffic with Wireshark and did NOT see RST packets from the other listening sockets.
