WIZ811MJ (W5100) W5100 send TCP ACK DUP instead of regular TCP segment with data


I’ve encountered a strange problem.
I’ve set up my W5100 to use only one socket - SOCKET0. Both RX and TX buffers are configured to 4kB. RTR=4000. RCR=5. Using W5100 in bus mode (15bit address, 8bits data). Socket is configured as server and if there is any client connected sends TCP segment with 1460 bytes of data every 12ms. Before putting data to W5100 I am testing if there is enough room in the TX buffer. If there is no room I drop frame and try to send during next 12ms slot. I am using ioLibrary from https://www.wiznet.io/product-item/w5100/.
The issue I’ve encountered is about that from time to time packet are missed. Missed packet were put into W5100 TX buffer but weren’t received by host. In the slot time for the missed packet there is TCP ACK from W5100 which is identified as duplicate by Wireshark. It is marked on the attached picture. I didn’t find any regularity. Sometime it happens very often and somtime pretty rare. Wireshark identifies TCP ACK packet as duplicate of SYN+ACK packet send when connection was created.

What could be a root cause? How to fix this?

Duplicate ACK with Len=0 happens when you issue SEND command without modifying (or even touching) TX_WR register. In other words W5100 has nothing to send, and it sends ACK packet containg last Seq ID and data length 0. That’s why Wireshark sees it is duplicate. Check your code to ensure you do not perform SEND without putting data into the TX buffer (unless it is your deliberate action).

1 Like

Thanks a lot for the response. Will check is as soon as possible.

I didn’t find any suspected parts at code. It looks like the code handles W5100 according to the W5100 specification. ioLibrary is used to handle W5100 and send() API used to send a TCP segment. Do you have any other suspicious about what could be wrong?

Then check the code again. Put breakpoints into it (e.g. “press space key to continue”), so that you can see the wireshark in realtime and catch what part of code causes W5100 sending this packet.

It also matters where you take the Wireshark log. If W5100 is not directly connected to this device, and connected through some switch, that switch may inject packets. It is theoretical possibility, which is having low probability though.