From nobody@FreeBSD.org  Fri Jan 25 09:19:18 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 827A037B400
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 25 Jan 2002 09:19:15 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g0PHJFf72544;
	Fri, 25 Jan 2002 09:19:15 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200201251719.g0PHJFf72544@freefall.freebsd.org>
Date: Fri, 25 Jan 2002 09:19:15 -0800 (PST)
From: Jeff Kletsky <jeff+freebsd@spotlife.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: tcpdump -v incorectly identifies packets as NFS
X-Send-Pr-Version: www-1.0

>Number:         34269
>Category:       bin
>Synopsis:       tcpdump -v incorectly identifies packets as NFS
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    fenner
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 25 09:20:03 PST 2002
>Closed-Date:    Tue Aug 30 10:11:23 GMT 2005
>Last-Modified:  Tue Aug 30 10:11:23 GMT 2005
>Originator:     Jeff Kletsky
>Release:        
>Organization:
SpotLife
>Environment:
4.4-PRERELEASE FreeBSD 4.4-PRERELEASE #2: Fri Aug 24 16:10:47 PDT 2001   
4.5-RC FreeBSD 4.5-RC #0: Wed Jan 16 09:01:11 PST 2002

tcpdump/VERSION -- 3.6.3

/* $FreeBSD: src/contrib/tcpdump/tcpdump.c,v 1.4.2.1 2001/07/26 22:30:02 fenner Exp $ */
# fgrep FreeBSD *nfs*
nfs.h: * $FreeBSD: src/contrib/tcpdump/nfs.h,v 1.2.2.1 2001/07/26 22:30:00 fenner Exp $
nfsfh.h: *      $FreeBSD: src/contrib/tcpdump/nfsfh.h,v 1.5.2.1 2001/07/26 22:30:00 fenner Exp $
parsenfsfh.c: * $FreeBSD: src/contrib/tcpdump/parsenfsfh.c,v 1.5.2.1 2001/07/26 22:30:00 fenner Exp $



>Description:
tcpdump -v parses TCP packets that are part of a valid HTTP request/response
exchange in the format of an NFS packet.  This has caused "false alarms" about
security of networks here. Note the improperly-parsed packets in the
example of the output below:

# tcpdump -nv port 2049
08:30:34.545243 216.106.74.90.2049 > 208.48.65.12.80: S [tcp sum ok] 6953841:6953841(0) win 8192 <mss 536,nop,nop,sackOK> (DF) (ttl 112, id 64830, len 48)
08:30:34.546152 208.48.65.12.80 > 216.106.74.90.2049: S [tcp sum ok] 1333449278:1333449278(0) ack 6953842 win 8767 <mss 1380> (ttl 254, id 0, len 44)
08:30:34.948079 216.106.74.90.2049 > 208.48.65.12.80: . [tcp sum ok] ack 1 win 8576 (DF) (ttl 112, id 1343, len 40)
08:30:34.964025 216.106.74.90.2049 > 208.48.65.12.796226405: reply ERR 396 (DF) (ttl 112, id 1599, len 436)
08:30:34.965233 208.48.65.12.80 > 216.106.74.90.2049: . [tcp sum ok] ack 397 win 32836 (ttl 64, id 14650, len 40)
08:30:35.017109 208.48.65.12.791752241 > 216.106.74.90.2049: 247 proc-542008692 (ttl 64, id 14651, len 287)
08:30:35.017900 208.48.65.12.976170870 > 216.106.74.90.2049: 63 proc-1831826803 (ttl 64, id 14652, len 103)
08:30:35.018116 208.48.65.12.80 > 216.106.74.90.2049: F [tcp sum ok] 311:311(0) ack 397 win 33232 (ttl 63, id 14653, len 40)
08:30:35.540344 216.106.74.90.2049 > 208.48.65.12.80: . [tcp sum ok] ack 311 win 8266 (DF) (ttl 112, id 4927, len 40)
08:30:35.554091 216.106.74.90.2049 > 208.48.65.12.80: . [tcp sum ok] ack 312 win 8266 (DF) (ttl 112, id 5439, len 40)
08:30:35.554363 216.106.74.90.2049 > 208.48.65.12.80: F [tcp sum ok] 397:397(0) ack 312 win 8266 (DF) (ttl 112, id 5695, len 40)
08:30:35.554863 208.48.65.12.80 > 216.106.74.90.2049: . [tcp sum ok] ack 398 win 33232 (ttl 64, id 14654, len 40)


At this location, this only seems to occur for return packets to port 2049 on a remote system.
This may occur under other conditions as well, not seen here.
>How-To-Repeat:
# tcpdump -nv 
(on a network with sufficient traffic to have TCP traffic from port 2049
on a remote machine)

Also, output of 

# tcpdump -w tcpdump.2049 -c 1000 -i fxp0 port 2049

available at 
http://wildside.wagsky.com/freebsd/tcpdump.2049

# tcpdump -vnr tcpdump.2049

avaialble at
http://wildside.wagsky.com/freebsd/tcpdump.2049.vnr

which can be seen to exhibit the same symptoms when processed with

# tcpdump -v -r tcpdump.2049

(files are approximately 100 kB each)
>Fix:
Possible workaround, use -q flag to bypass NFS parsing -- however this
disables all advanced parsing and limits utility of tools built on top
of tcpdump

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->fenner 
Responsible-Changed-By: kris 
Responsible-Changed-When: Sat Jul 12 22:38:49 PDT 2003 
Responsible-Changed-Why:  
Over to the tcpdump maintainer 


http://www.freebsd.org/cgi/query-pr.cgi?pr=34269 
State-Changed-From-To: open->feedback 
State-Changed-By: bms 
State-Changed-When: Mon Jun 14 15:09:17 GMT 2004 
State-Changed-Why:  
Can the submitter attempt to reproduce the problem with a more recent 
version of tcpdump (e.g. tcpdump 3.8.3 now in -CURRENT) and report if 
the problem still exists? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=34269 
State-Changed-From-To: feedback->closed 
State-Changed-By: matteo 
State-Changed-When: Tue Aug 30 10:11:07 GMT 2005 
State-Changed-Why:  
feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=34269 
>Unformatted:
