---
title: "SOCK_FIN_WAIT, SnRX_RSR transient issues"
url: "https://maker.wiznet.io/forum/10901"
markdown_url: "https://maker.wiznet.io/forum/10901/md"
type: "Forum topic"
category: "Ethernet Chips"
author: "Bill2009"
created: "2015-03-14T12:14:38+09:00"
last_activity: "2017-05-04T08:35:20+09:00"
language: "en"
views: 1327
replies: 5
source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)"
---

# SOCK_FIN_WAIT, SnRX_RSR transient issues

## Question

Asked by Bill2009 on 2015-03-14 in Ethernet Chips.

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/](http://wiznetmuseum.com/portfolio-items/minimal-http-server-with-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/](https://olduino.wordpress.com/2015/03/09/tcphttp-hll-but-some-light/)

Are these expected situations? Is there a better way to deal with them?

## Replies

### Reply 1 by Bill2009, 2015-03-19

Thank you. I am away from home for a couple of weeks but i will capture it with wireshark in April.

### Reply 2 by Bill2009, 2015-04-20

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.

[![](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/ee9e4d39e26800a21c903d5dde6f09dad354da16.jpg) 1280×897 424 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/ee9e4d39e26800a21c903d5dde6f09dad354da16.jpg)

[![](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/169c28e1b0c223f38f0ecc9c30c895104da8f75b.jpg) 824×516 129 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/169c28e1b0c223f38f0ecc9c30c895104da8f75b.jpg)

[0length.wireshark.txt](https://maker.wiznet.io/uploads/short-url/gKATvMtLKsOdGOluqiypBE5bxGt) (12.8 KB)

### Reply 3 by Coccoliso, 2015-04-21

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.

### Reply 4 by Bill2009, 2015-04-21

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.

### Reply 5 by Bill2009, 2015-04-21

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.

---

Source: https://maker.wiznet.io/forum/10901