[lkml]   [1998]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: tcpdump and <nop,nop,timestamp xxx yyy>
   Date: 	Fri, 20 Mar 1998 22:30:44 -0700 (MST)
From: Chris Noe <>

Just noticed this while tcpdump'ing a recent telnet (over ppp) session:

17:30:10.799810 > S 3310621889:3310621889(0) win 32488 <mss 536,nop,nop,timestamp 112754 0,wscale 0,eol> (DF)
17:30:10.976449 > S 1854400001:1854400001(0) ack 3310621890 win 16768 <mss 1460,nop,wscale 0,nop,nop,timestamp 17611 112754>


What are these <nop,nop>'s doing before my timestamps?
Could they be affecting throughput? (two in *each* packet sent/recv'd)

I've never seen this before in 2.1.89, 2.0.29..

Probably just a cool new feature, eh?

It's RFC1323 TCP extensions for high performance. The timestamps
allow round-trip estimates even in the presence of lost packets.
The NOPS are there on purpose to align the timestamp 32-bit values on
4-byte boundaries in the headers, as suggested by the RFC and as also
implemented in just about every other stack which supports timestamps.

If you think these are weird, wait until SACKs (RFC2018) start showing
up on the wire after my next TCP merge to Linus ;-)

David S. Miller

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:41    [W:0.035 / U:5.984 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site