Retransmission and RST before RTR timeout

I’m using the W5500. RTR and RCR are set as follows:

timeout_info.retry_cnt = 1;
timeout_info.time_100us = 0x07D0; // timeout value = 200ms

Sometimes I get unexplained socket closures. I captured this one with Wireshark. The W550, my PC running Wireshark, and a network switch are connected with an ethernet 3-way port mirroring switch. The switch is connected to our router.

W5500 ip address:
Server ip address:

Packet 19: MQTT Publish message from server
Packet 20: MQTT PUBACK back to server
Packet 21: Re-transmission of PUBACK (only 23 msec later)
Packet 22: Ack from server (23 msec after re-trans)
Packet 23: RST from W5500 (only 23 msec after re-trans)

Shouldn’t the W5500 wait 200 msec before re-transmission?
Shouldn’t there be more than one re-transmission before closing the socket?


More troubleshooting is needed. As I understood your PC is a “server”. What your PC sees is receiving retransmission of the packet. It does not state who did the retransmission, it could be a switch on behalf of W5500. Connect PC and W5500 directly without any gateways and switches (putting them in same subnetwork of course) and try again.

PC and W5500 are on the same subnetwork, and are connected through a mirror port.

W5500 ------------ Ethernet Port Mirroring Switch --------- Switch ----------Router ------ Internet -----Server
PC ---------------------------^

So the PC sees everything the W5500 sends or receives.

This is severe assumption which may be dramatically wrong.

I found my problem: see W5500 gets TCP timeout even when peer has sent the ACK within timelimit (200 ms) - #2 by Eugeny

The retry_count, which sets the RCR register, must be 3 or greater. Less than 3 leads to ‘unpredictable’ behavior.

Wish that was in the data sheet.

1 Like