W5100 incorrectly resends whole html page


#1

I have built a web server that serves a 1150 byte html page.
I poll it every 10 seconds thanks to a refresh command in the header:
meta http-equiv=“refresh” content=“10”
After a few hours, the server refuses to serve further responses to the “GET” command.
I have recorded the traffic using Wireshark.
What happens is that after the end of transmission of the page, the client does not acknowledge fast enough. Then, after 100 ms, the W5100 resends the whole page, but with flags PSH,ACK whereas it should be (if I am not mistaken) FIN,ACK. From then on, all goes wrong and the server does not answer any more.
Attached is a screenshot of the Wireshark page. The faulty frame is highlighted. Please note that for sake of memory size, my application sends the page in several packets, but the resend is done with the whole page at once.


#2

This is incorrect. Packets #59098, #59099 and further show keep alive exchange of the packets between .55 and .254, and futher there’s FIN/ACK from client and ACK by W5100.

And it seems you are right and client does not acknowledge end of communication with FIN and ACK to the server before W5100 timeout occurs, and W5100 resends the data, and does it right. But then driver for W5100 fails to disconnect, close connection and release the socket.

Look for logical (algorithmical) mistake in your W5100 driver. Please refer to tme W5100 datasheet chapter 5.


#3

Thanks Eugeny for your taking care of my problem. I tried to find a bug in my code, but so far did not find it. So I continued recording the traffic and I attach here a section where things go wrong when the remote client starts querying the server. Please explain me what this means.
analyseTrafic3.zip (1.8 KB)
Thanks!


#4

254 sends SYN, 55 (W5100) responds with SYN/ACK. But then it never gets ACK from 254, and performs retransmission of SYN/ACK.

Why it does not get final ACK to complete connection process is a good question. First of all, I would change MAC address from “DEAD_BEEF_FEED” to something else having bit 1 of first octet reset. Is there any other device with this generic MAC address in the subnetwork?

Something may be blocking packets. What is the location you capture Wireshark logs at? Do you capture at client side? Or at some other device on the network?

Edit: you use two ports: 53528 and 53529, and sequence number of 53528 of 7499866 looks suspicious. SYN/ACK is usually sequence 0, here I see big arbitrary number.

In addition, when connection is finally confirmed for port 53528 in packet 35, I see strange calculated window size of 16445440 (0xfaf0_00), however before it was reporting 8192. It may happen that some intermediary device (e.g. switch or router) may have issues with window size and window scaling.


#5

I do not understand why I should change my MAC address from
“locally managed” to “globally managed”. Can you explain me the
difference in term of system operation?

  There is no other device in the subnet with the same MAC address.

I am aware of the risk of duplicated MAC addresses, since I once
did the mistake of having two nodes with the same MAC address, and
I saw the mess it produced at the switch level !

  My test network is composed of a computer running Chrome as a web

client. It is connected to my access point through wifi, and the
router is connected by wired ethernet to my application under
test. In the connection to the application under test, I inserted
a hub that duplicates the frames and sends them to the ethernet
port of another computer which runs wireshark.

  So the capture is done at the server side, but there is an

internet router between the server and the client.


#6

Let me ask differenty - do you like your current MAC address, and is it too hard to try chaning it with bit 1 reset? Do you know and sure if bit 1 set, as you have it right now, has no negative consequences for other devices? Theoretically it should not.

I asked that quesiton because output seem to miss some packets. Put Windows or Linux host in between W5100 and router in bridge mode, and capture all the traffic on its both interfaces - only then you can be 100% sure that Wireshark logs all the packets.


#7

For your information : I ran a stress test on a test rig with the same configuration, and no problem happened. I am now looking for an electromagnetic disturbance in my real application.