wireshark and tcpdump -r: strange tcp window sizes

Question

I'm capturing http traffic with tcpdump and am interested in TCP slow start and how window sizes increase:

$ sudo tcpdump -i eth1 -w wget++.tcpdump tcp and port 80

When I view the dump file with Wireshark the progression of window sizes looks normal, i.e. 5840, 5888, 5888, 8576, 11264, etc...

But when I view the dump file via

$ tcpdump -r wget++.tcpdump -tnN | less

I get what seem to be nonsensical windows sizes ( IP addresses omitted for brevity ):

: S 1069713761:1069713761(0) win 5840 <mss 1460,sackOK,timestamp 24220583 0,nop,wscale 7>
: S 1198053215:1198053215(0) ack 1069713762 win 5672 <mss 1430,sackOK,timestamp 2485833728 24220583,nop,wscale 6>
: . ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . 1:1419(1418) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: P 1419:2002(583) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . ack 1419 win 133 <nop,nop,timestamp 2485833824 24220604>
: . ack 2002 win 178 <nop,nop,timestamp 2485833830 24220604>

Is there a way to get normal / absolute window sizes on the command line?

Answer 1

The window sizes are correct - they're just unscaled.

The connection initiator has set a wscale (window scaling factor) of 7, so its subsequent win values must be multiplied by 128 to get the window size in bytes. Thus the win 46 indicates a window of 5888 bytes.

The connection recipient has set a wscale of 6, so its win values must be multiplied by 64. Thus win 133 indicates a window of 8512 bytes, and win 178 indicates 11392 bytes.

Answer 2

Also, if the tool (wireshark or tcpdump, it doesn't matter) doesn't see the syn, it has to print the unscaled value, which can fool you