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 "[EMAIL PROTECTED]" _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
