Retransmission and RST before RTR timeout

Question

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 wizchip_settimeout(&timeout_info); 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: 192.168.1.11 Server ip address: 20.49.109.146 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? image1869×118 11.6 KB Thanks.

Eugeny · Answer

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.

mwiz · Answer

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. Mary

mwiz · Answer

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.