From owner-freebsd-pf@FreeBSD.ORG Sat Jun 16 19:45:49 2007 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65CDF16A47C for ; Sat, 16 Jun 2007 19:45:49 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.freebsd.org (Postfix) with ESMTP id 21A1513C448 for ; Sat, 16 Jun 2007 19:45:49 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 222391CC4B; Sat, 16 Jun 2007 15:29:53 -0400 (EDT) Date: Sat, 16 Jun 2007 15:29:53 -0400 From: Adam McDougall To: Volker Message-ID: <20070616192952.GB87503@egr.msu.edu> References: <200706140833.50583.rmiranda@digitalrelay.ca> <200706140921.53115.rmiranda@digitalrelay.ca> <46715C7F.4060602@vwsoft.com> <200706160826.16372.rmiranda@digitalrelay.ca> <4673FFC7.2030904@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4673FFC7.2030904@vwsoft.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-pf@freebsd.org Subject: Re: PF error message looping on screen. System Locked. 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: Sat, 16 Jun 2007 19:45:49 -0000 On Sat, Jun 16, 2007 at 05:20:39PM +0200, Volker wrote: On 06/16/07 15:26, Roger Miranda wrote: > On Thursday 14 June 2007 10:19, Volker wrote: >> [re-added cc:pf to have a wider audience, please keep this] >> >> On 06/14/07 16:21, Roger Miranda wrote: >>>> I remember a discussion about your machine in stable@ some time ago. >>> Yes. I have come a bit further. Generally I would get nothing on the >>> screen. I just started getting this. >>> >>>>> We have transfered 150GB (+/-) >>>> Using sftp, ftp, http or ...? >>> http / NFS / SMB >>> >>>> Are you by any chance being able to get a photopicture (with fast >>>> shutter time) of the debug messages? Do you have anything in >>>> /var/log/debug.log /var/log/messages which might be useful? >>> I do not have nothing with that fast of a shutter. I looked in the logs >>> the message the loops is not there. But I did find the follwoing: >>> >>> Jun 13 10:22:32 kernel: pf: dropping packet with ip options >>> Jun 13 10:22:33 last message repeated 5 times >> Roger, >> >> I don't think this message is related to your trouble. I think you can >> also avoid these messages by adding 'no scrub' to your pf.conf (I'm >> currently not aware of any side effects by adding this). >> >> Probably Max has some more suggestions on not scrubbing packets. >> >> You should get a debugger into your kernel (like Max suggested) and >> probably also use `pfctl -x loud' or `pfctl -x misc' to get more >> messages out of pf. If these messages are popping up again, break the >> system into the debugger and look for the messages (using 'scroll >> lock' to scroll back some pages), ps and a backtrace. >> >> HTH >> >> Volker > Alright, I have encoutered the loop messages again today. > I have debug set to loud and "no scrub" is in pf.conf. > > I managed to get a 5 sec. video of the loop. Get it at: > http://64.201.181.165:82/pfloop.avi > > Any help would be appreciated. > > Roger > Roger, watched your video (the next time, please mix some nice music in... just kidding). I've seen tons of 'pf: loose state match' messages. After seen this, I took again a look at your rules and am wondering about this one: rdr on $int_if inet proto tcp from any to any port www -> \ 127.0.0.1 port 3128 pass in log on $int_if route-to lo0 inet proto tcp from any to \ any port 3128 keep state I've never tried a combination like that but I think it might be dangerous. When a packet arrives your $int_if with a destination port 80, the rdr rule will replace the destination address to 127.0.0.1 port 3128. The pass rule will route that packet to lo0. I think you can safely avoid that extra step. Try it just like: rdr on $int_if inet proto tcp from any to any port www -> \ 127.0.0.1 port 3128 pass in log quick on $int_if inet proto tcp from any to \ any port 3128 flats S/SA keep state and see if you still see error messages. (Please note the missing 'route-to' statement, an added quick statement and the added 'flags S/SA' option) If that doesn't help, I recommend rewriting your rules a bit and use 'set state-policy if-bound' (which I'm using most as I find it better to administer). Unfortunately I don't have experience with state-policy if-bound in a bridged environment (just a little warning). I was thinking the same thing regarding if-bound. I use if-bound in production on a pf bridge and found it avoids lots of loose state match and other state confusion. Also, I have found using pf loud debugging tends to deadlock the console after not too long if I have more than one cpu enabled, so I avoid using it in production. After much testing, I feel comfortable without it, however interesting it is. HTH Volker _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"