Retransmission and RST before RTR timeout

TCP/IP Chip W5500
1

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?

image
image1869×118 11.6 KB

Thanks.

2

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.

3

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

4

This is severe assumption which may be dramatically wrong.

5

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