Hi list, I have several linux boxes hooked to a gigabit switch and accidentally noticed that tcpdump reports packages with size larger than 1500: tcpdump greater 1600 -n This produces many lines of output with packets with size > 1500 (2960, 4420, etc.) The MTU of the interface is 1500 (reported by ifconfig), the MTU on the other boxes hooked to the same switch is also 1500. This would be OK if it was limited to the intranet only (although strange as the MTU is 1500 on all boxes), but this also happens for packets going out to the Internet. I traced a tcp connection to an outside host on both sides and notices that both hosts send an mss of 1460 during connection initialization, but the first packet (and all other) that the box in question sends is with length 2960, which on the other side is received and acknowledged as two packets with length 1500. This suggest that someone on the way (probably the first router) does fragmentation, which is OK. The problem is that eventually packets on the remote host start to arrive with changed order, which tcp handles as expected, but this somehow prevents the tcp window from growing and as a result the transfer rate never gets high enough to utilize the line. What I`m trying to find out is how come packets leaving my box have larger size than the MTU of interface (I`m guessing that if I solve that, no additional fragmentation will occur, packets will arrive in the right order and tcp windows will grow as expected). Few notes: - kernel on the boxes in question: 2.6.14.6 and 2.6.15 - the line to the boxes is wide enough to handle 100Mbit/s, if I try the same test that I describe but in the other direction, I get the full 100Mbit/s speed as tcp window grows high enough to allow this even with latency > 100ms. - boxes in question use e1000 driver. -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
