From owner-freebsd-pf@FreeBSD.ORG Thu Jan 7 21:47:22 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5D4106566B for ; Thu, 7 Jan 2010 21:47:22 +0000 (UTC) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 96E438FC18 for ; Thu, 7 Jan 2010 21:47:22 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NT0CN-0006dg-M7 for freebsd-pf@freebsd.org; Thu, 07 Jan 2010 22:47:19 +0100 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 22:47:19 +0100 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 22:47:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Mark Atkinson Date: Thu, 07 Jan 2010 13:46:56 -0800 Lines: 20 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100104 Thunderbird/3.0 In-Reply-To: Sender: news Subject: Re: ftp problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 21:47:22 -0000 On 01/07/10 10:26, M. Keith Thompson wrote: > It does a list first to see which file to get. Then it tries to > download the 1st file. > > It starts downloading the file around: > > 14:40:49.668739 Yep, I see that, the only anomoly is no '226 transfer complete' on the command channel after the Fin + PSH from the server to the client. Not sure if this is the complete set data transferred or not, you maybe able to tell looking at the complete trace. The client finishes acking the rest of the data and then sends it's FIN as well, then the client closes the command channel and we see the 150 logout. I would suggest loading up the pcap in wireshark and look at the tcp analysis to see if it notes anything unusual in the sequence numbers, sizes, retransmits, etc that might be causing a problem.