From owner-freebsd-stable@FreeBSD.ORG Fri Jul 28 20:20:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57C9716A4EC for ; Fri, 28 Jul 2006 20:20:28 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA62443D46 for ; Fri, 28 Jul 2006 20:20:27 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6SKKOAw017685; Fri, 28 Jul 2006 16:20:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 28 Jul 2006 16:20:23 -0400 To: Stefan Bethke From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-stable@freebsd.org Subject: Re: Weird problems with 'pf' (on both 5.x and 6.x) 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: Fri, 28 Jul 2006 20:20:28 -0000 At 9:30 PM +0200 7/28/06, Stefan Bethke wrote: >Am 28.07.2006 um 03:57 schrieb Garance A Drosihn: > >>It occurred to me that it might be more informative to >>see the transaction from the *freebsd* side of things, >>since that's the machine running pf! So, here is a >>similar set of two lpq's, as seen from the print-server >>side of the connection. It seems to be telling the >>same basic story, as far as I can tell. > >It's just showing that no ACKs come back. Can you see >if anything showing pflog0 with tcpdump? Thanks for the reply. I'll check that when I get a chance to turn the machine back on. (the air-conditioning for our offices just died -- AGAIN -- so I had to shut down most of my machines today). >That output should also tell you which rule forced the >rejection. There is only one rule. The config file I'm testing with has three comment lines, and: pass out quick proto { tcp, udp } all keep state That's it. That's the entire /etc/pf.conf file. >What I do find curious is that the client keeps using >port 1023 consistently. I was under the impression that >reusing the same port number (thus having the same >src-ip/port+dst-ip/port tuple) shouldn't work, because >"old" packets could arrive after the original connection >was closed; that's what the CLOSE_WAIT state in netstat is. Hmm. Well, I did wait a few seconds between the two lpq's, just so it would be easier tell them apart in the packet dumps. Perhaps solaris is quicker to reuse ports, while 'pf' remembers that src-ip/port+dst-ip/port tuple for a longer stretch of time? But if so, there were seven seconds between the end of the first 'lpq' and the first attempt to start a connection for the second one. The 'pf' side didn't start returning ACK's until 111 seconds after the first connection had closed. That seems like a pretty long time to wait. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu