I am running a W5500 WIZ550io with the shield adapter on top of a custom microprocessor. The code is my own and a version of it can be seen here wiznetmuseum.com/portfolio-items … ith-w5500/
Sometimes I encounter SOCK_FIN_WAIT after issuing a disconnect but if i let it go for a couple of hundred ms it will close properly. Other times the status is persistent and I just have to issue close. The temporary problems happen when the connection is coming from outside the local lan and the permanent problems are usually local.
Also, sometimes a session is established but there is no data (SnRX_RSR=0) but if i wait a couple of hundred ms, the size fills in. Other times the problem is permanent and the data never shows up. Again, the problem happens particularly with connections coming in from outside the local LAN.
In both cases, I am now running retry code but i don’t like it because it ties up the system and there is no way of knowing how long to wait. I have run similar code with a w5200-based shield and not I would just disconnect 0 data sessions and close on SOCK_FIN_WAIT but if i do that with the w5500 i end up with hung browsers.
Thanks for any help.
There’s a bit more info here olduino.wordpress.com/2015/03/0 … ome-light/
Are these expected situations? Is there a better way to deal with them?
Hi, Bill2009.
First problem is often happened in web server applications. SOCK_FIN_WAIT means half-close state that is waitting for FIN packet from a peer.
So, If peer doesn’t send the FIN packet to W5500, W5500’s SOCKET state cannot be changed into SOCK_CLOSED.
Normally, In web-server application, You’d better use the command CLOSE instead of DISCON.
CLOSE command can be forced the socket on SOCK_CLOSED regardless of the peer.
Second problem, I cannot understand it. I need more description about the problem. If possible, capture the packet by Wireshark in this situation and attach the capture files.
Thank you.
Thank you. I am away from home for a couple of weeks but i will capture it with wireshark in April.
Ok: I can easily recreate the problem and I have tried to capture it.
In this case the client ip is 24.114.86.112 and the server is 192.168.1.182.
Client sends an HTTP GET, the socket status goes to 17 - session established but when I read SnRX_RSR I get 0 for approximately 200 ms. Then SnRX_RSR shows the proper length 381. I have attached the wireshark capture print as well as screengrabs of the tcp stream content and packets.
I did capture everything but I’ve limited the uploads to the tcp stream. if there’s more that would be a help please let me know.
0length.wireshark.txt (12.8 KB)
I looked at the source code and I saw that you have a delay(200) in the main loop of which escapes me the utility.
Checking the status of the socket should be managed continuously.
Thanks for looking at the code. I have a 100ms delay in the main loop because i sometimes stream the status codes to a serial port and i don’t want to flood it.
I reduced the delay to 1ms and I found the transient 0 length happened almost every time whether the client was on the local network or not. My conclusion is that there is a perceptible lag between when the socket status goes to 17 and when the data is available.
I can live with the retries except that Chrome frequently causes a session to be established with 0 data and this never resolves so the server spins its wheels for 200ms waiting for something that never happens.
I don’t have directly comparable code but I have tried this with the W5200 and the transient 0 size does occur but less frequently. I had not seen it before because the 100ms delay pretty well masks it.
On the question of SOCK_FIN_WAIT, I tried having the server issue CR_CLOSE rather than CR_DISCON when it was done sending a response. This leaves the browser(chrome, local) hung for about 45 seconds then clears - some sort of timeout. Not a good idea. I have gone back to the original code of issuing CR_DISCON to end a session and only issuing CR_CLOSE if I see the SFW status. This seems to be fine.
