views:

48

answers:

1

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?

+1  A: 

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.

caf
First, why is this done? Second, is there a way I can get `tcpdump` to automatically do the scaling in the output when viewing the dump file the way Wireshark does?
Robert S. Barnes
@Robert: It's done this way because the original TCP/IP spec provided a 16 bit field for window size; when this was found to be insufficient, the window scaling mechanism allowed it to represent larger numbers without having to change the field size. It doesn't appear that there is a way of showing scaled window sizes in `tcpdump` - you could always submit a patch ;) You could always use `tshark` (Wireshark's text-based version) instead.
caf