Here's the TCP initial handshake:
17:30:44.951789 IP 213.207.90.2.48147 > 145.222.14.10.25: S
50514820:50514820(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK>
17:30:44.954496 IP 145.222.14.10.25 > 213.207.90.2.48147: S
4148480248:4148480248(0) ack 50514821 win 5840 <mss 1380,nop,wscale 2>
17:30:44.954519 IP 213.207.90.2.48147 > 145.222.14.10.25: . ack 1 win 49680
Later, as the receiver processes the network packets, it acknowledges
the data received, sends its receive window size (how much more it
is willing to receive).
Above, with "wscale 2" the server at 145.222.14.10 announces that
its TCP receive window value needs to be multiplied by a factor of
4 (binary number shifted left by 2).
But, there is a broken router in the path that does not understand
window scaling.
Here is an example of what gets f-ed up:
17:30:45.412222 IP 213.207.90.2.48147 > 145.222.14.10.25: . 20853:22233(1380)
ack 137 win 49680
17:30:45.412230 IP 213.207.90.2.48147 > 145.222.14.10.25: . 22233:23613(1380)
ack 137 win 49680
17:30:45.412249 IP 213.207.90.2.48147 > 145.222.14.10.25: P 23613:24993(1380)
ack 137 win 49680
17:30:45.412747 IP 145.222.14.10.25 > 213.207.90.2.48147: P ack 8433 win 5800
17:30:45.412748 IP 145.222.14.10.25 > 213.207.90.2.48147: P ack 8433 win 5800
17:30:45.412749 IP 145.222.14.10.25 > 213.207.90.2.48147: P ack 8433 win 5800
The receiver says they can receive bytes 8433-31633, but the broken
router does not know that 5800 needs to be multiplied by 4, and it
thinks the receiver can receive only bytes 8433-14233.
The broken router then throws away the bytes with higher sequence
numbers than 14233.
Workaround: turn off window scaling support on the sender's kernel.
Wietse
