W5500 gets TCP timeout even when peer has sent the ACK within timelimit (200 ms)
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: W5500 gets TCP timeout even when peer has sent the ACK within timelimit (200 ms)
by Eugeny ·
TCP conversation between nodes seem to be fine, I suspect that first ACK #2049 has been lost, the W5500 unexpectedly receives ACK for #2051, and resends all 4 bytes remaining in the buffer from previous ACK (7e472142). Then IMHO server properly responds.
Do you take this Wireshark log at the server side? Then you may not see whole picture. I advise you to put Windows 7 machine configured as network bridge with Wireshark connected directly to W5500, and then you will be able to see what is going on at the chip’s side. I think you may be surprised that some proxy or router confuses packets or decides for the involved communicating nodes that they need to break up, and instructs W5500 to close its connection from its side and then of course W5500 responds RST on any further packets from the server as its socket is closed.
RE: W5500 gets TCP timeout even when peer has sent the ACK within timelimit (200 ms)
by vdd ·
Hi Eugeny,
Thanks for the post!
I have found the fix for this issue. I was using TCP re-transmission counter to value 2. As per RFC the minimum value for TCP re-transmission counter should be 3. If it is not then the behavior could be unpredictable. And that’s the reason W5500 was sometime sending reset request. I have set the re-transmission counter to default value ( 7) as per w5500 datasheet. Every things works fine. No abnormal reset is found.