On Friday 01 October 2004 16:46, Berend De Schouwer wrote: [ snip ] Ouch! That cut-and-paste looks horrible. > I think so :) I'll cut-and-paste the headers, as reported by tcpdump > here. I can e-mail a whole dump, and lots of other info, to some > people, but I didn't want to flood the list. Lets put some comments in, and make it (a bit) more readable... 09:37:41.039607 IP (tos 0x0, ttl 64, id 40412, offset 0, flags [DF], length: 60) 10.16.2.143.32768 > 192.168.4.2.1023: S [tcp sum ok] 3746211625:3746211625(0) win 5840 <mss 1460,sackOK,timestamp 150930,nop,wscale 0> 09:37:41.118724 IP (tos 0x0, ttl 59, id 22622, offset 0, flags [none], length: 44) 192.168.4.2.1023 > 10.16.2.143.32768: S [tcp sum ok] 1626351996:1626351996(0) ack 3746211626 win 536 <mss 1460> 09:37:41.118761 IP (tos 0x0, ttl 64, id 40413, offset 0, flags [DF], length: 40) 10.16.2.143.32768 > 192.168.4.2.1023: . [tcp sum ok] ack 1 win 5840 Up to here: normal syn, syn/ack, ack. Negotiated mss 1460 and win 536. 09:37:41.118891 IP (tos 0x0, ttl 64, id 40414, offset 0, flags [DF], length: 308) 10.16.2.143.32768 > 192.168.4.2.1023: . 1:269(268) ack 1win 5840 Send 268 bytes of data, in one segment, in one fragment. 268 is half of the window size, and much less than mss. 09:37:41.118904 IP (tos 0x0, ttl 64, id 40415, offset 0, flags [DF], length: 83) 10.16.2.143.32768 > 192.168.4.2.1023: P 269:312(43) ack 1win Sent a second packet. I assume this is the first (and only) fragment of the second segment. Remainder of the 311 bytes of data. 5840 09:37:41.331573 IP (tos 0x0, ttl 121, id 8308, offset 0, flags [DF], length: 40) 192.168.4.2.1023 > 10.16.2.143.32768: . [tcp sum ok] ack 312 win 16305 Ack the first segment. 09:37:41.353036 IP (tos 0x0, ttl 121, id 8312, offset 0, flags [DF], length: 68) 192.168.4.2.1023 > 10.16.2.143.32768: P [tcp sum ok] 1:29 (28) ack 312 win 16305 Sends me data (but tells me my data is broken.) The rest of the packets are the final ACK, and the FIN sequence. 09:37:41.353072 IP (tos 0x0, ttl 64, id 40416, offset 0, flags [DF], length: 40) 10.16.2.143.32768 > 192.168.4.2.1023: . [tcp sum ok] ack 29 win 5840 09:37:41.353250 IP (tos 0x0, ttl 64, id 40417, offset 0, flags [DF], length: 40) 10.16.2.143.32768 > 192.168.4.2.1023: F [tcp sum ok] 312:312(0) ack 29 win 5840 09:37:41.374442 IP (tos 0x0, ttl 121, id 8315, offset 0, flags [DF], length: 40) 192.168.4.2.1023 > 10.16.2.143.32768: F [tcp sum ok] 29:29 (0) ack 312 win 16305 09:37:41.374476 IP (tos 0x0, ttl 64, id 40418, offset 0, flags [DF], length: 40) 10.16.2.143.32768 > 192.168.4.2.1023: . [tcp sum ok] ack 30 win 5840 09:37:41.457056 IP (tos 0x0, ttl 121, id 8316, offset 0, flags [DF], length: 40) 192.168.4.2.1023 > 10.16.2.143.32768: . [tcp sum ok] ack 313 win 16305 > > If that's true, it is a very limited TCP implementation indeed. > > I'm certain it's limited. > > > -- Jamie > > - > > : send the line "unsubscribe > > linux-net" in the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Berend - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
