From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 21:42:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52506106566B for ; Mon, 15 Feb 2010 21:42:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 31B4A8FC14 for ; Mon, 15 Feb 2010 21:42:19 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta11.emeryville.ca.mail.comcast.net with comcast id iLu81d0041zF43QABMffkE; Mon, 15 Feb 2010 21:39:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta24.emeryville.ca.mail.comcast.net with comcast id iMje1d0043S48mS8kMjlYW; Mon, 15 Feb 2010 21:43:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 90F651E301A; Mon, 15 Feb 2010 13:42:01 -0800 (PST) Date: Mon, 15 Feb 2010 13:42:01 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100215214201.GA71304@icarus.home.lan> References: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> <20100215101148.GA56308@icarus.home.lan> <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ACK and RST packets sent after successfully terminating TCP connection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:42:20 -0000 On Mon, Feb 15, 2010 at 10:07:32PM +0100, n j wrote: > Hello Jeremy, > > > Is it possible for you to upload these captures somewhere on the web? > > tcpdump -p -i {iface} -s 0 -n -w {somefile} should be sufficient. > > You can find the two pcaps at http://drop.io/llwiy8o. IP addresses and > the data have been anonymized, everything else has been left intact. > There was no ICMP traffic between the hosts. Thanks for looking into > it! succ.pcap -- Packet #9: client --> server: client requests TCP connection close (FIN+ACK) Packet #10: server --> client: server sends ACK Packet #11: server --> client: server announces TCP window size of 0, indicating TCP receive buffers are exhausted and that the client should wait before doing anything more Packet #12: server --> client: identical re-sent ACK of packet #10 fail.pcap -- Packet #3: client --> server: initial handshake; TCP ACK Packet #4: server --> client: server sends TCP RST. Software on server likely closed the socket/fd Packet #5: server --> client: server announces TCP window size of 0, indicating TCP receive buffers are exhausted and that the client should wait before doing anything more Packet #6: server --> client: identical re-sent RST of packet #4 Packet #7: client --> server: confirms reset (RST+ACK) Whatever this client/server protocol is, it isn't normal/standard. It's not something like, for example, HTTP, SSH, or FTP; It's a custom protocol and one I haven't seen before. Do you see the above awkward behaviour (zero-sized TCP window packets followed by a retransmission of a prior packet) when using standardised protocols or software, such as Apache (HTTP), OpenSSH (SSH), or FTP? If not, then the client/server software is probably to blame. It may be operating on a raw socket level, populating IP and/or TCP portions of the packet itself rather than relying on socket(2) entirely. If it uses standard kernel socket(2) functionality with PF_INET and SOCK_STREAM, then I'd ask if the source is available publicly to be analysed to determine if this behaviour is intentional or not. Is there VPN and/or NAT involved between the client and server (re: NAT: particularly around the server)? Finally, is it possible to get "ifconfig -a" and "netstat -m" output from the server? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |