Ask Your Question

I have implemented a TCP/IP stack on a PIC24 - I have an issue transferring larger files

asked 2022-08-29 05:07:39 +0000

updated 2022-08-29 16:36:58 +0000

Some preliminary information:

  • Browser: Firefox 104.0 (64-bit)
  • Server: Custom code. My server allows up to 18 sockets, 6 of which can be HTTP connections.

I have one last issue with my server implementation that I just cannot figure out. If the request is for a somewhat small file, usually the transfer happens without issue. When requesting larger files, the file transfer stalls.

My test case that works: Open a tab and enter http://SA-8.lan/favicon.ico. Hold shift and click on refresh. All works ok. favicon.ico is 489 bytes.

My test case that fails: Open a tab and enter http://sa-8.lan/js/math.min.js. Hold shift and click on refresh. Fails. math.min.js is 451.4 kB

This issue is that when the page is refreshed on the large file transfer, Firefox initiates a second HTTP request during the transfer of math.min.js. This should not present a problem as my server opens another socket (because the port number is different) and handles the 2nd request. What's odd is that when the next packet of the first socket is sent, the browser does not ACK it.

The sequence and ack numbers all look fine. Wireshark recognizes it as a TCP segment of a reassembled PDU. For some reason that I cannot understand, the browser does not ACK and, after a long delay, sends a TCP Keep-Alive with the Sequence # minus 1.

Why does the browser not respond to my packet segment?

Apparently I cannot attach the wireshark pcap until I have >60 something, so here is a link to a shared file: Also, here are the pertinent packet bytes in text form - Transaction No. 86 does not get a reply. Why?

No. Time    Source  Destination Protocol    Length  Info
1   0.000000000  TCP 74  39890 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312662211 TSecr=0 WS=128
2   0.001636251  TCP 66  80 → 39890 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.001673090  TCP 54  39890 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4   0.001745945  HTTP    454 GET /js/angular.min.js HTTP/1.1 
5   0.003977207  TCP 60  80 → 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=0
6   0.024330297  TCP 1514    80 → 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7   0.024361342  TCP 54  39890 → 80 [ACK] Seq=401 Ack=1461 Win=64128 Len=0
8   0.038601693 ...
edit retag flag offensive close merge delete


For real you can put a capture file on a publicly accessible file sharing site and post a link here.

Jaap gravatar imageJaap ( 2022-08-29 05:09:55 +0000 )edit

Excellent suggestion. Done. I guess I was too tired to think straight when I posted my question (after 1AM local time).

StartedWith400 gravatar imageStartedWith400 ( 2022-08-29 14:56:29 +0000 )edit

What's going on here:
81 1.306119233 HTTP 60 HTTP/1.1 503 Service Unavailable

Chuckc gravatar imageChuckc ( 2022-08-29 15:41:05 +0000 )edit

My mistake - I posted a version of the capture where I was experimenting with limiting the number of allowed HTTP sockets to 1. I recaptured with the number of allowed HTTP sockets back to 6. Sorry about the confusion, but the outcome is still the same - the browser does not ACK the data packet.

StartedWith400 gravatar imageStartedWith400 ( 2022-08-29 16:28:01 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2022-08-29 22:11:36 +0000

SYN-bit gravatar image

The TCP checksum of frame 86 is incorrect, so the TCP/IP stack will discard it and therefor no ACK is sent for this segment. As the FCS of the ethernet frame is valid (otherwise the frame would have been dropped by the NIC), I suspect there is an error in your checksum calculation function that produces the wrong checksum value.

edit flag offensive delete link more


That was it. Thank you so much for your time helping me out.

I had an 'automatic' packet begin call that occurred after a packet was filled. The intervening transfer on another socket interfered with the expectation that a new packet was already started. A little additional logic and the problem is solved.

StartedWith400 gravatar imageStartedWith400 ( 2022-08-30 03:34:38 +0000 )edit

Glad I was able to help out. Since you have not yet implemented TCP retransmissions, one error broke down the whole conversation. Which in this case was a good thing, as it made you fix this issue first. Next, implement a retransmission mechanism :-)

SYN-bit gravatar imageSYN-bit ( 2022-08-30 17:59:14 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2022-08-29 05:05:02 +0000

Seen: 68 times

Last updated: Aug 29