Berend De Schouwer wrote: > 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. Those aren't fragments. There is no IP fragmentation in these dumps. Those two packets are two TCP segments, in the expected order. > 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. That packet is ack'ing both segments. See the "ack 312": it acknowleges that all data up to position 312 has been received. 312 is the sequence number of the second data segment. TCP does not need to ack every 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. >From a TCP point of view that's fine. I presume the 28 octets are an error message from the application, and the application is broken in the way Henrik suggested. I don't know the exact reason why MSS is bounded at half the maximum window, but it seems quite feasible that would be a critical condition beyond which the complex interaction of delay ack/quick ack/silly window/estimation/congestion avoidance etc. etc. algoriths would behave differently. It's unfortunate that some of the heuristics in the TCP code aren't explained clearly. -- 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
