![]() ![]() So the question is what causes the client to pause for that long time. In this case the RST has sent, beause the server has closed his socket in the meantime of 9 Minutes. ![]() After that he is glad and closes the session in the same milisecond as the Request, too. And then after more than 9 Minutes (that is what I meant with delayed) he sends his Request. Because he still wants to send something. Failing that, you may want to ask your question (with more context) on Wiresharks Forum if you want help leveraging Wireshark or Server Fault if you want help tracking down the loss. Which is more or less immediately ACKED by the client, so the client is still alive.īut the client does not close his half-session, too. You could use the display filter, which can be used with both Wireshark and PyShark. Then ~30 sec after the 3WAY Handshake (05:47:39.491) the server terminates the session by a half close (FIN-Bit). ![]() So the server starts the discussed "Spurious Retransmission" after ~30 sec. But after the 3WAY Handshake, when normally the POST Request is transmitted nothing happens. So what we see is that the session has been initiated at 05:46:48.155. Which seems to be fine.īut in the second picture the session has a duration of more than 10 Minutes. Also you can see in the primary picture that the whole session inclusive Request has a duration of 13ms. ![]() 123 device with the W5500 chip.The reason for the session is to transmit the POST Request which can be seen in FRAME 323. If the network is slow, but not always necessary, it is impossible to open the web page. The problem I have is with the one implementing a web server. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |