W5500 sends RST ACK to client

Question

Hello, I’m using W5500 for a server application and I configured it to receive requests on port 1002 (4 sockets, for specific application) and on port 80 (4 sockets, for http web browsers). It happens that when client opens a http page and performs multiple parallel requests, the W5500 answers back with the [RST, ACK] packet in response to the [SYN] packet sent by the client (see attached Wireshark capture) 2704×1058 218 KB , the page loading is not completed and those requests are aborted by the clients. I found this behaviour on MAC OSX using Safari or Firefox and also on iOS devices, not on Windows OS. This is shown using Safari Web Inspector 2882×908 560 KB and Console Messages 2786×294 63.6 KB Could anyone explain this and how to solve it? Thanks E.M.Villa

emvilla · Answer

Hi midnightcow, thank you for your answer. I already tried, as you suggest, to open more sockets (all 8 sockets on port 80) and, as far as all sockets are available, everything works fine, but when some socket becomes busy, because more clients are connected, the available sockets for a further connection are less than 8 and the problem is still present. I wonder why clients (in particular Safari on OSX and iOS) do not retry and abort requests or if there is a particular setting for W5500 to avoid this. Regards E.M.Villa

emvilla · Answer

Hi midnightcow, I understand that the [RST, SYN] packet is sent when no more sockets are available and, indeed, this happens when all sockets are busy. Let me explain better the problem. The sockets are initialized and they go to SOCK_LISTEN state. I can monitor the Sn_SRs of the various sockets and I see that they all assume the value = 0x14 When clients start the requests the states of the sockets move to SOCK_ESTABILISHED (Sn_SR = 0x17). This happens for all the sockets that receive a requests. In case of multiple simultaneous requests, more sockets go into state 0x17. If one more request arrives when all sockets are in SOCK_ESTABILISHED state, W5500 answers back to the [SYN] packet with the [RST, ACK] packet, instead of the [SYN, ACK] as it does normally when a socket is available. As you wrote, the reason is the lack of an available socket. This is clear. What happens is that, while on Windows based system the process continues and the browser at the end gets all files, on OSX / iOS systems the browser stops and does not get all files. Those requests that received [RST, ACK] answer are dropped and browser does not ask anymore or keep waiting. I’m not telling that this could be a Wiznet problem, I’m only describing what happens with different browsers and on different OSs. I attach two Wireshark capture files (see zip file): Wiznet-Firefox-Win7.pcapng: capture made on Windows7 system while getting the htm page using Firefox Wiznet-Safari-OSX.pcapng: capture made on MAC OSX system while getting the htm page using Safari. Of course, the requested page is the same and the Wiznet is operating in the same condition and with the same configuration in both cases. Following your suggestions, I tried to replace the DISCON command with the CLOSE command but what happens is that the browsers hang on and keep waiting the answer of the server, both on Windows and on OSX. I cannot simplify the page and I also if I increase the web socket count (even up to 8), the problem is…

emvilla · Answer

Hi midnightcow, I knew this. Although HTTP 1.1 specifications recommend to not perform more than two request simultaneously, most browsers do it, some do up to 6 parallel connections, some others up to 8. There is documentation of this on the web. I imagined that was a problem related to browser implementation, but I hoped there was a solution that I could manage at the source. It is difficult to say to the customer that he must configure his browser in particular way. The answer would be: “my browser works fine with everything, why not with your product?”. Specially on smartphones or tablets where configuration options are not avaliable or quite limited. Could Wiznet keep additional requests in stand by until a socket become available instead of responding immediately with [RST ACK] packet? Doing so, all browsers could manage automatically the missing answer with their timeout and eventually perform more retries. If not today, maybe in future releases of the chip or in future products. I think Wiznet is a valid product and I hope it will improved to take in account this problem. Thank you very much for your support and answers. Best regards E.M. Villa

alexpescaru · Answer

emvilla, midnightcow answered you pretty well and to the point when he told you to end any web server response in a much quicker manner by closing the socket instead of disconnecting it. For the end web browser this will be the same thing. The disconnect command could take very long time and the sockets could get all very quickly unavailable, therefore RST/ACK. After you send the data/response, the close command (instead of disconnect) will free the socket instantly and that socket will be available for the next request. So, considering that any web server response could take say 50-100 ms to process/transmit a response, for 8 sockets, this mean about 6-12 ms per request. I don’t think that you are getting more than 100 requests per second on your embedded web server… If yes, maybe a different approach/chip may be in order…

emvilla · Answer

Hi Alex, the difference between disconnecting and closing a socket and what it implies are clear. I don’t know if you had a look to my wireshark capture files (see attached above) and if you can explain the difference in Windows-Firefox and OSX-Safari with the same W5500 configuration. To simplify the problem I made the following test: I setup only one socket of the eight available in W5500 to accept connection on port 80. The other seven are configured on a different port so that they are not available to the HTTP port used by the browser. My HTML page is made by HTML code and includes some graphic images and references to some external javascript files. The total page load is several hundreds of kByte, splitted in different files, so it take a while to be loaded. What happens is that as soon the browser loads the HTML and starts to process it, it requests the other resources, i.e. graphics and javascript files. To do this the browser sends multiple parallel requests, in order to speed up the uploading. Having only one socket available, W5500 can accept only one request at a time and I expect that the browser keeps waiting that every request is accepted as soon as the socket becomes free and hence, one after the other, and all the images and the js file are sent to the browser. Of course, the page loading will be slow because of the availability of only one socket. I found that Firefox on Windows can load the page while Safari on OSX/iOS not because W5500 answer with [RST ACK] packet to the multiple parallel requests to the [SYN] packet. The server application and W5500 are running in the same condition. Could you explain why please? I’m not saying that W5500 is operating wrong but I would like to found a reason and a solution without having to setting any particular configuration in the browser. Regards E.M.Villa

hjjeon0608 · Answer

Hi, There is difference Windows and MAC OS. And it is because MAC and Windows handle the issue differently. And it is dependent OS not W5500.