From owner-freebsd-net@FreeBSD.ORG Wed Feb 25 16:44:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2038C4DC; Wed, 25 Feb 2015 16:44:53 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77442FF1; Wed, 25 Feb 2015 16:44:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t1PGilQv057965; Thu, 26 Feb 2015 03:44:47 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 26 Feb 2015 03:44:46 +1100 (EST) From: Ian Smith To: Gary Palmer Subject: Re: What is this? In-Reply-To: <20150225145918.GD29176@in-addr.com> Message-ID: <20150226032414.F38620@sola.nimnet.asn.au> References: <20150225211159.U38620@sola.nimnet.asn.au> <20150225145918.GD29176@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 16:44:53 -0000 On Wed, 25 Feb 2015 14:59:18 +0000, Gary Palmer wrote: > On Wed, Feb 25, 2015 at 09:30:49PM +1100, Ian Smith wrote: > > This snippet is from an old linux 2.4 router/firewall/proxy box, usually > > clockwork. Clipped this while monitoring one night, saved it, forgot, > > but still find it curious and haven't seen anything similar before or > > since. 31.13.70.1 & 173.252.102.24 are facebook, our guy 192.168.9.21 > > > > 25/9/2014 what? rpc? no rpc here even internally. .21 is a win7 box. > > > > 22:34:15.753436 IP 31.13.70.1.443 > 192.168.9.21.3721: . 21784:23236(1452) ack 15573 win 65340 > > 22:34:15.753560 IP 31.13.70.1.443 > 192.168.9.21.3721: P 23236:23661(425) ack 15573 win 65340 > > 22:34:15.754017 IP 192.168.9.21.3721 > 31.13.70.1.443: . ack 23661 win 65535 > > 22:34:15.828235 IP 173.252.102.24.3660741704 > 192.168.9.21.2049: 735 proc-3090265999 > > 22:34:15.837027 IP 192.168.9.21.2049 > 173.252.102.24.3355443200: reply Unknown rpc response code=239244857 1452 > > 22:34:15.837031 IP 192.168.9.21.2049 > 173.252.102.24.1494367229: reply Unknown rpc response code=3295742795 33 > > 22:34:15.875408 IP 31.13.70.1.443 > 192.168.9.21.3721: . 23661:25113(1452) ack 15573 win 65340 > > 22:34:15.875552 IP 31.13.70.1.443 > 192.168.9.21.3721: P 25113:25677(564) ack 15573 win 65340 > > 22:34:15.875976 IP 192.168.9.21.3721 > 31.13.70.1.443: . ack 25677 win 65535 > > 22:34:16.114979 IP 173.252.102.24.443 > 192.168.9.21.2049: . ack 3841 win 64670 > > 22:34:16.116361 IP 173.252.102.24.443 > 192.168.9.21.2049: . ack 3874 win 64670 > > 22:34:16.117679 IP 173.252.102.24.4046617672 > 192.168.9.21.2049: 758 proc-685943137 > > 22:34:16.124011 IP 192.168.9.21.2049 > 173.252.102.24.2483027968: reply Unknown rpc response code=255805058 1177 > > 22:34:16.400004 IP 173.252.102.24.443 > 192.168.9.21.2049: . ack 5051 win 64670 > > 22:34:20.928488 IP 173.252.102.24.2100460616 > 192.168.9.21.2049: 1410 proc-3156600121 > > 22:34:20.935755 IP 192.168.9.21.2049 > 173.252.102.24.2483027968: reply Unknown rpc response code=269780798 1177 > > 22:34:21.211544 IP 173.252.102.24.443 > 192.168.9.21.2049: . ack 6228 win 64670 > > > > Kick me downstairs if it's just some old linux thing, especially the 2-3 > > giga(what?) port numbers, but otherwise, what is this about? > > Supposition: whatever you are using on Linux is seeing the 2049 port > number and trying to decode the packet as NFS traffic even though > it's not, and the port number isn't a port number at all but a NFS handle > or something, but it isn't really, it's just some data from the packet > contents that is in the location where the handle would be if the packet > were truly NFS. Ah, right, of course I should have checked /etc/services first .. nfsd 2049/sctp nfs # NFS server daemon nfsd 2049/tcp nfs # NFS server daemon nfsd 2049/udp nfs # NFS server daemon All that's running on linux is tcpdump -pn on the router - the traffic is with the win7 box - so I guess linux' tcpdump was (mis)interpreting. Seems that traffic was getting through anyway, but I didn't clip much. Thanks, Ian