First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

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

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: https://ln5.sync.com/dl/ac4466430/ykdcndnf-2tkf7zuk-fk2nuujs-q5ytenpk. 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 10.0.0.188  10.0.0.225  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 10.0.0.225  10.0.0.188  TCP 66  80 → 39890 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.001673090 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4   0.001745945 10.0.0.188  10.0.0.225  HTTP    454 GET /js/angular.min.js HTTP/1.1 
5   0.003977207 10.0.0.225  10.0.0.188  TCP 60  80 → 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=0
6   0.024330297 10.0.0.225  10.0.0.188  TCP 1514    80 → 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7   0.024361342 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=401 Ack=1461 Win=64128 Len=0
8   0.038601693 10.0.0.225  10.0.0.188 ...
(more)
StartedWith400's avatar
3
StartedWith400
asked 2022-08-29 05:07:39 +0000, updated 2022-08-29 16:36:58 +0000
edit flag offensive 0 remove flag close merge delete

Comments

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

Jaap's avatar Jaap (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's avatar StartedWith400 (2022-08-29 14:56:29 +0000) edit

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

Chuckc's avatar Chuckc (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's avatar StartedWith400 (2022-08-29 16:28:01 +0000) edit
add a comment see more comments

1 Answer

0

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.

SYN-bit's avatar
18.5k
SYN-bit
answered 2022-08-29 22:11:36 +0000
edit flag offensive 0 remove flag delete link

Comments

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's avatar StartedWith400 (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's avatar SYN-bit (2022-08-30 17:59:14 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer