Revision history [back]
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 TCP 1514 80 → 39890 [ACK] Seq=1461 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9 0.038618972 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=401 Ack=2921 Win=64128 Len=0
10 0.052858026 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 [ACK] Seq=2921 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11 0.052883415 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=401 Ack=4381 Win=64128 Len=0
.... (skipped some packets for brevity) ....
No. Time Source Destination Protocol Length Info
71 1.219332911 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=401 Ack=48181 Win=64128 Len=0
72 1.233711923 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 [ACK] Seq=48181 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73 1.275343115 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=401 Ack=49641 Win=64128 Len=0
74 1.288693443 10.0.0.188 10.0.0.225 TCP 74 39892 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312663499 TSecr=0 WS=128
75 1.289689153 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 [ACK] Seq=49641 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
76 1.291021096 10.0.0.225 10.0.0.188 TCP 66 80 → 39892 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77 1.291036249 10.0.0.188 10.0.0.225 TCP 54 39892 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78 1.291171415 10.0.0.188 10.0.0.225 HTTP 402 GET /favicon.ico HTTP/1.1
79 1.293348709 10.0.0.225 10.0.0.188 TCP 60 80 → 39892 [ACK] Seq=1 Ack=349 Win=186880 Len=0
80 1.299963557 10.0.0.225 10.0.0.188 TCP 101 80 → 39892 [ACK] Seq=1 Ack=349 Win=186880 Len=47 [TCP segment of a reassembled PDU]
81 1.299984281 10.0.0.188 10.0.0.225 TCP 54 39892 → 80 [ACK] Seq=349 Ack=48 Win=64256 Len=0
82 1.301555541 10.0.0.225 10.0.0.188 HTTP 60 HTTP/1.1 404 Not found
83 1.301979479 10.0.0.188 10.0.0.225 TCP 54 39892 → 80 [FIN, ACK] Seq=349 Ack=49 Win=64256 Len=0
84 1.303427429 10.0.0.225 10.0.0.188 TCP 60 80 → 39892 [ACK] Seq=49 Ack=350 Win=186880 Len=0
85 1.331334859 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=401 Ack=51101 Win=64128 Len=0
86 1.345386507 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 [ACK] Seq=51101 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
87 11.299340118 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
88 12.323329898 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
89 13.351333464 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
90 14.375333012 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
91 15.399330446 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [RST, ACK] Seq=401 Ack=51101 Win=64128 Len=0
Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.
P.S. Is there a way to debug the browser to see why is didn't ACK?
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 41202 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312662211 TSval=1312026123 TSecr=0 WS=128
2 0.001636251 0.001519852 10.0.0.225 10.0.0.188 TCP 66 80 → 39890 41202 [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 0.001560889 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4 0.001745945 0.001673032 10.0.0.188 10.0.0.225 HTTP 454 GET /js/angular.min.js HTTP/1.1
5 0.003977207 0.003887051 10.0.0.225 10.0.0.188 TCP 60 80 → 39890 41202 [ACK] Seq=1 Ack=401 Win=186880 Len=0
6 0.024330297 0.024216943 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 41202 [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 0.024239272 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 Ack=1461 Win=64128 Len=0
8 0.038601693 0.038301890 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 41202 [ACK] Seq=1461 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9 0.038618972 10.0.0.188 10.0.0.225 TCP 54 39890 0.038340740 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 Ack=2921 Win=64128 Len=0
10 0.052858026 0.052425962 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 41202 [ACK] Seq=2921 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11 0.052883415 10.0.0.188 10.0.0.225 TCP 54 39890 0.052459562 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 Ack=4381 Win=64128 Len=0
.... (skipped some packets for brevity) ....
No. Time Source Destination Protocol Length Info
71 1.219332911 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=401 Ack=48181 Win=64128 Len=0
72 1.233711923 1.208656628 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 41202 [ACK] Seq=48181 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73 1.275343115 10.0.0.188 10.0.0.225 TCP 54 39890 1.254572136 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 Ack=49641 Win=64128 Len=0
74 1.288693443 10.0.0.188 10.0.0.225 TCP 74 39892 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312663499 TSecr=0 WS=128
75 1.289689153 1.268635475 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 41202 [ACK] Seq=49641 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75 1.276658583 10.0.0.188 10.0.0.225 TCP 74 41204 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312027400 TSecr=0 WS=128
76 1.291021096 1.278292328 10.0.0.225 10.0.0.188 TCP 66 80 → 39892 41204 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77 1.291036249 10.0.0.188 10.0.0.225 TCP 54 39892 1.278336324 10.0.0.188 10.0.0.225 TCP 54 41204 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78 1.291171415 1.278516418 10.0.0.188 10.0.0.225 HTTP 402 GET /favicon.ico HTTP/1.1
79 1.293348709 1.280896982 10.0.0.225 10.0.0.188 TCP 60 80 → 39892 41204 [ACK] Seq=1 Ack=349 Win=186880 Len=0
80 1.299963557 1.287570511 10.0.0.225 10.0.0.188 TCP 101 80 → 39892 41204 [ACK] Seq=1 Ack=349 Win=186880 Len=47 [TCP segment of a reassembled PDU]
81 1.299984281 10.0.0.188 10.0.0.225 TCP 54 39892 1.287596789 10.0.0.188 10.0.0.225 TCP 54 41204 → 80 [ACK] Seq=349 Ack=48 Win=64256 Len=0
82 1.301555541 1.289099762 10.0.0.225 10.0.0.188 HTTP 60 HTTP/1.1 404 Not found
83 1.301979479 10.0.0.188 10.0.0.225 TCP 54 39892 1.289292405 10.0.0.188 10.0.0.225 TCP 54 41204 → 80 [FIN, ACK] Seq=349 Ack=49 Win=64256 Len=0
84 1.303427429 1.290905334 10.0.0.225 10.0.0.188 TCP 60 80 → 39892 41204 [ACK] Seq=49 Ack=350 Win=186880 Len=0
85 1.331334859 10.0.0.188 10.0.0.225 TCP 54 39890 1.310571817 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 Ack=51101 Win=64128 Len=0
86 1.345386507 1.324619741 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 41202 [ACK] Seq=51101 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
87 11.299340118 11.294575726 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
88 12.323329898 12.314605673 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
89 13.351333464 13.342577224 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
90 14.375333012 14.362582354 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 39890 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
91 15.399330446 10.0.0.188 10.0.0.225 TCP 54 39890 15.390582366 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [RST, ACK] Seq=401 Ack=51101 Win=64128 Len=0
Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.
P.S. Is there a way to debug the browser to see why is didn't ACK?
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 85 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 41202 43070 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312026123 TSval=1270624431 TSecr=0 WS=128
2 0.001519852 0.001635595 10.0.0.225 10.0.0.188 TCP 66 80 → 41202 43070 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3 0.001560889 0.001674970 10.0.0.188 10.0.0.225 TCP 54 41202 43070 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4 0.001673032 0.001751029 10.0.0.188 10.0.0.225 HTTP 454 451 GET /js/angular.min.js /js/math.min.js HTTP/1.1
5 0.003887051 0.004238756 10.0.0.225 10.0.0.188 TCP 60 80 → 41202 43070 [ACK] Seq=1 Ack=401 Ack=398 Win=186880 Len=0
6 0.024216943 0.024392047 10.0.0.225 10.0.0.188 TCP 1514 80 → 41202 43070 [ACK] Seq=1 Ack=401 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7 0.024239272 0.024405659 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 43070 → 80 [ACK] Seq=398 Ack=1461 Win=64128 Len=0
8 0.038301890 0.038481649 10.0.0.225 10.0.0.188 TCP 1514 80 → 41202 43070 [ACK] Seq=1461 Ack=401 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9 0.038340740 0.038494319 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 43070 → 80 [ACK] Seq=398 Ack=2921 Win=64128 Len=0
10 0.052425962 0.052616814 10.0.0.225 10.0.0.188 TCP 1514 80 → 41202 43070 [ACK] Seq=2921 Ack=401 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11 0.052459562 0.052638389 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 43070 → 80 [ACK] Seq=398 Ack=4381 Win=64128 Len=0
.... (skipped some packets for brevity) ....
No. Time Source Destination Protocol Length Info
72 1.208656628 1.220794991 10.0.0.225 10.0.0.188 TCP 1514 80 → 41202 43070 [ACK] Seq=48181 Ack=401 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73 1.254572136 1.266740106 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 43070 → 80 [ACK] Seq=398 Ack=49641 Win=64128 Len=0
74 1.268635475 1.280819523 10.0.0.225 10.0.0.188 TCP 1514 80 → 41202 43070 [ACK] Seq=49641 Ack=401 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75 1.276658583 1.301652905 10.0.0.188 10.0.0.225 TCP 74 41204 43074 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312027400 TSval=1270625733 TSecr=0 WS=128
76 1.278292328 1.303284866 10.0.0.225 10.0.0.188 TCP 66 80 → 41204 43074 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77 1.278336324 1.303316377 10.0.0.188 10.0.0.225 TCP 54 41204 43074 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78 1.278516418 1.303445281 10.0.0.188 10.0.0.225 HTTP 402 399 GET /favicon.ico HTTP/1.1
79 1.280896982 10.0.0.225 10.0.0.188 TCP 60 80 → 41204 1.305447545 10.0.0.225 10.0.0.188 TCP 150 80 → 43074 [ACK] Seq=1 Ack=349 Ack=1 Win=186880 Len=0
80 1.287570511 10.0.0.225 10.0.0.188 TCP 101 80 → 41204 [ACK] Seq=1 Ack=349 Win=186880 Len=47 Len=96 [TCP segment of a reassembled PDU]
80 1.305467257 10.0.0.188 10.0.0.225 TCP 54 43074 → 80 [ACK] Seq=346 Ack=97 Win=64256 Len=0
81 1.287596789 1.306119233 10.0.0.225 10.0.0.188 HTTP 60 HTTP/1.1 503 Service Unavailable
82 1.306246772 10.0.0.188 10.0.0.225 TCP 54 41204 → 80 [ACK] Seq=349 Ack=48 Win=64256 Len=0
82 1.289099762 10.0.0.225 10.0.0.188 HTTP 60 HTTP/1.1 404 Not found
83 1.289292405 10.0.0.188 10.0.0.225 TCP 54 41204 43074 → 80 [FIN, ACK] Seq=349 Ack=49 Seq=346 Ack=98 Win=64256 Len=0
83 1.307186083 10.0.0.225 10.0.0.188 TCP 60 80 → 43074 [ACK] Seq=98 Ack=347 Win=186880 Len=0
84 1.290905334 10.0.0.225 10.0.0.188 TCP 60 80 → 41204 [ACK] Seq=49 Ack=350 Win=186880 Len=0
85 1.310571817 1.322753934 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [ACK] Seq=401 43070 → 80 [ACK] Seq=398 Ack=51101 Win=64128 Len=0
86 1.324619741 85 1.336850281 10.0.0.225 10.0.0.188 TCP 1514 80 → 41202 43070 [ACK] Seq=51101 Ack=401 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
87 11.294575726 86 11.290742683 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
88 12.314605673 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
89 13.342577224 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
90 14.362582354 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
91 15.390582366 10.0.0.188 10.0.0.225 TCP 54 41202 → 80 [RST, ACK] Seq=401 43070 → 80 [ACK] Seq=397 Ack=51101 Win=64128 Len=0
Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.
P.S. Is there a way to debug the browser to see why is didn't ACK?
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 I'll put the pertinent packet bytes in text form - Transaction No. 85 does not get a reply. Why?here)
No. Time Source Destination Protocol Length Info
1 0.000000000 10.0.0.188 10.0.0.225 TCP 74 43070 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270624431 TSecr=0 WS=128
2 0.001635595 10.0.0.225 10.0.0.188 TCP 66 80 → 43070 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3 0.001674970 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4 0.001751029 10.0.0.188 10.0.0.225 HTTP 451 GET /js/math.min.js HTTP/1.1
5 0.004238756 10.0.0.225 10.0.0.188 TCP 60 80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=0
6 0.024392047 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7 0.024405659 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=1461 Win=64128 Len=0
8 0.038481649 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=1461 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9 0.038494319 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=2921 Win=64128 Len=0
10 0.052616814 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=2921 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11 0.052638389 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=4381 Win=64128 Len=0
.... (skipped some packets for brevity) ....
No. Time Source Destination Protocol Length Info
72 1.220794991 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=48181 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73 1.266740106 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=49641 Win=64128 Len=0
74 1.280819523 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=49641 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75 1.301652905 10.0.0.188 10.0.0.225 TCP 74 43074 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270625733 TSecr=0 WS=128
76 1.303284866 10.0.0.225 10.0.0.188 TCP 66 80 → 43074 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77 1.303316377 10.0.0.188 10.0.0.225 TCP 54 43074 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78 1.303445281 10.0.0.188 10.0.0.225 HTTP 399 GET /favicon.ico HTTP/1.1
79 1.305447545 10.0.0.225 10.0.0.188 TCP 150 80 → 43074 [ACK] Seq=1 Ack=1 Win=186880 Len=96 [TCP segment of a reassembled PDU]
80 1.305467257 10.0.0.188 10.0.0.225 TCP 54 43074 → 80 [ACK] Seq=346 Ack=97 Win=64256 Len=0
81 1.306119233 10.0.0.225 10.0.0.188 HTTP 60 HTTP/1.1 503 Service Unavailable
82 1.306246772 10.0.0.188 10.0.0.225 TCP 54 43074 → 80 [FIN, ACK] Seq=346 Ack=98 Win=64256 Len=0
83 1.307186083 10.0.0.225 10.0.0.188 TCP 60 80 → 43074 [ACK] Seq=98 Ack=347 Win=186880 Len=0
84 1.322753934 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=51101 Win=64128 Len=0
85 1.336850281 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=51101 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
86 11.290742683 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 43070 → 80 [ACK] Seq=397 Ack=51101 Win=64128 Len=0
Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.
P.S. Is there a way to debug the browser to see why is didn't ACK?
I have implemented a TCP/IP stack on a PIC24 - I have an issue transferring larger fileswith large .js
Some preliminary information:
Browser:Browser - Firefox 104.0 (64-bit)Server: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 I'll put the pertinent packet bytes here)
No. Time Source Destination Protocol Length Info
1 0.000000000 10.0.0.188 10.0.0.225 TCP 74 43070 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270624431 TSecr=0 WS=128
2 0.001635595 10.0.0.225 10.0.0.188 TCP 66 80 → 43070 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3 0.001674970 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4 0.001751029 10.0.0.188 10.0.0.225 HTTP 451 GET /js/math.min.js HTTP/1.1
5 0.004238756 10.0.0.225 10.0.0.188 TCP 60 80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=0
6 0.024392047 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7 0.024405659 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=1461 Win=64128 Len=0
8 0.038481649 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=1461 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9 0.038494319 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=2921 Win=64128 Len=0
10 0.052616814 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=2921 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11 0.052638389 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=4381 Win=64128 Len=0
.... (skipped some packets for brevity) ....
No. Time Source Destination Protocol Length Info
72 1.220794991 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=48181 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73 1.266740106 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=49641 Win=64128 Len=0
74 1.280819523 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=49641 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75 1.301652905 10.0.0.188 10.0.0.225 TCP 74 43074 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270625733 TSecr=0 WS=128
76 1.303284866 10.0.0.225 10.0.0.188 TCP 66 80 → 43074 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77 1.303316377 10.0.0.188 10.0.0.225 TCP 54 43074 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78 1.303445281 10.0.0.188 10.0.0.225 HTTP 399 GET /favicon.ico HTTP/1.1
79 1.305447545 10.0.0.225 10.0.0.188 TCP 150 80 → 43074 [ACK] Seq=1 Ack=1 Win=186880 Len=96 [TCP segment of a reassembled PDU]
80 1.305467257 10.0.0.188 10.0.0.225 TCP 54 43074 → 80 [ACK] Seq=346 Ack=97 Win=64256 Len=0
81 1.306119233 10.0.0.225 10.0.0.188 HTTP 60 HTTP/1.1 503 Service Unavailable
82 1.306246772 10.0.0.188 10.0.0.225 TCP 54 43074 → 80 [FIN, ACK] Seq=346 Ack=98 Win=64256 Len=0
83 1.307186083 10.0.0.225 10.0.0.188 TCP 60 80 → 43074 [ACK] Seq=98 Ack=347 Win=186880 Len=0
84 1.322753934 10.0.0.188 10.0.0.225 TCP 54 43070 → 80 [ACK] Seq=398 Ack=51101 Win=64128 Len=0
85 1.336850281 10.0.0.225 10.0.0.188 TCP 1514 80 → 43070 [ACK] Seq=51101 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
86 11.290742683 10.0.0.188 10.0.0.225 TCP 54 [TCP Keep-Alive] 43070 → 80 [ACK] Seq=397 Ack=51101 Win=64128 Len=0
Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.
P.S. Is there a way to debug the browser to see why is didn't ACK?