From balustefan at gmail.com  Sun Apr  1 11:10:16 2012
From: balustefan at gmail.com (Stefan Balu)
Date: Sun Apr  1 11:10:21 2012
Subject: kern/166411: [pf] simply enabling pf makes udpxy not to work
Message-ID: <201204011110.q31BAFlm074564@freefall.freebsd.org>

The following reply was made to PR kern/166411; it has been noted by GNATS.

From: Stefan Balu <balustefan@gmail.com>
To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= <eri@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/166411: [pf] simply enabling pf makes udpxy not to work
Date: Sun, 1 Apr 2012 14:06:55 +0300

 --f46d040f9bae54ce2504bc9c12d4
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 This seems to have fixed the problem. Thank you!
 
 On Wed, Mar 28, 2012 at 12:41 PM, Ermal Lu=C3=A7i <eri@freebsd.org> wrote:
 
 > Normally this is the effect of pf(4) default behviour of dropping
 > packets with ip-options.
 >
 > You need to enable those with 'allow-opts' added to the rule.
 >
 > --
 > Ermal
 >
 
 
 
 --=20
 =C8=98tefan B=C4=82LU
 Tel: +40757 377 489
 
 --f46d040f9bae54ce2504bc9c12d4
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 This seems to have fixed the problem. Thank you!<br><br><div class=3D"gmail=
 _quote">On Wed, Mar 28, 2012 at 12:41 PM, Ermal Lu=C3=A7i <span dir=3D"ltr"=
 >&lt;<a href=3D"mailto:eri@freebsd.org">eri@freebsd.org</a>&gt;</span> wrot=
 e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
 eft:1px #ccc solid;padding-left:1ex">
 Normally this is the effect of pf(4) default behviour of dropping<br>
 packets with ip-options.<br>
 <br>
 You need to enable those with &#39;allow-opts&#39; added to the rule.<br>
 <span class=3D"HOEnZb"><font color=3D"#888888"><br>
 --<br>
 Ermal<br>
 </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
 r>=C8=98tefan B=C4=82LU<br>Tel: +40757 377 489<br>
 
 --f46d040f9bae54ce2504bc9c12d4--
From bugmaster at FreeBSD.org  Mon Apr  2 11:07:14 2012
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr  2 11:09:33 2012
Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org
Message-ID: <201204021107.q32B7DPU046867@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/166411  pf         [pf] simply enabling pf makes udpxy not to work
o kern/166336  pf         [pf] kern.securelevel 3 +pf reload
o kern/165315  pf         [pf] States never cleared in PF with DEVICE_POLLING
o kern/164402  pf         [pf] pf crashes with a particular set of rules when fi
o kern/164271  pf         [pf] not working pf nat on FreeBSD 9.0 [regression]
o kern/163208  pf         [pf] PF state key linking mismatch
o kern/160370  pf         [pf] Incorrect pfctl check of pf.conf
o kern/155736  pf         [pf] [altq] borrow from parent queue does not work wit
o kern/153307  pf         [pf] Bug with PF firewall
o kern/148290  pf         [pf] "sticky-address" option of Packet Filter (PF) blo
o kern/148260  pf         [pf] [patch] pf rdr incompatible with dummynet
o kern/147789  pf         [pf] Firewall PF no longer drops connections by sendin
o kern/143543  pf         [pf] [panic] PF route-to causes kernel panic
o bin/143504   pf         [patch] outgoing states are not killed by authpf(8)
o conf/142961  pf         [pf] No way to adjust pidfile in pflogd
o conf/142817  pf         [patch] etc/rc.d/pf: silence pfctl
o kern/141905  pf         [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697  pf         [pf] pf behaviour changes - must be documented
o kern/137982  pf         [pf] when pf can hit state limits, random IP failures 
o kern/136781  pf         [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948  pf         [pf] [gre] pf not natting gre protocol
o kern/135162  pf         [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996  pf         [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732  pf         [pf] max-src-conn issue
o kern/132769  pf         [pf] [lor] 2 LOR's with pf task mtx / ifnet and  rtent
f kern/132176  pf         [pf] pf stalls connection when using route-to [regress
o conf/130381  pf         [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861  pf         [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920  pf         [pf] ipv6 and synproxy don't play well together
o conf/127814  pf         [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439  pf         [pf] deadlock in pf
o kern/127121  pf         [pf] [patch] pf incorrect log priority
o kern/127042  pf         [pf] [patch] pf recursion panic if interface group is 
o kern/125467  pf         [pf] pf keep state bug while handling sessions between
s kern/124933  pf         [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364  pf         [pf] [panic] Kernel panic with pf + bridge
o kern/122773  pf         [pf] pf doesn't log uid or pid when configured to
o kern/122014  pf         [pf] [panic] FreeBSD 6.2 panic in pf
o kern/120281  pf         [pf] [request] lost returning packets to PF for a rdr 
o kern/120057  pf         [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355   pf         [pf] [patch] pfctl(8) help message options order false
o kern/114567  pf         [pf] [lor] pf_ioctl.c + if.c
s conf/110838  pf         [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283  pf         pfsync fails to sucessfully transfer some sessions
o kern/103281  pf         pfsync reports bulk update failures
o kern/93825   pf         [pf] pf reply-to doesn't work
o sparc/93530  pf         [pf] Incorrect checksums when using pf's route-to on s
o kern/92949   pf         [pf] PF + ALTQ problems with latency
o bin/86635    pf         [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271   pf         [pf] cbq scheduler cause bad latency

50 problems total.

From kim at hppremium.co.za  Tue Apr  3 06:47:15 2012
From: kim at hppremium.co.za (Kim)
Date: Tue Apr  3 06:47:23 2012
Subject: Premium hospital cover
Message-ID: <14049273@news2.procontact.us>

Unsubscribe Here

 http://www.procontact.co.za/app/bulk_mailer/comp/view_form/view_form.php?15431%3A%3A1+Vsgbwf+freebsd-pf@freebsd.org+53777%3A72++4457%3B%3B1%3B

Get consultants to call me back with Premium Hospital Cover quotes.
http://www.hppremium.co.za/?sourceID=10000036&amp;campaignID=51

This plan pays a pre-defined daily benefit from your 3rd day in hospital, if
 you are hospitalised for 3 or more days, but the daily benefit is paid from
 day 1. You can use the money as you wish.

http://www.hppremium.co.za/?sourceID=10000036&amp;campaignID=51

>From R198 a month get up to R5000 a day while you are in hospital
Cash back benefit � Get 6 premiums back in cash after your 60th payment
Accidental death benefit � get up to R500 000 cover
Accidental disability benefit -- get up to R500 000 paid out to you
Maternity benefits included
Dread disease benefit � get up to R250 000
ICU benefit � get an additional cash benefit for each day spent in ICU
No medical examinations required

http://www.hppremium.co.za/?sourceID=10000036&amp;campaignID=51

Be advised that product benefits and offering may differ from insurer to
 insurer.
From mikemacleod at gmail.com  Tue Apr  3 19:24:20 2012
From: mikemacleod at gmail.com (Michael MacLeod)
Date: Tue Apr  3 19:24:26 2012
Subject: PF And Cone NAT
Message-ID: <CAM-FeoENCu2dxCJM6GAY-SRaGh9Qvaik5OrhgjBNRT1Nbjx45w@mail.gmail.com>

Ladies and Gentlemen,

Every once and a while I run into an issue wherein the symmetric NAT of pf
causes me grief. I've found some older mailing list entries asking about PF
and Cone or Full Cone NAT (such as this one from 2005:
http://www.mail-archive.com/freebsd-pf@freebsd.org/msg00804.html), but I
haven't seen anything new in a while.

Almost all discussion I can find suggests to use static-port on the NAT
rule entry, but this doesn't seem to be entirely the same thing. Adding
static-port will prevent PF from randomizing the source port used for
outbound TCP and UDP traffic, but I don't see any mention of it enabling
actual Cone behaviour with regards to inbound traffic destined for the
now-not-random port. It appears that a NAT table entry, even with the
static-port option, will still not accept an inbound packet
from external IP B when the NAT rule was originally created for external IP
A, which I gather is the main thrust of cone NAT.

I understand that cone NAT is a generally terrible and insecure way to do
NAT, but game and application developers seem hell-bent on depending on
cone NAT behaviour. Is there a way to make it work with PF?

Regards,
Mike
From jasjus.bwi at gmail.com  Thu Apr  5 23:50:38 2012
From: jasjus.bwi at gmail.com (just man man)
Date: Thu Apr  5 23:50:45 2012
Subject: nat vlan
Message-ID: <CAJm50m9u94_3JB9kVDvajNhaqWGEoycYW3=zsahTbjvLHzFbhQ@mail.gmail.com>

How to nat multi vlan in PF in freebsd?

thank you
From Greg.Hennessy at nviz.net  Fri Apr  6 00:16:41 2012
From: Greg.Hennessy at nviz.net (Greg Hennessy)
Date: Fri Apr  6 00:16:47 2012
Subject: nat vlan
In-Reply-To: <CAJm50m9u94_3JB9kVDvajNhaqWGEoycYW3=zsahTbjvLHzFbhQ@mail.gmail.com>
References: <CAJm50m9u94_3JB9kVDvajNhaqWGEoycYW3=zsahTbjvLHzFbhQ@mail.gmail.com>
Message-ID: <9EB23F6C23A8B6488E8BCC92A48E832616BE0484D0@PEMEXMBXVS04.jellyfishnet.co.uk.local>

Put the vlan interfaces into an interface group and nat that... 

> -----Original Message-----
> From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-
> pf@freebsd.org] On Behalf Of just man man
> Sent: Friday, 6 April 2012 9:51 AM
> To: freebsd-pf@freebsd.org
> Subject: nat vlan
> 
> How to nat multi vlan in PF in freebsd?
> 
> thank you
> _______________________________________________
> 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"
From jasjus.bwi at gmail.com  Sat Apr  7 00:05:47 2012
From: jasjus.bwi at gmail.com (just man man)
Date: Sat Apr  7 00:05:54 2012
Subject: nat vlan
In-Reply-To: <9EB23F6C23A8B6488E8BCC92A48E832616BE0484D0@PEMEXMBXVS04.jellyfishnet.co.uk.local>
References: <CAJm50m9u94_3JB9kVDvajNhaqWGEoycYW3=zsahTbjvLHzFbhQ@mail.gmail.com>
	<9EB23F6C23A8B6488E8BCC92A48E832616BE0484D0@PEMEXMBXVS04.jellyfishnet.co.uk.local>
Message-ID: <CAJm50m-e-A=V9FQO_RDnYF1aJPMsmVLhc=ECp8ZsFPf=DzzXrA@mail.gmail.com>

Thank you, ,do you have tutorial for bandwidth management for IP in vlan.
my topology like below:

internet ------ main
router(pf+freebed)----------router1(pf+freebsd)............VLAN......

my plan:
Bandwidth management in main router
Nat in router1

Thank you


On Fri, Apr 6, 2012 at 8:15 AM, Greg Hennessy <Greg.Hennessy@nviz.net>wrote:

> Put the vlan interfaces into an interface group and nat that...
>
> > -----Original Message-----
> > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-
> > pf@freebsd.org] On Behalf Of just man man
> > Sent: Friday, 6 April 2012 9:51 AM
> > To: freebsd-pf@freebsd.org
> > Subject: nat vlan
> >
> > How to nat multi vlan in PF in freebsd?
> >
> > thank you
> > _______________________________________________
> > 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"
>
From sales at offdocs.com  Sat Apr  7 02:57:23 2012
From: sales at offdocs.com (OFFDOCS Limited (EA))
Date: Sat Apr  7 02:57:29 2012
Subject: Human Resources,Business & Legal Document Templates
Message-ID: <E1SGKuY-00045V-6J@Ndovu.stratechkenya.com>

You can now download hundreds of business forms, templates, and contracts online today. 

Find documents for almost every kind of business such as;

 - Purchase orders, 
 - Partnership agreements, 
 - Loan agreements, applications,
 - Bill of sale. 

You can also browse our list by popular categories such as;


 - Marketing
 - Legal
 - Finance
 - Real estate 

Purchase these affordable off-the-shelf documents if you are starting a business,you already are in business, or if you are just looking at your options to get to the next level.

Experts in this field professionally prepared all these documents.Please consider that these documents will protect your business and assist you in fulfilling your legal obligations in line with best practice.


For more information visit http://www.offdocs.com or email sales@offdocs.com


Regards;

Sales Team
OFFDOCS LIMITED

M:   +254-721-351269
T:    +254-20-313770

Hamilton House,
Kaunda St. 2nd Floor, Suite 3,
P.O. Box 18534 - 00100
Nairobi - Kenya
------------------------------------------------------------------------------------------------------------------------------------------------------
DISCLAIMER:
This email and any files transmitted with it are confidential and intended solely for the 
use of the individual or entity to whom they are addressed. If you have received this email 
in error please notify admin@offdocs.com. This message contains confidential 
information and is intended only for the individual named. If you are not the intended 
recipient, please notify the sender immediately,delete this Message and do not disclose, 
distribute or copy it to any third party or otherwise use this Message.<br>Click the link below to unsubscribe from our mailing list <br> http://www.webmasters.co.ke/mailer/unsub.php?id=80466&t=1333761294&cid=21
From artemrts at ukr.net  Sat Apr  7 05:02:37 2012
From: artemrts at ukr.net (wishmaster)
Date: Sat Apr  7 05:02:43 2012
Subject: nat vlan
In-Reply-To: <CAJm50m-e-A=V9FQO_RDnYF1aJPMsmVLhc=ECp8ZsFPf=DzzXrA@mail.gmail.com>
References: <CAJm50m9u94_3JB9kVDvajNhaqWGEoycYW3=zsahTbjvLHzFbhQ@mail.gmail.com>
	<CAJm50m-e-A=V9FQO_RDnYF1aJPMsmVLhc=ECp8ZsFPf=DzzXrA@mail.gmail.com>
	<9EB23F6C23A8B6488E8BCC92A48E832616BE0484D0@PEMEXMBXVS04.jellyfishnet.co.uk.local>
Message-ID: <62491.1333774950.2235850529908850688@ffe15.ukr.net>



  --- Original message ---
 From: "just man man" <jasjus.bwi@gmail.com>
 To: "Greg Hennessy" <Greg.Hennessy@nviz.net>
  Date: 7 April 2012, 03:06:10
 Subject: Re: nat vlan
 
 


> Thank you, ,do you have tutorial for bandwidth management for IP in vlan.
 
   Some googling, man 5 pf.conf, man 4 altq, examples in /usr/share/examples/pf, official FAQ on OpenBSD.org.

> my topology like below:
> 
> internet ------ main
> router(pf+freebed)----------router1(pf+freebsd)............VLAN......
> 
> my plan:
> Bandwidth management in main router
> Nat in router1
> 
> Thank you
> 
> 
> On Fri, Apr 6, 2012 at 8:15 AM, Greg Hennessy <Greg.Hennessy@nviz.net>wrote:
> 
> > Put the vlan interfaces into an interface group and nat that...
> >
> > > -----Original Message-----
> > > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-
> > > pf@freebsd.org] On Behalf Of just man man
> > > Sent: Friday, 6 April 2012 9:51 AM
> > > To: freebsd-pf@freebsd.org
> > > Subject: nat vlan
> > >
> > > How to nat multi vlan in PF in freebsd?
> > >
> > > thank you
> > > _______________________________________________
> > > 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"
> >
> _______________________________________________
> 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"
From bugmaster at FreeBSD.org  Mon Apr  9 11:07:18 2012
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr  9 11:09:30 2012
Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org
Message-ID: <201204091107.q39B7Hwt039689@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/166411  pf         [pf] simply enabling pf makes udpxy not to work
o kern/166336  pf         [pf] kern.securelevel 3 +pf reload
o kern/165315  pf         [pf] States never cleared in PF with DEVICE_POLLING
o kern/164402  pf         [pf] pf crashes with a particular set of rules when fi
o kern/164271  pf         [pf] not working pf nat on FreeBSD 9.0 [regression]
o kern/163208  pf         [pf] PF state key linking mismatch
o kern/160370  pf         [pf] Incorrect pfctl check of pf.conf
o kern/155736  pf         [pf] [altq] borrow from parent queue does not work wit
o kern/153307  pf         [pf] Bug with PF firewall
o kern/148290  pf         [pf] "sticky-address" option of Packet Filter (PF) blo
o kern/148260  pf         [pf] [patch] pf rdr incompatible with dummynet
o kern/147789  pf         [pf] Firewall PF no longer drops connections by sendin
o kern/143543  pf         [pf] [panic] PF route-to causes kernel panic
o bin/143504   pf         [patch] outgoing states are not killed by authpf(8)
o conf/142961  pf         [pf] No way to adjust pidfile in pflogd
o conf/142817  pf         [patch] etc/rc.d/pf: silence pfctl
o kern/141905  pf         [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697  pf         [pf] pf behaviour changes - must be documented
o kern/137982  pf         [pf] when pf can hit state limits, random IP failures 
o kern/136781  pf         [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948  pf         [pf] [gre] pf not natting gre protocol
o kern/135162  pf         [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996  pf         [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732  pf         [pf] max-src-conn issue
o kern/132769  pf         [pf] [lor] 2 LOR's with pf task mtx / ifnet and  rtent
f kern/132176  pf         [pf] pf stalls connection when using route-to [regress
o conf/130381  pf         [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861  pf         [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920  pf         [pf] ipv6 and synproxy don't play well together
o conf/127814  pf         [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439  pf         [pf] deadlock in pf
o kern/127121  pf         [pf] [patch] pf incorrect log priority
o kern/127042  pf         [pf] [patch] pf recursion panic if interface group is 
o kern/125467  pf         [pf] pf keep state bug while handling sessions between
s kern/124933  pf         [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364  pf         [pf] [panic] Kernel panic with pf + bridge
o kern/122773  pf         [pf] pf doesn't log uid or pid when configured to
o kern/122014  pf         [pf] [panic] FreeBSD 6.2 panic in pf
o kern/120281  pf         [pf] [request] lost returning packets to PF for a rdr 
o kern/120057  pf         [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355   pf         [pf] [patch] pfctl(8) help message options order false
o kern/114567  pf         [pf] [lor] pf_ioctl.c + if.c
s conf/110838  pf         [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283  pf         pfsync fails to sucessfully transfer some sessions
o kern/103281  pf         pfsync reports bulk update failures
o kern/93825   pf         [pf] pf reply-to doesn't work
o sparc/93530  pf         [pf] Incorrect checksums when using pf's route-to on s
o kern/92949   pf         [pf] PF + ALTQ problems with latency
o bin/86635    pf         [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271   pf         [pf] cbq scheduler cause bad latency

50 problems total.

From 1HourLoan at Super-Loan.co.za  Mon Apr  9 12:36:46 2012
From: 1HourLoan at Super-Loan.co.za (Super-Loan.co.za)
Date: Mon Apr  9 12:37:28 2012
Subject: FREEBSD PF, Securing a R150,
 000 Personal Loan in 1 Hour is that Easy - Super-Loan.co.za
Message-ID: <BE938DC9-5332-45D4-B01E-567D0F677AFD@Sender>

Hi FREEBSD PF,

Let?s be realistic.  Everyone needs a little extra cash from time to time.  Maybe it?s for splashing out on a much needed renovation, affording that wedding you always wanted, paying for unforeseen medical bills or perhaps it?s simply for consolidating your debt.

BUT, do you really want to spend 2 hours in a bank queue over lunch? And especially if you don?t even know whether you will even get the loan or what your repayments will be?

In today?s fast paced world, we simply don?t have time for these hassles.

That?s where we at Super-Loan.co.za come in.  Securing a loan up to R150,000 in under one business hour has never been this easy and hassle free!

Simply complete a 1 minute online form and that?s it.  Yes, we will take it from there and let you know within one business hour what loan you qualify for and what your repayments will be.  We assure you there is no other process like this in South Africa.

Give us a try, go to www.Super-Loan.co.za, or apply now

Thanks

The Super-Loan.co.za team

 

Get yourself a R150,000 loan in an hour

Our Services include:
1) Online automated loan application process
2) Step by step guidance and advice from our professionally trained staff
3) Best loan offer provided with in an hour based on your personal circumstance
4) Totally secure application process using SSL Encryption


Email sent by SA Consumer Foundation
SA Consumer Foundation | 120 1st Avenue | Hyde Park, JHB, Gauteng 2196
2012 SA Consumer Foundation All Rights Reserved.


If you did not wish to receive this, please unsubscribe from further emails  at http://www.formstack.com/forms/sa-emailunsubscribe?email=freebsd-pf@freebsd.org

If you consider this email unsolicited bulk mail, please report SPAM at http://www.formstack.com/forms/sa-reportspam?email=freebsd-pf@freebsd.org&email_from=1HourLoan@Super-Loan.co.za
From Anti-Virus-From at sha.pilship.com  Wed Apr 11 00:39:59 2012
From: Anti-Virus-From at sha.pilship.com (Anti-Virus-From)
Date: Wed Apr 11 00:40:07 2012
Subject: c150B.pilship.com  Virus removed from message
Message-ID: <20120411003959.A8F1C1065812@hub.freebsd.org>

The following viruses were repaired or dropped from the message (MID 310267)
    'Troj/ZipMal-AW', 'W32/MyDoom-O'

And, Attachments dropped during repair.

Actions taken:
    Message delivered

Original Envelope Sender:
    From freebsd-pf@freebsd.org Wed Apr 11 08:38:48 2012

Message Headers:
    From: freebsd-pf@freebsd.org
    To: ivy.xiong@szx.pilship.com
    Subject: Message could not be delivered
    Date: Wed, 11 Apr 2012 08:45:36 +0800
    Content-Type: multipart/mixed;	boundary="----=_NextPart_000_0009_7102E042.81FD5FAD"
    X-Priority: 3
    X-MSMail-Priority: Normal
    X-Mailer: Microsoft Outlook Express 6.00.2600.0000
    X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
From nobody at nic.fr  Wed Apr 11 07:29:40 2012
From: nobody at nic.fr (Echo de Messagerie)
Date: Wed Apr 11 07:29:49 2012
Subject: [Echo de Message] Votre message a echo@nic.fr
Message-ID: <201204110722.q3B7MS0a027728@gibil.prod-int.prive.th3.nic.fr>

Madame, Monsieur,

Vous avez envoye un message a l'adresse <echo@afnic.fr>.
Voici donc ci-apres le message tel que nous l'avons recu.
Verifier notamment que les adresses de l'enveloppe et dans
le corps du message sont correctes.

Expediteur:

        enveloppe:      freebsd-pf@freebsd.org
        entete:         freebsd-pf@freebsd.org

L'automate Echo de Messagerie de l'AFNIC.

    --------oooooooo00000000ooooooooo---------

>From freebsd-pf@freebsd.org  Wed Apr 11 09:22:28 2012
Return-Path: <freebsd-pf@freebsd.org>
X-Original-To: ping@gibil.prod-int.prive.th3.nic.fr
Delivered-To: ping@gibil.prod-int.prive.th3.nic.fr
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162])
	by gibil.prod-int.prive.th3.nic.fr (Postfix) with ESMTP id 98DAC3560001
	for <ping@gibil.prod-int.prive.th3.nic.fr>; Wed, 11 Apr 2012 09:22:28 +0200 (CEST)
Received: by relay1.nic.fr (Postfix)
	id 96DBE4C0029; Wed, 11 Apr 2012 09:22:28 +0200 (CEST)
Delivered-To: ping@nic.fr
Received: from mx5.nic.fr (mx5.nic.fr [IPv6:2001:67c:2218:2::4:13])
	by relay1.nic.fr (Postfix) with ESMTP id 7A3DD4C0006
	for <ping@nic.fr>; Wed, 11 Apr 2012 09:22:28 +0200 (CEST)
Received: from mx5.nic.fr (localhost [127.0.0.1])
	by mx5.nic.fr (Postfix) with SMTP id 6F10630004F
	for <ping@nic.fr>; Wed, 11 Apr 2012 09:22:28 +0200 (CEST)
Received: by mx5.nic.fr (Postfix, from userid 1137)
	id 4E4593001BB; Wed, 11 Apr 2012 09:22:28 +0200 (CEST)
Received: from freebsd.org (unknown [58.192.55.233])
	by mx5.nic.fr (Postfix) with ESMTP id A792C30004F
	for <ping@nic.fr>; Wed, 11 Apr 2012 09:22:24 +0200 (CEST)
From: freebsd-pf@freebsd.org
To: ping@nic.fr
Subject: [PMX:VIRUS] Returned mail: see transcript for details
Date: Wed, 11 Apr 2012 15:22:26 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0013_6A7AAAE9.F9F6ABDB"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Bogosity: Yes, tests=bogofilter, spamicity=1.000000, version=1.2.2
Message-Id: <30126_1334128948_4F853134_30126_10769_1_20120411072228.4E4593001BB@mx5.nic.fr>
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2012.4.11.70031
X-PerlMx-Virus-Detected: W32/MyDoom-O
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='
 HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_10000_PLUS 0, BOUNCE_ENVELOPE 0, BOUNCE_GENERIC 0, BOUNCE_NDR 0, FORGED_MUA_OUTLOOK 0, NO_REAL_NAME 0, RDNS_NXDOMAIN 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, USER_AGENT_OE 0, __ANY_URI 0, __BOUNCE_NDR_SUBJECT_CONTAINS 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __DATE_TZ_HK 0, __HAS_MSGID 0, __HAS_MSMAIL_PRI 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __OUTLOOK_MUA 0, __OUTLOOK_MUA_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT_MS_GENERIC 0'

This is a multi-part message in MIME format.



------=_NextPart_000_0013_6A7AAAE9.F9F6ABDB
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit




------=_NextPart_000_0013_6A7AAAE9.F9F6ABDB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The original content of this message part has been replaced
by this text because it tested positive for the following
virus(es):

    W32/MyDoom-O

The original message has been quarantined pending further
action by the mail administrator.  For further information
about the message and its delivery status, please contact
the undersigned, and include the full content of this
message.  The identifier for this message is
'4F853134_30126_10769_1'.

This notification is being sent to you and any other
original envelope recipient(s).   To avoid creating a
From thciobanu at nth.ro  Thu Apr 12 11:17:03 2012
From: thciobanu at nth.ro (Theodor-Iulian Ciobanu)
Date: Thu Apr 12 11:17:12 2012
Subject: Panic in packet filter
In-Reply-To: <D25EB30E-9241-4B81-A312-E37861DA5017@apple-park.kiev.ua>
References: <CAOxY2CotiKHHcw+jv2pAi6CbZ7oM3V7ohMrwHY0XhrwTAaRz1w@mail.gmail.com>
	<CAPBZQG16nbu09Bj8rKYUQbuRvCFikvF28REcM41t2urVzn7c1w@mail.gmail.com>
	<CAOxY2Cph2rt-1wnoQRBdsr+mLCHyBaMAYW2o8Z08W+3Dz-_7iw@mail.gmail.com>
	<D25EB30E-9241-4B81-A312-E37861DA5017@apple-park.kiev.ua>
Message-ID: <20120412141632.00007c72@unknown>

Hello,

I came across this same issue yesterday on a system I have just set up.
I'm currently using the default kernel:

FreeBSD changeme 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30
UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64

with pf obviously loaded as a module. Even with kern.smp.disabled=1 pf
will crash as soon as it matches a rule that contains tables with
counters (I added such a table with just three addresses).

I'll have this machine around for testing for about a week or so and am
willing to try out any available patches to help fix the issue.

On Fri Feb 24 14:47:53 2012
iskander at apple-park.kiev.ua (Alexander Vyrlanovich) wrote:

> 
> On 24 Feb 2012, at 11:10, Ali Mdidech wrote:
> 
> > Hi Ermal,
> >
> > 2012/2/24 Ermal Lu?i <eri@freebsd.org>:
> >> On Thu, Feb 23, 2012 at 8:44 AM, Ali Mdidech <ali@moua7.com> wrote:
> >>> Hi List,
> >>>
> >>> I've a box that panics multiple times randomly since a year
> >>> whatever the release is (8 or 9)
> >>> The crash dump shows that the problem is related to pf.
> >>> Is this some sort of identified bug?
> >>> Below some info and my pf.conf file.
> >>>
> >>> Thank you very much for your help.
> >>>
> >>
> >> Can you try do disable SMP through sysctl and see if you still
> >> get this?
> >> What are you doing to get the panic?
> >
> > Well, I'm able now to avoid or reproduce the panic.
> > Disabling counters in <ssh_brute> table makes the server stable
> > enough and no panic for 48 hours.
> > Restoring the counters and adding a host in the table by hand (pfctl
> > -t ssh_brute -T add someip) provokes the panic within few seconds.
> > I've disabled smp (adding kern.smp.disabled=1 in loader.conf and
> > rebooting) => kernel still panics.
> >
> > FreeBSD somehost 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Sat Jan 21
> > 09:31:30 CET 2012     root@somehost:/usr/obj/usr/src/sys/DDX3KRNL
> > i386
> I can confirm that problem with counters in pf tables persist
> at last on i386 and amd64. My systems is:
> 
> FreeBSD gw 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Jan  3 15:55:41
> EET 2012
> root@gw:/usr/obj/usr/src/sys/GW3  amd64
> 
> FreeBSD gw2 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Wed Jan 25 13:52:48  
> EET 2012
> root@gw2:/usr/obj/usr/src/sys/GWS90  i386
> 
> pf + altq compiled in kernel
> 
> Same result: kernel panic. Without counters systems is rock solid.
> 
> >> Also its very helpful to know the `uname -a` command output.
> >>
> >>> panic: page fault
> >>>
> >>> GNU gdb 6.1.1 [FreeBSD]
> >>> Copyright 2004 Free Software Foundation, Inc.
> >>> GDB is free software, covered by the GNU General Public License,  
> >>> and you are
> >>> welcome to change it and/or distribute copies of it under
> >>> certain conditions.
> >>> Type "show copying" to see the conditions.
> >>> There is absolutely no warranty for GDB.  Type "show warranty"
> >>> for details.
> >>> This GDB was configured as "i386-marcel-freebsd"...
> >>>
> >>> Unread portion of the kernel message buffer:
> >>>
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 0; apic id = 00
> >>> fault virtual address   = 0x6c
> >>> fault code              = supervisor read, page not present
> >>> instruction pointer     = 0x20:0xc0a25dc0
> >>> stack pointer           = 0x28:0xc4df5910
> >>> frame pointer           = 0x28:0xc4df5954
> >>> code segment            = base 0x0, limit 0xfffff, type 0x1b
> >>>                        = DPL 0, pres 1, def32 1, gran 1
> >>> processor eflags        = interrupt enabled, resume, IOPL = 0
> >>> current process         = 12 (irq256: em0:rx 0)
> >>> trap number             = 12
> >>> panic: page fault
> >>> cpuid = 0
> >>> KDB: stack backtrace:
> >>> #0 0xc08380b7 at kdb_backtrace+0x47
> >>> #1 0xc0805617 at panic+0x117
> >>> #2 0xc0aebcc3 at trap_fatal+0x323
> >>> #3 0xc0aec802 at trap+0x182
> >>> #4 0xc0ad5f8c at calltrap+0x6
> >>> #5 0xc589f7cc at pfr_update_stats+0x1cc
> >>> #6 0xc588de21 at pf_test+0x981
> >>> #7 0xc5895e79 at pf_check_in+0x39
> >>> #8 0xc08c3c68 at pfil_run_hooks+0x78
> >>> #9 0xc08e18ae at ip_input+0x24e
> >>> #10 0xc08c2d9f at netisr_dispatch_src+0x8f
> >>> #11 0xc08c3040 at netisr_dispatch+0x20
> >>> #12 0xc08b9721 at ether_demux+0x171
> >>> #13 0xc08b9b6f at ether_nh_input+0x37f
> >>> #14 0xc08c2d9f at netisr_dispatch_src+0x8f
> >>> #15 0xc08c3040 at netisr_dispatch+0x20
> >>> #16 0xc08b9269 at ether_input+0x19
> >>> #17 0xc05b383f at em_rxeof+0x30f
> >>> Uptime: 1h45m44s
> >>> Physical memory: 2002 MB
> >>> Dumping 185 MB: 170 154 138 122 106 90 74 58 42 26 10
> >>>
> >>> Reading symbols from /boot/kernel/pf.ko...Reading symbols from
> >>> /boot/kernel/pf.ko.symbols...
> >>> done.
> >>> done.
> >>> Loaded symbols for /boot/kernel/pf.ko
> >>> #0  doadump (textdump=1) at pcpu.h:244
> >>> 244     pcpu.h: No such file or directory.
> >>>        in pcpu.h
> >>> (kgdb) #0  doadump (textdump=1) at pcpu.h:244
> >>> #1  0xc08053ba in kern_reboot (howto=260)
> >>>    at /usr/src/sys/kern/kern_shutdown.c:442
> >>> #2  0xc0805651 in panic (fmt=Variable "fmt" is not available.
> >>> ) at /usr/src/sys/kern/kern_shutdown.c:607
> >>> #3  0xc0aebcc3 in trap_fatal (frame=0xc4df58d0, eva=108)
> >>>    at /usr/src/sys/i386/i386/trap.c:975
> >>> #4  0xc0aec802 in trap (frame=0xc4df58d0) at /usr/src/sys/i386/ 
> >>> i386/trap.c:352
> >>> #5  0xc0ad5f8c in calltrap () at /usr/src/sys/i386/i386/ 
> >>> exception.s:168
> >>> #6  0xc0a25dc0 in uma_zalloc_arg (zone=0x0, udata=0x0, flags=257)
> >>>    at pcpu.h:244
> >>> #7  0xc589f7cc in pfr_update_stats (kt=0xc58d44d8, a=0xc56aa01a,  
> >>> af=2 '\002',
> >>>    len=52, dir_out=0, op_pass=0, notrule=0) at uma.h:305
> >>> #8  0xc588de21 in pf_test (dir=1, ifp=0xc5253c00, m0=0xc4df5acc,  
> >>> eh=0x0,
> >>>    inp=0x0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c: 
> >>> 7057
> >>> #9  0xc5895e79 in pf_check_in (arg=0x0, m=0xc4df5acc,  
> >>> ifp=0xc5253c00, dir=1,
> >>>    inp=0x0) at /usr/src/sys/modules/pf/../../contrib/pf/net/ 
> >>> pf_ioctl.c:4139
> >>> #10 0xc08c3c68 in pfil_run_hooks (ph=0xc0d685e0, mp=0xc4df5b24,
> >>>    ifp=0xc5253c00, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:82
> >>> #11 0xc08e18ae in ip_input (m=0xc567db00)
> >>>    at /usr/src/sys/netinet/ip_input.c:510
> >>> #12 0xc08c2d9f in netisr_dispatch_src (proto=1, source=0,  
> >>> m=0xc567db00)
> >>>    at /usr/src/sys/net/netisr.c:1013
> >>> #13 0xc08c3040 in netisr_dispatch (proto=1, m=0xc567db00)
> >>>    at /usr/src/sys/net/netisr.c:1104
> >>> #14 0xc08b9721 in ether_demux (ifp=0xc5253c00, m=0xc567db00)
> >>>    at /usr/src/sys/net/if_ethersubr.c:937
> >>> #15 0xc08b9b6f in ether_nh_input (m=0xc567db00)
> >>>    at /usr/src/sys/net/if_ethersubr.c:756
> >>> #16 0xc08c2d9f in netisr_dispatch_src (proto=9, source=0,  
> >>> m=0xc567db00)
> >>>    at /usr/src/sys/net/netisr.c:1013
> >>> #17 0xc08c3040 in netisr_dispatch (proto=9, m=0xc567db00)
> >>>    at /usr/src/sys/net/netisr.c:1104
> >>> #18 0xc08b9269 in ether_input (ifp=0xc5253c00, m=0xc567db00)
> >>>    at /usr/src/sys/net/if_ethersubr.c:797
> >>> #19 0xc05b383f in em_rxeof (rxr=0xc520bc00, count=99, done=0x0)
> >>>    at /usr/src/sys/dev/e1000/if_em.c:4340
> >>> #20 0xc05b3a06 in em_msix_rx (arg=0xc520bc00)
> >>>    at /usr/src/sys/dev/e1000/if_em.c:1577
> >>> #21 0xc07da6eb in intr_event_execute_handlers (p=0xc5157588,  
> >>> ie=0xc5241680)
> >>>    at /usr/src/sys/kern/kern_intr.c:1257
> >>> #22 0xc07dbeaa in ithread_loop (arg=0xc52506e0)
> >>>    at /usr/src/sys/kern/kern_intr.c:1270
> >>> #23 0xc07d78f7 in fork_exit (callout=0xc07dbe30 <ithread_loop>,
> >>>    arg=0xc52506e0, frame=0xc4df5d28) at /usr/src/sys/kern/ 
> >>> kern_fork.c:995
> >>> #24 0xc0ad6004 in fork_trampoline () at /usr/src/sys/i386/i386/ 
> >>> exception.s:275
> >>> (kgdb)
> >>>
> >>>
> >>> ################## pf.conf ##################
> >>> ext_if = "em0"
> >>>
> >>> public_tcp_ports = "{21,25,53,80,143,443,873,993,50021:50121}"
> >>> public_udp_ports = "53"
> >>>
> >>> table <secure> {someip}
> >>> table <ssh_brute> persist counters
> >>>
> >>> ### Redirection for SMTP
> >>> rdr on $ext_if proto tcp from any to $ext_if port 225 -> $ext_if  
> >>> port 25
> >>>
> >>> ### Block everything in an pass everything out
> >>> pass out on $ext_if all modulate state
> >>> block in on $ext_if all
> >>>
> >>> ### secure users
> >>> pass in quick on $ext_if proto tcp from <secure> to any flags
> >>> S/SA \ modulate state
> >>>
> >>> ### public tcp/udp ports rules
> >>> pass in on $ext_if proto udp to $ext_if port $public_udp_ports
> >>> pass in on $ext_if proto tcp to $ext_if port $public_tcp_ports  
> >>> flags S/SA \
> >>> modulate state
> >>>
> >>> ### block ssh bruteforce
> >>> block in quick from <ssh_brute>
> >>> pass in quick on $ext_if proto tcp to $ext_if port 22 flags S/SA
> >>> modulate state \
> >>> (max-src-conn 5, max-src-conn-rate 10/60, overload <ssh_brute>  
> >>> flush global)
> >>>
> >>> ### block icmp timestamp request/response
> >>> block in quick on $ext_if inet proto icmp all icmp-type {13, 14}
> >>> pass in quick on $ext_if proto icmp all
> >>>
> >>> ############ end pf.conf ##############
> >>>
> >>> --
> >>> Ali Mdidech
> >>> _______________________________________________
> >>> 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"
> >>
> >>
> >>
> >> --
> >> Ermal
> >
> > -- 
> > Ali Mdidech
> > _______________________________________________
> > 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"
> 
> ????????? ??????????
> --------------------------
> ????????? ?????????????
> ??? "???"

-- 
Theo
From eri at freebsd.org  Thu Apr 12 13:01:48 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Thu Apr 12 13:01:54 2012
Subject: Panic in packet filter
In-Reply-To: <20120412141632.00007c72@unknown>
References: <CAOxY2CotiKHHcw+jv2pAi6CbZ7oM3V7ohMrwHY0XhrwTAaRz1w@mail.gmail.com>
	<CAPBZQG16nbu09Bj8rKYUQbuRvCFikvF28REcM41t2urVzn7c1w@mail.gmail.com>
	<CAOxY2Cph2rt-1wnoQRBdsr+mLCHyBaMAYW2o8Z08W+3Dz-_7iw@mail.gmail.com>
	<D25EB30E-9241-4B81-A312-E37861DA5017@apple-park.kiev.ua>
	<20120412141632.00007c72@unknown>
Message-ID: <CAPBZQG352UtXQ+4STkHNwF0f3e4z_2q=0zoRSBDCTZFMAJRAQg@mail.gmail.com>

Hello,

On Thu, Apr 12, 2012 at 1:16 PM, Theodor-Iulian Ciobanu
<thciobanu@nth.ro> wrote:
> Hello,
>
> I came across this same issue yesterday on a system I have just set up.
> I'm currently using the default kernel:
>
> FreeBSD changeme 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan ?3 07:46:30
> UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
> amd64
>
> with pf obviously loaded as a module. Even with kern.smp.disabled=1 pf
> will crash as soon as it matches a rule that contains tables with
> counters (I added such a table with just three addresses).
>
> I'll have this machine around for testing for about a week or so and am
> willing to try out any available patches to help fix the issue.
>

Try this patch http://people.freebsd.org/~eri/pf_table_counter_fix.diff.
It should fix the issue for you.

Seems there is a forgotten pool initialization for this, my fault!

Though looking at it the whole thing seems a microoptimization that is
still present on latest OpenBSD code,
that saves about 16bytes!

Anyway see if it fixes the issue to get this committed.

> On Fri Feb 24 14:47:53 2012
> iskander at apple-park.kiev.ua (Alexander Vyrlanovich) wrote:
>
>>
>> On 24 Feb 2012, at 11:10, Ali Mdidech wrote:
>>
>> > Hi Ermal,
>> >
>> > 2012/2/24 Ermal Lu?i <eri@freebsd.org>:
>> >> On Thu, Feb 23, 2012 at 8:44 AM, Ali Mdidech <ali@moua7.com> wrote:
>> >>> Hi List,
>> >>>
>> >>> I've a box that panics multiple times randomly since a year
>> >>> whatever the release is (8 or 9)
>> >>> The crash dump shows that the problem is related to pf.
>> >>> Is this some sort of identified bug?
>> >>> Below some info and my pf.conf file.
>> >>>
>> >>> Thank you very much for your help.
>> >>>
>> >>
>> >> Can you try do disable SMP through sysctl and see if you still
>> >> get this?
>> >> What are you doing to get the panic?
>> >
>> > Well, I'm able now to avoid or reproduce the panic.
>> > Disabling counters in <ssh_brute> table makes the server stable
>> > enough and no panic for 48 hours.
>> > Restoring the counters and adding a host in the table by hand (pfctl
>> > -t ssh_brute -T add someip) provokes the panic within few seconds.
>> > I've disabled smp (adding kern.smp.disabled=1 in loader.conf and
>> > rebooting) => kernel still panics.
>> >
>> > FreeBSD somehost 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Sat Jan 21
>> > 09:31:30 CET 2012 ? ? root@somehost:/usr/obj/usr/src/sys/DDX3KRNL
>> > i386
>> I can confirm that problem with counters in pf tables persist
>> at last on i386 and amd64. My systems is:
>>
>> FreeBSD gw 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Jan ?3 15:55:41
>> EET 2012
>> root@gw:/usr/obj/usr/src/sys/GW3 ?amd64
>>
>> FreeBSD gw2 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Wed Jan 25 13:52:48
>> EET 2012
>> root@gw2:/usr/obj/usr/src/sys/GWS90 ?i386
>>
>> pf + altq compiled in kernel
>>
>> Same result: kernel panic. Without counters systems is rock solid.
>>
>> >> Also its very helpful to know the `uname -a` command output.
>> >>
>> >>> panic: page fault
>> >>>
>> >>> GNU gdb 6.1.1 [FreeBSD]
>> >>> Copyright 2004 Free Software Foundation, Inc.
>> >>> GDB is free software, covered by the GNU General Public License,
>> >>> and you are
>> >>> welcome to change it and/or distribute copies of it under
>> >>> certain conditions.
>> >>> Type "show copying" to see the conditions.
>> >>> There is absolutely no warranty for GDB. ?Type "show warranty"
>> >>> for details.
>> >>> This GDB was configured as "i386-marcel-freebsd"...
>> >>>
>> >>> Unread portion of the kernel message buffer:
>> >>>
>> >>>
>> >>> Fatal trap 12: page fault while in kernel mode
>> >>> cpuid = 0; apic id = 00
>> >>> fault virtual address ? = 0x6c
>> >>> fault code ? ? ? ? ? ? ?= supervisor read, page not present
>> >>> instruction pointer ? ? = 0x20:0xc0a25dc0
>> >>> stack pointer ? ? ? ? ? = 0x28:0xc4df5910
>> >>> frame pointer ? ? ? ? ? = 0x28:0xc4df5954
>> >>> code segment ? ? ? ? ? ?= base 0x0, limit 0xfffff, type 0x1b
>> >>> ? ? ? ? ? ? ? ? ? ? ? ?= DPL 0, pres 1, def32 1, gran 1
>> >>> processor eflags ? ? ? ?= interrupt enabled, resume, IOPL = 0
>> >>> current process ? ? ? ? = 12 (irq256: em0:rx 0)
>> >>> trap number ? ? ? ? ? ? = 12
>> >>> panic: page fault
>> >>> cpuid = 0
>> >>> KDB: stack backtrace:
>> >>> #0 0xc08380b7 at kdb_backtrace+0x47
>> >>> #1 0xc0805617 at panic+0x117
>> >>> #2 0xc0aebcc3 at trap_fatal+0x323
>> >>> #3 0xc0aec802 at trap+0x182
>> >>> #4 0xc0ad5f8c at calltrap+0x6
>> >>> #5 0xc589f7cc at pfr_update_stats+0x1cc
>> >>> #6 0xc588de21 at pf_test+0x981
>> >>> #7 0xc5895e79 at pf_check_in+0x39
>> >>> #8 0xc08c3c68 at pfil_run_hooks+0x78
>> >>> #9 0xc08e18ae at ip_input+0x24e
>> >>> #10 0xc08c2d9f at netisr_dispatch_src+0x8f
>> >>> #11 0xc08c3040 at netisr_dispatch+0x20
>> >>> #12 0xc08b9721 at ether_demux+0x171
>> >>> #13 0xc08b9b6f at ether_nh_input+0x37f
>> >>> #14 0xc08c2d9f at netisr_dispatch_src+0x8f
>> >>> #15 0xc08c3040 at netisr_dispatch+0x20
>> >>> #16 0xc08b9269 at ether_input+0x19
>> >>> #17 0xc05b383f at em_rxeof+0x30f
>> >>> Uptime: 1h45m44s
>> >>> Physical memory: 2002 MB
>> >>> Dumping 185 MB: 170 154 138 122 106 90 74 58 42 26 10
>> >>>
>> >>> Reading symbols from /boot/kernel/pf.ko...Reading symbols from
>> >>> /boot/kernel/pf.ko.symbols...
>> >>> done.
>> >>> done.
>> >>> Loaded symbols for /boot/kernel/pf.ko
>> >>> #0 ?doadump (textdump=1) at pcpu.h:244
>> >>> 244 ? ? pcpu.h: No such file or directory.
>> >>> ? ? ? ?in pcpu.h
>> >>> (kgdb) #0 ?doadump (textdump=1) at pcpu.h:244
>> >>> #1 ?0xc08053ba in kern_reboot (howto=260)
>> >>> ? ?at /usr/src/sys/kern/kern_shutdown.c:442
>> >>> #2 ?0xc0805651 in panic (fmt=Variable "fmt" is not available.
>> >>> ) at /usr/src/sys/kern/kern_shutdown.c:607
>> >>> #3 ?0xc0aebcc3 in trap_fatal (frame=0xc4df58d0, eva=108)
>> >>> ? ?at /usr/src/sys/i386/i386/trap.c:975
>> >>> #4 ?0xc0aec802 in trap (frame=0xc4df58d0) at /usr/src/sys/i386/
>> >>> i386/trap.c:352
>> >>> #5 ?0xc0ad5f8c in calltrap () at /usr/src/sys/i386/i386/
>> >>> exception.s:168
>> >>> #6 ?0xc0a25dc0 in uma_zalloc_arg (zone=0x0, udata=0x0, flags=257)
>> >>> ? ?at pcpu.h:244
>> >>> #7 ?0xc589f7cc in pfr_update_stats (kt=0xc58d44d8, a=0xc56aa01a,
>> >>> af=2 '\002',
>> >>> ? ?len=52, dir_out=0, op_pass=0, notrule=0) at uma.h:305
>> >>> #8 ?0xc588de21 in pf_test (dir=1, ifp=0xc5253c00, m0=0xc4df5acc,
>> >>> eh=0x0,
>> >>> ? ?inp=0x0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:
>> >>> 7057
>> >>> #9 ?0xc5895e79 in pf_check_in (arg=0x0, m=0xc4df5acc,
>> >>> ifp=0xc5253c00, dir=1,
>> >>> ? ?inp=0x0) at /usr/src/sys/modules/pf/../../contrib/pf/net/
>> >>> pf_ioctl.c:4139
>> >>> #10 0xc08c3c68 in pfil_run_hooks (ph=0xc0d685e0, mp=0xc4df5b24,
>> >>> ? ?ifp=0xc5253c00, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:82
>> >>> #11 0xc08e18ae in ip_input (m=0xc567db00)
>> >>> ? ?at /usr/src/sys/netinet/ip_input.c:510
>> >>> #12 0xc08c2d9f in netisr_dispatch_src (proto=1, source=0,
>> >>> m=0xc567db00)
>> >>> ? ?at /usr/src/sys/net/netisr.c:1013
>> >>> #13 0xc08c3040 in netisr_dispatch (proto=1, m=0xc567db00)
>> >>> ? ?at /usr/src/sys/net/netisr.c:1104
>> >>> #14 0xc08b9721 in ether_demux (ifp=0xc5253c00, m=0xc567db00)
>> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:937
>> >>> #15 0xc08b9b6f in ether_nh_input (m=0xc567db00)
>> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:756
>> >>> #16 0xc08c2d9f in netisr_dispatch_src (proto=9, source=0,
>> >>> m=0xc567db00)
>> >>> ? ?at /usr/src/sys/net/netisr.c:1013
>> >>> #17 0xc08c3040 in netisr_dispatch (proto=9, m=0xc567db00)
>> >>> ? ?at /usr/src/sys/net/netisr.c:1104
>> >>> #18 0xc08b9269 in ether_input (ifp=0xc5253c00, m=0xc567db00)
>> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:797
>> >>> #19 0xc05b383f in em_rxeof (rxr=0xc520bc00, count=99, done=0x0)
>> >>> ? ?at /usr/src/sys/dev/e1000/if_em.c:4340
>> >>> #20 0xc05b3a06 in em_msix_rx (arg=0xc520bc00)
>> >>> ? ?at /usr/src/sys/dev/e1000/if_em.c:1577
>> >>> #21 0xc07da6eb in intr_event_execute_handlers (p=0xc5157588,
>> >>> ie=0xc5241680)
>> >>> ? ?at /usr/src/sys/kern/kern_intr.c:1257
>> >>> #22 0xc07dbeaa in ithread_loop (arg=0xc52506e0)
>> >>> ? ?at /usr/src/sys/kern/kern_intr.c:1270
>> >>> #23 0xc07d78f7 in fork_exit (callout=0xc07dbe30 <ithread_loop>,
>> >>> ? ?arg=0xc52506e0, frame=0xc4df5d28) at /usr/src/sys/kern/
>> >>> kern_fork.c:995
>> >>> #24 0xc0ad6004 in fork_trampoline () at /usr/src/sys/i386/i386/
>> >>> exception.s:275
>> >>> (kgdb)
>> >>>
>> >>>
>> >>> ################## pf.conf ##################
>> >>> ext_if = "em0"
>> >>>
>> >>> public_tcp_ports = "{21,25,53,80,143,443,873,993,50021:50121}"
>> >>> public_udp_ports = "53"
>> >>>
>> >>> table <secure> {someip}
>> >>> table <ssh_brute> persist counters
>> >>>
>> >>> ### Redirection for SMTP
>> >>> rdr on $ext_if proto tcp from any to $ext_if port 225 -> $ext_if
>> >>> port 25
>> >>>
>> >>> ### Block everything in an pass everything out
>> >>> pass out on $ext_if all modulate state
>> >>> block in on $ext_if all
>> >>>
>> >>> ### secure users
>> >>> pass in quick on $ext_if proto tcp from <secure> to any flags
>> >>> S/SA \ modulate state
>> >>>
>> >>> ### public tcp/udp ports rules
>> >>> pass in on $ext_if proto udp to $ext_if port $public_udp_ports
>> >>> pass in on $ext_if proto tcp to $ext_if port $public_tcp_ports
>> >>> flags S/SA \
>> >>> modulate state
>> >>>
>> >>> ### block ssh bruteforce
>> >>> block in quick from <ssh_brute>
>> >>> pass in quick on $ext_if proto tcp to $ext_if port 22 flags S/SA
>> >>> modulate state \
>> >>> (max-src-conn 5, max-src-conn-rate 10/60, overload <ssh_brute>
>> >>> flush global)
>> >>>
>> >>> ### block icmp timestamp request/response
>> >>> block in quick on $ext_if inet proto icmp all icmp-type {13, 14}
>> >>> pass in quick on $ext_if proto icmp all
>> >>>
>> >>> ############ end pf.conf ##############
>> >>>
>> >>> --
>> >>> Ali Mdidech
>> >>> _______________________________________________
>> >>> 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"
>> >>
>> >>
>> >>
>> >> --
>> >> Ermal
>> >
>> > --
>> > Ali Mdidech
>> > _______________________________________________
>> > 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"
>>
>> ????????? ??????????
>> --------------------------
>> ????????? ?????????????
>> ??? "???"
>
> --
> Theo
> _______________________________________________
> 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"



-- 
Ermal
From thciobanu at nth.ro  Thu Apr 12 22:29:40 2012
From: thciobanu at nth.ro (Theodor-Iulian Ciobanu)
Date: Thu Apr 12 22:29:48 2012
Subject: Panic in packet filter
In-Reply-To: <CAPBZQG352UtXQ+4STkHNwF0f3e4z_2q=0zoRSBDCTZFMAJRAQg@mail.gmail.com>
References: <CAOxY2CotiKHHcw+jv2pAi6CbZ7oM3V7ohMrwHY0XhrwTAaRz1w@mail.gmail.com>
	<CAPBZQG16nbu09Bj8rKYUQbuRvCFikvF28REcM41t2urVzn7c1w@mail.gmail.com>
	<CAOxY2Cph2rt-1wnoQRBdsr+mLCHyBaMAYW2o8Z08W+3Dz-_7iw@mail.gmail.com>
	<D25EB30E-9241-4B81-A312-E37861DA5017@apple-park.kiev.ua>
	<20120412141632.00007c72@unknown>
	<CAPBZQG352UtXQ+4STkHNwF0f3e4z_2q=0zoRSBDCTZFMAJRAQg@mail.gmail.com>
Message-ID: <20120413012931.00006832@unknown>

On Thu, 12 Apr 2012 15:01:46 +0200
Ermal Lu?i <eri@freebsd.org> wrote:

> Hello,
> 
> On Thu, Apr 12, 2012 at 1:16 PM, Theodor-Iulian Ciobanu
> <thciobanu@nth.ro> wrote:
> > Hello,
> >
> > I came across this same issue yesterday on a system I have just set
> > up. I'm currently using the default kernel:
> >
> > FreeBSD changeme 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan ?3
> > 07:46:30 UTC 2012
> > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
> >
> > with pf obviously loaded as a module. Even with kern.smp.disabled=1
> > pf will crash as soon as it matches a rule that contains tables with
> > counters (I added such a table with just three addresses).
> >
> > I'll have this machine around for testing for about a week or so
> > and am willing to try out any available patches to help fix the
> > issue.
> >
> 
> Try this patch
> http://people.freebsd.org/~eri/pf_table_counter_fix.diff. It should
> fix the issue for you.
> 
> Seems there is a forgotten pool initialization for this, my fault!
> 
> Though looking at it the whole thing seems a microoptimization that is
> still present on latest OpenBSD code,
> that saves about 16bytes!
> 
> Anyway see if it fixes the issue to get this committed.

Great use of 16b, as it doesn't seem to crash anymore, at least in a
simple synthetic test (uploading C:\Windows from 2 systems at once
through ftp, 10 transfer connections each).

Thank you!

> > On Fri Feb 24 14:47:53 2012
> > iskander at apple-park.kiev.ua (Alexander Vyrlanovich) wrote:
> >
> >>
> >> On 24 Feb 2012, at 11:10, Ali Mdidech wrote:
> >>
> >> > Hi Ermal,
> >> >
> >> > 2012/2/24 Ermal Lu?i <eri@freebsd.org>:
> >> >> On Thu, Feb 23, 2012 at 8:44 AM, Ali Mdidech <ali@moua7.com>
> >> >> wrote:
> >> >>> Hi List,
> >> >>>
> >> >>> I've a box that panics multiple times randomly since a year
> >> >>> whatever the release is (8 or 9)
> >> >>> The crash dump shows that the problem is related to pf.
> >> >>> Is this some sort of identified bug?
> >> >>> Below some info and my pf.conf file.
> >> >>>
> >> >>> Thank you very much for your help.
> >> >>>
> >> >>
> >> >> Can you try do disable SMP through sysctl and see if you still
> >> >> get this?
> >> >> What are you doing to get the panic?
> >> >
> >> > Well, I'm able now to avoid or reproduce the panic.
> >> > Disabling counters in <ssh_brute> table makes the server stable
> >> > enough and no panic for 48 hours.
> >> > Restoring the counters and adding a host in the table by hand
> >> > (pfctl -t ssh_brute -T add someip) provokes the panic within few
> >> > seconds. I've disabled smp (adding kern.smp.disabled=1 in
> >> > loader.conf and rebooting) => kernel still panics.
> >> >
> >> > FreeBSD somehost 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Sat Jan 21
> >> > 09:31:30 CET 2012 ? ? root@somehost:/usr/obj/usr/src/sys/DDX3KRNL
> >> > i386
> >> I can confirm that problem with counters in pf tables persist
> >> at last on i386 and amd64. My systems is:
> >>
> >> FreeBSD gw 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Jan ?3 15:55:41
> >> EET 2012
> >> root@gw:/usr/obj/usr/src/sys/GW3 ?amd64
> >>
> >> FreeBSD gw2 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Wed Jan 25 13:52:48
> >> EET 2012
> >> root@gw2:/usr/obj/usr/src/sys/GWS90 ?i386
> >>
> >> pf + altq compiled in kernel
> >>
> >> Same result: kernel panic. Without counters systems is rock solid.
> >>
> >> >> Also its very helpful to know the `uname -a` command output.
> >> >>
> >> >>> panic: page fault
> >> >>>
> >> >>> GNU gdb 6.1.1 [FreeBSD]
> >> >>> Copyright 2004 Free Software Foundation, Inc.
> >> >>> GDB is free software, covered by the GNU General Public
> >> >>> License, and you are
> >> >>> welcome to change it and/or distribute copies of it under
> >> >>> certain conditions.
> >> >>> Type "show copying" to see the conditions.
> >> >>> There is absolutely no warranty for GDB. ?Type "show warranty"
> >> >>> for details.
> >> >>> This GDB was configured as "i386-marcel-freebsd"...
> >> >>>
> >> >>> Unread portion of the kernel message buffer:
> >> >>>
> >> >>>
> >> >>> Fatal trap 12: page fault while in kernel mode
> >> >>> cpuid = 0; apic id = 00
> >> >>> fault virtual address ? = 0x6c
> >> >>> fault code ? ? ? ? ? ? ?= supervisor read, page not present
> >> >>> instruction pointer ? ? = 0x20:0xc0a25dc0
> >> >>> stack pointer ? ? ? ? ? = 0x28:0xc4df5910
> >> >>> frame pointer ? ? ? ? ? = 0x28:0xc4df5954
> >> >>> code segment ? ? ? ? ? ?= base 0x0, limit 0xfffff, type 0x1b
> >> >>> ? ? ? ? ? ? ? ? ? ? ? ?= DPL 0, pres 1, def32 1, gran 1
> >> >>> processor eflags ? ? ? ?= interrupt enabled, resume, IOPL = 0
> >> >>> current process ? ? ? ? = 12 (irq256: em0:rx 0)
> >> >>> trap number ? ? ? ? ? ? = 12
> >> >>> panic: page fault
> >> >>> cpuid = 0
> >> >>> KDB: stack backtrace:
> >> >>> #0 0xc08380b7 at kdb_backtrace+0x47
> >> >>> #1 0xc0805617 at panic+0x117
> >> >>> #2 0xc0aebcc3 at trap_fatal+0x323
> >> >>> #3 0xc0aec802 at trap+0x182
> >> >>> #4 0xc0ad5f8c at calltrap+0x6
> >> >>> #5 0xc589f7cc at pfr_update_stats+0x1cc
> >> >>> #6 0xc588de21 at pf_test+0x981
> >> >>> #7 0xc5895e79 at pf_check_in+0x39
> >> >>> #8 0xc08c3c68 at pfil_run_hooks+0x78
> >> >>> #9 0xc08e18ae at ip_input+0x24e
> >> >>> #10 0xc08c2d9f at netisr_dispatch_src+0x8f
> >> >>> #11 0xc08c3040 at netisr_dispatch+0x20
> >> >>> #12 0xc08b9721 at ether_demux+0x171
> >> >>> #13 0xc08b9b6f at ether_nh_input+0x37f
> >> >>> #14 0xc08c2d9f at netisr_dispatch_src+0x8f
> >> >>> #15 0xc08c3040 at netisr_dispatch+0x20
> >> >>> #16 0xc08b9269 at ether_input+0x19
> >> >>> #17 0xc05b383f at em_rxeof+0x30f
> >> >>> Uptime: 1h45m44s
> >> >>> Physical memory: 2002 MB
> >> >>> Dumping 185 MB: 170 154 138 122 106 90 74 58 42 26 10
> >> >>>
> >> >>> Reading symbols from /boot/kernel/pf.ko...Reading symbols from
> >> >>> /boot/kernel/pf.ko.symbols...
> >> >>> done.
> >> >>> done.
> >> >>> Loaded symbols for /boot/kernel/pf.ko
> >> >>> #0 ?doadump (textdump=1) at pcpu.h:244
> >> >>> 244 ? ? pcpu.h: No such file or directory.
> >> >>> ? ? ? ?in pcpu.h
> >> >>> (kgdb) #0 ?doadump (textdump=1) at pcpu.h:244
> >> >>> #1 ?0xc08053ba in kern_reboot (howto=260)
> >> >>> ? ?at /usr/src/sys/kern/kern_shutdown.c:442
> >> >>> #2 ?0xc0805651 in panic (fmt=Variable "fmt" is not available.
> >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:607
> >> >>> #3 ?0xc0aebcc3 in trap_fatal (frame=0xc4df58d0, eva=108)
> >> >>> ? ?at /usr/src/sys/i386/i386/trap.c:975
> >> >>> #4 ?0xc0aec802 in trap (frame=0xc4df58d0) at /usr/src/sys/i386/
> >> >>> i386/trap.c:352
> >> >>> #5 ?0xc0ad5f8c in calltrap () at /usr/src/sys/i386/i386/
> >> >>> exception.s:168
> >> >>> #6 ?0xc0a25dc0 in uma_zalloc_arg (zone=0x0, udata=0x0,
> >> >>> flags=257) at pcpu.h:244
> >> >>> #7 ?0xc589f7cc in pfr_update_stats (kt=0xc58d44d8,
> >> >>> a=0xc56aa01a, af=2 '\002',
> >> >>> ? ?len=52, dir_out=0, op_pass=0, notrule=0) at uma.h:305
> >> >>> #8 ?0xc588de21 in pf_test (dir=1, ifp=0xc5253c00,
> >> >>> m0=0xc4df5acc, eh=0x0,
> >> >>> ? ?inp=0x0)
> >> >>> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c: 7057
> >> >>> #9 ?0xc5895e79 in pf_check_in (arg=0x0, m=0xc4df5acc,
> >> >>> ifp=0xc5253c00, dir=1,
> >> >>> ? ?inp=0x0) at /usr/src/sys/modules/pf/../../contrib/pf/net/
> >> >>> pf_ioctl.c:4139
> >> >>> #10 0xc08c3c68 in pfil_run_hooks (ph=0xc0d685e0, mp=0xc4df5b24,
> >> >>> ? ?ifp=0xc5253c00, dir=1, inp=0x0)
> >> >>> at /usr/src/sys/net/pfil.c:82 #11 0xc08e18ae in ip_input
> >> >>> (m=0xc567db00) at /usr/src/sys/netinet/ip_input.c:510
> >> >>> #12 0xc08c2d9f in netisr_dispatch_src (proto=1, source=0,
> >> >>> m=0xc567db00)
> >> >>> ? ?at /usr/src/sys/net/netisr.c:1013
> >> >>> #13 0xc08c3040 in netisr_dispatch (proto=1, m=0xc567db00)
> >> >>> ? ?at /usr/src/sys/net/netisr.c:1104
> >> >>> #14 0xc08b9721 in ether_demux (ifp=0xc5253c00, m=0xc567db00)
> >> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:937
> >> >>> #15 0xc08b9b6f in ether_nh_input (m=0xc567db00)
> >> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:756
> >> >>> #16 0xc08c2d9f in netisr_dispatch_src (proto=9, source=0,
> >> >>> m=0xc567db00)
> >> >>> ? ?at /usr/src/sys/net/netisr.c:1013
> >> >>> #17 0xc08c3040 in netisr_dispatch (proto=9, m=0xc567db00)
> >> >>> ? ?at /usr/src/sys/net/netisr.c:1104
> >> >>> #18 0xc08b9269 in ether_input (ifp=0xc5253c00, m=0xc567db00)
> >> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:797
> >> >>> #19 0xc05b383f in em_rxeof (rxr=0xc520bc00, count=99, done=0x0)
> >> >>> ? ?at /usr/src/sys/dev/e1000/if_em.c:4340
> >> >>> #20 0xc05b3a06 in em_msix_rx (arg=0xc520bc00)
> >> >>> ? ?at /usr/src/sys/dev/e1000/if_em.c:1577
> >> >>> #21 0xc07da6eb in intr_event_execute_handlers (p=0xc5157588,
> >> >>> ie=0xc5241680)
> >> >>> ? ?at /usr/src/sys/kern/kern_intr.c:1257
> >> >>> #22 0xc07dbeaa in ithread_loop (arg=0xc52506e0)
> >> >>> ? ?at /usr/src/sys/kern/kern_intr.c:1270
> >> >>> #23 0xc07d78f7 in fork_exit (callout=0xc07dbe30 <ithread_loop>,
> >> >>> ? ?arg=0xc52506e0, frame=0xc4df5d28) at /usr/src/sys/kern/
> >> >>> kern_fork.c:995
> >> >>> #24 0xc0ad6004 in fork_trampoline () at /usr/src/sys/i386/i386/
> >> >>> exception.s:275
> >> >>> (kgdb)
> >> >>>
> >> >>>
> >> >>> ################## pf.conf ##################
> >> >>> ext_if = "em0"
> >> >>>
> >> >>> public_tcp_ports = "{21,25,53,80,143,443,873,993,50021:50121}"
> >> >>> public_udp_ports = "53"
> >> >>>
> >> >>> table <secure> {someip}
> >> >>> table <ssh_brute> persist counters
> >> >>>
> >> >>> ### Redirection for SMTP
> >> >>> rdr on $ext_if proto tcp from any to $ext_if port 225 ->
> >> >>> $ext_if port 25
> >> >>>
> >> >>> ### Block everything in an pass everything out
> >> >>> pass out on $ext_if all modulate state
> >> >>> block in on $ext_if all
> >> >>>
> >> >>> ### secure users
> >> >>> pass in quick on $ext_if proto tcp from <secure> to any flags
> >> >>> S/SA \ modulate state
> >> >>>
> >> >>> ### public tcp/udp ports rules
> >> >>> pass in on $ext_if proto udp to $ext_if port $public_udp_ports
> >> >>> pass in on $ext_if proto tcp to $ext_if port $public_tcp_ports
> >> >>> flags S/SA \
> >> >>> modulate state
> >> >>>
> >> >>> ### block ssh bruteforce
> >> >>> block in quick from <ssh_brute>
> >> >>> pass in quick on $ext_if proto tcp to $ext_if port 22 flags
> >> >>> S/SA modulate state \
> >> >>> (max-src-conn 5, max-src-conn-rate 10/60, overload <ssh_brute>
> >> >>> flush global)
> >> >>>
> >> >>> ### block icmp timestamp request/response
> >> >>> block in quick on $ext_if inet proto icmp all icmp-type {13,
> >> >>> 14} pass in quick on $ext_if proto icmp all
> >> >>>
> >> >>> ############ end pf.conf ##############
> >> >>>
> >> >>> --
> >> >>> Ali Mdidech
> >> >>> _______________________________________________
> >> >>> 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"
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Ermal
> >> >
> >> > --
> >> > Ali Mdidech
> >> > _______________________________________________
> >> > 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"
> >>
> >> ????????? ??????????
> >> --------------------------
> >> ????????? ?????????????
> >> ??? "???"
> >
> > --
> > Theo
> > _______________________________________________
> > 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"

-- 
Theo
From ml at my.gd  Fri Apr 13 01:39:46 2012
From: ml at my.gd (Damien Fleuriot)
Date: Fri Apr 13 01:40:56 2012
Subject: PF - pf not loading non-persist tables from main ruleset on
	8.3-PRERELEASE
In-Reply-To: <CAE63ME7ZywicorwMC-3DTyBmRnO1ZLF2f_vjD_dNDnLM-TAgKQ@mail.gmail.com>
References: <CAE63ME7ZywicorwMC-3DTyBmRnO1ZLF2f_vjD_dNDnLM-TAgKQ@mail.gmail.com>
Message-ID: <CAE63ME7d4jk-GPX2dnCqGvRV-uYm=ur_uci+aQ8UyzXZ7x9ghg@mail.gmail.com>

Sending to -pf since nobody in -stable seemed interested.

Kindly let me know if I can be of assistance to track down the issue.

For the record, a source update against RELENG_8 today (2012/04/12)
did not show any updated file regarding PF, so I guess this still is
an issue.


---------- Forwarded message ----------
From: Damien Fleuriot <ml@my.gd>
Date: 12 April 2012 16:08
Subject: PF - pf not loading non-persist tables from main ruleset on
8.3-PRERELEASE
To: freebsd-stable@freebsd.org


Hello list,



I installed a box recently and updated it to 8.3-PRERELEASE on 2012/04/11


I'm experiencing this extremely weird behavior where PF refuses to
load standard and const table definitions from the main ruleset.
- persist tables load just fine
- normal and const tables inside anchors load just fine



Does anyone else have the same problem ?

I'll try to update the kernel again, you never know.
From jhellenthal at dataix.net  Fri Apr 13 03:04:59 2012
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Fri Apr 13 03:05:06 2012
Subject: PF - pf not loading non-persist tables from main ruleset on
 8.3-PRERELEASE
In-Reply-To: <CAE63ME7d4jk-GPX2dnCqGvRV-uYm=ur_uci+aQ8UyzXZ7x9ghg@mail.gmail.com>
References: <CAE63ME7ZywicorwMC-3DTyBmRnO1ZLF2f_vjD_dNDnLM-TAgKQ@mail.gmail.com>
	<CAE63ME7d4jk-GPX2dnCqGvRV-uYm=ur_uci+aQ8UyzXZ7x9ghg@mail.gmail.com>
Message-ID: <20120413030455.GA40140@DataIX.net>


Did you ever post your ruleset and example tables ? I don't think pf
changed that much between 8.2-RELEASE to 8.3 as it stands now in the
aspects that would effect this outcome.

I am on 8.3-STABLE and the configuration of rules sounds similiar to
yours but I am not exhibiting any problems. Rule order is also key here
so be sure to check that.


On Fri, Apr 13, 2012 at 03:39:44AM +0200, Damien Fleuriot wrote:
> Sending to -pf since nobody in -stable seemed interested.
> 
> Kindly let me know if I can be of assistance to track down the issue.
> 
> For the record, a source update against RELENG_8 today (2012/04/12)
> did not show any updated file regarding PF, so I guess this still is
> an issue.
> 
> 
> ---------- Forwarded message ----------
> From: Damien Fleuriot <ml@my.gd>
> Date: 12 April 2012 16:08
> Subject: PF - pf not loading non-persist tables from main ruleset on
> 8.3-PRERELEASE
> To: freebsd-stable@freebsd.org
> 
> 
> Hello list,
> 
> 
> 
> I installed a box recently and updated it to 8.3-PRERELEASE on 2012/04/11
> 
> 
> I'm experiencing this extremely weird behavior where PF refuses to
> load standard and const table definitions from the main ruleset.
> - persist tables load just fine
> - normal and const tables inside anchors load just fine
> 
> 
> 
> Does anyone else have the same problem ?
> 
> I'll try to update the kernel again, you never know.
> _______________________________________________
> 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"

-- 
;s =;
From ml at my.gd  Fri Apr 13 03:36:41 2012
From: ml at my.gd (Damien Fleuriot)
Date: Fri Apr 13 03:36:48 2012
Subject: PF - pf not loading non-persist tables from main ruleset on
	8.3-PRERELEASE
In-Reply-To: <20120413030455.GA40140@DataIX.net>
References: <CAE63ME7ZywicorwMC-3DTyBmRnO1ZLF2f_vjD_dNDnLM-TAgKQ@mail.gmail.com>
	<CAE63ME7d4jk-GPX2dnCqGvRV-uYm=ur_uci+aQ8UyzXZ7x9ghg@mail.gmail.com>
	<20120413030455.GA40140@DataIX.net>
Message-ID: <CAE63ME7i3fyORKw2A4t6B6G4zL7qmqb1bBWTvCpbV+VJ-bjZTg@mail.gmail.com>

I've actually tried with the following, minimalist ruleset, and gotten
the same outcome.
Notice I included a rule of each type (nat, rdr, pass, block).


vlan31="vlan31"
vlan95="vlan95"
vlan710="vlan710"

table <tab_regular> { 192.168.1.1 }
table <tab_const> const { 192.168.2.2 }
table <tab_persist> persist { 192.168.3.3 }

set optimization aggressive
set loginterface $vlan95
set state-policy if-bound
set block-policy drop
set require-order yes

scrub in all no-df random-id

nat on $vlan31 inet from $vlan710:network to any -> 192.168.31.108
rdr pass on $vlan710 proto tcp from $vlan710 to any port 21 ->
127.0.0.1 port 8021

pass in quick on $vlan710
pass out





# Dummy load of the ruleset:
# pfctl -nvvvvf pf.conf
vlan31 = "vlan31"
vlan95 = "vlan95"
vlan710 = "vlan710"
table <tab_regular> { 192.168.1.1 }
table <tab_const> const { 192.168.2.2 }
table <tab_persist> persist { 192.168.3.3 }
set optimization aggressive
set loginterface vlan95
set state-policy if-bound
set block-policy drop
set require-order yes
@0 scrub in all no-df random-id fragment reassemble
@1 nat on vlan31 inet from 10.107.10.0/23 to any -> 192.168.31.108
@2 rdr pass on vlan710 inet proto tcp from 10.107.10.252 to any port =
ftp -> 127.0.0.1 port 8021
@3 pass in quick on vlan710 all flags S/SA keep state (if-bound)
@4 pass out all flags S/SA keep state (if-bound)



# After actual load:
# pfctl -sa
TRANSLATION RULES:
nat on vlan31 inet from 10.107.10.0/23 to any -> 192.168.31.108
rdr pass on vlan710 inet proto tcp from 10.107.10.252 to any port =
ftp -> 127.0.0.1 port 8021

FILTER RULES:
scrub in all no-df random-id fragment reassemble
pass in quick on vlan710 all flags S/SA keep state (if-bound)
pass out all flags S/SA keep state (if-bound)
No queue in use

INFO:
Status: Enabled for 0 days 00:00:35           Debug: Urgent

[ snip stats, timeouts and limits ]

TABLES:
tab_persist





Notice how again, PF only loads "persist" tables and not "const" and
regular ones.




uname -a, on amd64:
FreeBSD 8.3-PRERELEASE #0: Wed Apr 11 09:46:20 CEST 2012


I'm going to switch from RELENG_8 to RELENG_8_3 , update sources,
rebuild, and see if that helps.




On 13 April 2012 05:04, Jason Hellenthal <jhellenthal@dataix.net> wrote:
>
> Did you ever post your ruleset and example tables ? I don't think pf
> changed that much between 8.2-RELEASE to 8.3 as it stands now in the
> aspects that would effect this outcome.
>
> I am on 8.3-STABLE and the configuration of rules sounds similiar to
> yours but I am not exhibiting any problems. Rule order is also key here
> so be sure to check that.
>
>
> On Fri, Apr 13, 2012 at 03:39:44AM +0200, Damien Fleuriot wrote:
>> Sending to -pf since nobody in -stable seemed interested.
>>
>> Kindly let me know if I can be of assistance to track down the issue.
>>
>> For the record, a source update against RELENG_8 today (2012/04/12)
>> did not show any updated file regarding PF, so I guess this still is
>> an issue.
>>
>>
>> ---------- Forwarded message ----------
>> From: Damien Fleuriot <ml@my.gd>
>> Date: 12 April 2012 16:08
>> Subject: PF - pf not loading non-persist tables from main ruleset on
>> 8.3-PRERELEASE
>> To: freebsd-stable@freebsd.org
>>
>>
>> Hello list,
>>
>>
>>
>> I installed a box recently and updated it to 8.3-PRERELEASE on 2012/04/11
>>
>>
>> I'm experiencing this extremely weird behavior where PF refuses to
>> load standard and const table definitions from the main ruleset.
>> - persist tables load just fine
>> - normal and const tables inside anchors load just fine
>>
>>
>>
>> Does anyone else have the same problem ?
>>
>> I'll try to update the kernel again, you never know.
>> _______________________________________________
>> 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"
>
> --
> ;s =;
From daniel at benzedrine.cx  Fri Apr 13 07:27:19 2012
From: daniel at benzedrine.cx (Daniel Hartmeier)
Date: Fri Apr 13 07:27:26 2012
Subject: PF - pf not loading non-persist tables from main ruleset on
	8.3-PRERELEASE
In-Reply-To: <CAE63ME7i3fyORKw2A4t6B6G4zL7qmqb1bBWTvCpbV+VJ-bjZTg@mail.gmail.com>
References: <CAE63ME7ZywicorwMC-3DTyBmRnO1ZLF2f_vjD_dNDnLM-TAgKQ@mail.gmail.com>
	<CAE63ME7d4jk-GPX2dnCqGvRV-uYm=ur_uci+aQ8UyzXZ7x9ghg@mail.gmail.com>
	<20120413030455.GA40140@DataIX.net>
	<CAE63ME7i3fyORKw2A4t6B6G4zL7qmqb1bBWTvCpbV+VJ-bjZTg@mail.gmail.com>
Message-ID: <20120413071414.GA20180@insomnia.benzedrine.cx>

But you're not referencing the tables in your rules!

>From pf.conf(5)

     persist  The persist flag forces the kernel to keep the table even when
              no rules refer to it.  If the flag is not set, the kernel will
              automatically remove the table when the last rule referring to
              it is flushed.

Daniel
From ml at my.gd  Fri Apr 13 07:35:31 2012
From: ml at my.gd (Damien Fleuriot)
Date: Fri Apr 13 07:35:41 2012
Subject: PF - pf not loading non-persist tables from main ruleset on
	8.3-PRERELEASE
In-Reply-To: <20120413071414.GA20180@insomnia.benzedrine.cx>
References: <CAE63ME7ZywicorwMC-3DTyBmRnO1ZLF2f_vjD_dNDnLM-TAgKQ@mail.gmail.com>
	<CAE63ME7d4jk-GPX2dnCqGvRV-uYm=ur_uci+aQ8UyzXZ7x9ghg@mail.gmail.com>
	<20120413030455.GA40140@DataIX.net>
	<CAE63ME7i3fyORKw2A4t6B6G4zL7qmqb1bBWTvCpbV+VJ-bjZTg@mail.gmail.com>
	<20120413071414.GA20180@insomnia.benzedrine.cx>
Message-ID: <CAE63ME4Y-sp__Sza-dtiZ7pRcecs-35BcddS9Tg7U2zivtpSPw@mail.gmail.com>

On 13 April 2012 09:14, Daniel Hartmeier <daniel@benzedrine.cx> wrote:
> But you're not referencing the tables in your rules!
>
> From pf.conf(5)
>
> ? ? persist ?The persist flag forces the kernel to keep the table even when
> ? ? ? ? ? ? ?no rules refer to it. ?If the flag is not set, the kernel will
> ? ? ? ? ? ? ?automatically remove the table when the last rule referring to
> ? ? ? ? ? ? ?it is flushed.
>
> Daniel


Oh god, could that be it...

Let me try with a rule referencing the tables... -.-
From ml at my.gd  Fri Apr 13 07:41:23 2012
From: ml at my.gd (Damien Fleuriot)
Date: Fri Apr 13 07:41:30 2012
Subject: PF - pf not loading non-persist tables from main ruleset on
	8.3-PRERELEASE
In-Reply-To: <CAE63ME4Y-sp__Sza-dtiZ7pRcecs-35BcddS9Tg7U2zivtpSPw@mail.gmail.com>
References: <CAE63ME7ZywicorwMC-3DTyBmRnO1ZLF2f_vjD_dNDnLM-TAgKQ@mail.gmail.com>
	<CAE63ME7d4jk-GPX2dnCqGvRV-uYm=ur_uci+aQ8UyzXZ7x9ghg@mail.gmail.com>
	<20120413030455.GA40140@DataIX.net>
	<CAE63ME7i3fyORKw2A4t6B6G4zL7qmqb1bBWTvCpbV+VJ-bjZTg@mail.gmail.com>
	<20120413071414.GA20180@insomnia.benzedrine.cx>
	<CAE63ME4Y-sp__Sza-dtiZ7pRcecs-35BcddS9Tg7U2zivtpSPw@mail.gmail.com>
Message-ID: <CAE63ME6c+VMQ-2tqVfF9XrWYbJxwOG2cvt7sguF4J-Oh+Z1G-w@mail.gmail.com>

On 13 April 2012 09:35, Damien Fleuriot <ml@my.gd> wrote:
> On 13 April 2012 09:14, Daniel Hartmeier <daniel@benzedrine.cx> wrote:
>> But you're not referencing the tables in your rules!
>>
>> From pf.conf(5)
>>
>> ? ? persist ?The persist flag forces the kernel to keep the table even when
>> ? ? ? ? ? ? ?no rules refer to it. ?If the flag is not set, the kernel will
>> ? ? ? ? ? ? ?automatically remove the table when the last rule referring to
>> ? ? ? ? ? ? ?it is flushed.
>>
>> Daniel
>
>
> Oh god, could that be it...
>
> Let me try with a rule referencing the tables... -.-
>


Works much better...

Thank you for your help, what a dumb mistake from me and what a loss of time.
From eri at freebsd.org  Fri Apr 13 08:36:30 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Fri Apr 13 08:36:37 2012
Subject: Panic in packet filter
In-Reply-To: <20120413012931.00006832@unknown>
References: <CAOxY2CotiKHHcw+jv2pAi6CbZ7oM3V7ohMrwHY0XhrwTAaRz1w@mail.gmail.com>
	<CAPBZQG16nbu09Bj8rKYUQbuRvCFikvF28REcM41t2urVzn7c1w@mail.gmail.com>
	<CAOxY2Cph2rt-1wnoQRBdsr+mLCHyBaMAYW2o8Z08W+3Dz-_7iw@mail.gmail.com>
	<D25EB30E-9241-4B81-A312-E37861DA5017@apple-park.kiev.ua>
	<20120412141632.00007c72@unknown>
	<CAPBZQG352UtXQ+4STkHNwF0f3e4z_2q=0zoRSBDCTZFMAJRAQg@mail.gmail.com>
	<20120413012931.00006832@unknown>
Message-ID: <CAPBZQG0SR2+Nn_JySFywtSf1wkYJ7Utv8J-UdWDPSxyyRswoXA@mail.gmail.com>

On Fri, Apr 13, 2012 at 12:29 AM, Theodor-Iulian Ciobanu
<thciobanu@nth.ro> wrote:
> On Thu, 12 Apr 2012 15:01:46 +0200
> Ermal Lu?i <eri@freebsd.org> wrote:
>
>> Hello,
>>
>> On Thu, Apr 12, 2012 at 1:16 PM, Theodor-Iulian Ciobanu
>> <thciobanu@nth.ro> wrote:
>> > Hello,
>> >
>> > I came across this same issue yesterday on a system I have just set
>> > up. I'm currently using the default kernel:
>> >
>> > FreeBSD changeme 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan ?3
>> > 07:46:30 UTC 2012
>> > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>> >
>> > with pf obviously loaded as a module. Even with kern.smp.disabled=1
>> > pf will crash as soon as it matches a rule that contains tables with
>> > counters (I added such a table with just three addresses).
>> >
>> > I'll have this machine around for testing for about a week or so
>> > and am willing to try out any available patches to help fix the
>> > issue.
>> >
>>
>> Try this patch
>> http://people.freebsd.org/~eri/pf_table_counter_fix.diff. It should
>> fix the issue for you.
>>
>> Seems there is a forgotten pool initialization for this, my fault!
>>
>> Though looking at it the whole thing seems a microoptimization that is
>> still present on latest OpenBSD code,
>> that saves about 16bytes!
>>
>> Anyway see if it fixes the issue to get this committed.
>
> Great use of 16b, as it doesn't seem to crash anymore, at least in a
> simple synthetic test (uploading C:\Windows from 2 systems at once
> through ftp, 10 transfer connections each).
>

Thank you for testing.
Just on the side of the 16bytes it might have a reason of guaranteeing
stable ABI while extending stats.
Either way will see to get this committed.

> Thank you!
>
>> > On Fri Feb 24 14:47:53 2012
>> > iskander at apple-park.kiev.ua (Alexander Vyrlanovich) wrote:
>> >
>> >>
>> >> On 24 Feb 2012, at 11:10, Ali Mdidech wrote:
>> >>
>> >> > Hi Ermal,
>> >> >
>> >> > 2012/2/24 Ermal Lu?i <eri@freebsd.org>:
>> >> >> On Thu, Feb 23, 2012 at 8:44 AM, Ali Mdidech <ali@moua7.com>
>> >> >> wrote:
>> >> >>> Hi List,
>> >> >>>
>> >> >>> I've a box that panics multiple times randomly since a year
>> >> >>> whatever the release is (8 or 9)
>> >> >>> The crash dump shows that the problem is related to pf.
>> >> >>> Is this some sort of identified bug?
>> >> >>> Below some info and my pf.conf file.
>> >> >>>
>> >> >>> Thank you very much for your help.
>> >> >>>
>> >> >>
>> >> >> Can you try do disable SMP through sysctl and see if you still
>> >> >> get this?
>> >> >> What are you doing to get the panic?
>> >> >
>> >> > Well, I'm able now to avoid or reproduce the panic.
>> >> > Disabling counters in <ssh_brute> table makes the server stable
>> >> > enough and no panic for 48 hours.
>> >> > Restoring the counters and adding a host in the table by hand
>> >> > (pfctl -t ssh_brute -T add someip) provokes the panic within few
>> >> > seconds. I've disabled smp (adding kern.smp.disabled=1 in
>> >> > loader.conf and rebooting) => kernel still panics.
>> >> >
>> >> > FreeBSD somehost 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Sat Jan 21
>> >> > 09:31:30 CET 2012 ? ? root@somehost:/usr/obj/usr/src/sys/DDX3KRNL
>> >> > i386
>> >> I can confirm that problem with counters in pf tables persist
>> >> at last on i386 and amd64. My systems is:
>> >>
>> >> FreeBSD gw 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Jan ?3 15:55:41
>> >> EET 2012
>> >> root@gw:/usr/obj/usr/src/sys/GW3 ?amd64
>> >>
>> >> FreeBSD gw2 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Wed Jan 25 13:52:48
>> >> EET 2012
>> >> root@gw2:/usr/obj/usr/src/sys/GWS90 ?i386
>> >>
>> >> pf + altq compiled in kernel
>> >>
>> >> Same result: kernel panic. Without counters systems is rock solid.
>> >>
>> >> >> Also its very helpful to know the `uname -a` command output.
>> >> >>
>> >> >>> panic: page fault
>> >> >>>
>> >> >>> GNU gdb 6.1.1 [FreeBSD]
>> >> >>> Copyright 2004 Free Software Foundation, Inc.
>> >> >>> GDB is free software, covered by the GNU General Public
>> >> >>> License, and you are
>> >> >>> welcome to change it and/or distribute copies of it under
>> >> >>> certain conditions.
>> >> >>> Type "show copying" to see the conditions.
>> >> >>> There is absolutely no warranty for GDB. ?Type "show warranty"
>> >> >>> for details.
>> >> >>> This GDB was configured as "i386-marcel-freebsd"...
>> >> >>>
>> >> >>> Unread portion of the kernel message buffer:
>> >> >>>
>> >> >>>
>> >> >>> Fatal trap 12: page fault while in kernel mode
>> >> >>> cpuid = 0; apic id = 00
>> >> >>> fault virtual address ? = 0x6c
>> >> >>> fault code ? ? ? ? ? ? ?= supervisor read, page not present
>> >> >>> instruction pointer ? ? = 0x20:0xc0a25dc0
>> >> >>> stack pointer ? ? ? ? ? = 0x28:0xc4df5910
>> >> >>> frame pointer ? ? ? ? ? = 0x28:0xc4df5954
>> >> >>> code segment ? ? ? ? ? ?= base 0x0, limit 0xfffff, type 0x1b
>> >> >>> ? ? ? ? ? ? ? ? ? ? ? ?= DPL 0, pres 1, def32 1, gran 1
>> >> >>> processor eflags ? ? ? ?= interrupt enabled, resume, IOPL = 0
>> >> >>> current process ? ? ? ? = 12 (irq256: em0:rx 0)
>> >> >>> trap number ? ? ? ? ? ? = 12
>> >> >>> panic: page fault
>> >> >>> cpuid = 0
>> >> >>> KDB: stack backtrace:
>> >> >>> #0 0xc08380b7 at kdb_backtrace+0x47
>> >> >>> #1 0xc0805617 at panic+0x117
>> >> >>> #2 0xc0aebcc3 at trap_fatal+0x323
>> >> >>> #3 0xc0aec802 at trap+0x182
>> >> >>> #4 0xc0ad5f8c at calltrap+0x6
>> >> >>> #5 0xc589f7cc at pfr_update_stats+0x1cc
>> >> >>> #6 0xc588de21 at pf_test+0x981
>> >> >>> #7 0xc5895e79 at pf_check_in+0x39
>> >> >>> #8 0xc08c3c68 at pfil_run_hooks+0x78
>> >> >>> #9 0xc08e18ae at ip_input+0x24e
>> >> >>> #10 0xc08c2d9f at netisr_dispatch_src+0x8f
>> >> >>> #11 0xc08c3040 at netisr_dispatch+0x20
>> >> >>> #12 0xc08b9721 at ether_demux+0x171
>> >> >>> #13 0xc08b9b6f at ether_nh_input+0x37f
>> >> >>> #14 0xc08c2d9f at netisr_dispatch_src+0x8f
>> >> >>> #15 0xc08c3040 at netisr_dispatch+0x20
>> >> >>> #16 0xc08b9269 at ether_input+0x19
>> >> >>> #17 0xc05b383f at em_rxeof+0x30f
>> >> >>> Uptime: 1h45m44s
>> >> >>> Physical memory: 2002 MB
>> >> >>> Dumping 185 MB: 170 154 138 122 106 90 74 58 42 26 10
>> >> >>>
>> >> >>> Reading symbols from /boot/kernel/pf.ko...Reading symbols from
>> >> >>> /boot/kernel/pf.ko.symbols...
>> >> >>> done.
>> >> >>> done.
>> >> >>> Loaded symbols for /boot/kernel/pf.ko
>> >> >>> #0 ?doadump (textdump=1) at pcpu.h:244
>> >> >>> 244 ? ? pcpu.h: No such file or directory.
>> >> >>> ? ? ? ?in pcpu.h
>> >> >>> (kgdb) #0 ?doadump (textdump=1) at pcpu.h:244
>> >> >>> #1 ?0xc08053ba in kern_reboot (howto=260)
>> >> >>> ? ?at /usr/src/sys/kern/kern_shutdown.c:442
>> >> >>> #2 ?0xc0805651 in panic (fmt=Variable "fmt" is not available.
>> >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:607
>> >> >>> #3 ?0xc0aebcc3 in trap_fatal (frame=0xc4df58d0, eva=108)
>> >> >>> ? ?at /usr/src/sys/i386/i386/trap.c:975
>> >> >>> #4 ?0xc0aec802 in trap (frame=0xc4df58d0) at /usr/src/sys/i386/
>> >> >>> i386/trap.c:352
>> >> >>> #5 ?0xc0ad5f8c in calltrap () at /usr/src/sys/i386/i386/
>> >> >>> exception.s:168
>> >> >>> #6 ?0xc0a25dc0 in uma_zalloc_arg (zone=0x0, udata=0x0,
>> >> >>> flags=257) at pcpu.h:244
>> >> >>> #7 ?0xc589f7cc in pfr_update_stats (kt=0xc58d44d8,
>> >> >>> a=0xc56aa01a, af=2 '\002',
>> >> >>> ? ?len=52, dir_out=0, op_pass=0, notrule=0) at uma.h:305
>> >> >>> #8 ?0xc588de21 in pf_test (dir=1, ifp=0xc5253c00,
>> >> >>> m0=0xc4df5acc, eh=0x0,
>> >> >>> ? ?inp=0x0)
>> >> >>> at /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c: 7057
>> >> >>> #9 ?0xc5895e79 in pf_check_in (arg=0x0, m=0xc4df5acc,
>> >> >>> ifp=0xc5253c00, dir=1,
>> >> >>> ? ?inp=0x0) at /usr/src/sys/modules/pf/../../contrib/pf/net/
>> >> >>> pf_ioctl.c:4139
>> >> >>> #10 0xc08c3c68 in pfil_run_hooks (ph=0xc0d685e0, mp=0xc4df5b24,
>> >> >>> ? ?ifp=0xc5253c00, dir=1, inp=0x0)
>> >> >>> at /usr/src/sys/net/pfil.c:82 #11 0xc08e18ae in ip_input
>> >> >>> (m=0xc567db00) at /usr/src/sys/netinet/ip_input.c:510
>> >> >>> #12 0xc08c2d9f in netisr_dispatch_src (proto=1, source=0,
>> >> >>> m=0xc567db00)
>> >> >>> ? ?at /usr/src/sys/net/netisr.c:1013
>> >> >>> #13 0xc08c3040 in netisr_dispatch (proto=1, m=0xc567db00)
>> >> >>> ? ?at /usr/src/sys/net/netisr.c:1104
>> >> >>> #14 0xc08b9721 in ether_demux (ifp=0xc5253c00, m=0xc567db00)
>> >> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:937
>> >> >>> #15 0xc08b9b6f in ether_nh_input (m=0xc567db00)
>> >> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:756
>> >> >>> #16 0xc08c2d9f in netisr_dispatch_src (proto=9, source=0,
>> >> >>> m=0xc567db00)
>> >> >>> ? ?at /usr/src/sys/net/netisr.c:1013
>> >> >>> #17 0xc08c3040 in netisr_dispatch (proto=9, m=0xc567db00)
>> >> >>> ? ?at /usr/src/sys/net/netisr.c:1104
>> >> >>> #18 0xc08b9269 in ether_input (ifp=0xc5253c00, m=0xc567db00)
>> >> >>> ? ?at /usr/src/sys/net/if_ethersubr.c:797
>> >> >>> #19 0xc05b383f in em_rxeof (rxr=0xc520bc00, count=99, done=0x0)
>> >> >>> ? ?at /usr/src/sys/dev/e1000/if_em.c:4340
>> >> >>> #20 0xc05b3a06 in em_msix_rx (arg=0xc520bc00)
>> >> >>> ? ?at /usr/src/sys/dev/e1000/if_em.c:1577
>> >> >>> #21 0xc07da6eb in intr_event_execute_handlers (p=0xc5157588,
>> >> >>> ie=0xc5241680)
>> >> >>> ? ?at /usr/src/sys/kern/kern_intr.c:1257
>> >> >>> #22 0xc07dbeaa in ithread_loop (arg=0xc52506e0)
>> >> >>> ? ?at /usr/src/sys/kern/kern_intr.c:1270
>> >> >>> #23 0xc07d78f7 in fork_exit (callout=0xc07dbe30 <ithread_loop>,
>> >> >>> ? ?arg=0xc52506e0, frame=0xc4df5d28) at /usr/src/sys/kern/
>> >> >>> kern_fork.c:995
>> >> >>> #24 0xc0ad6004 in fork_trampoline () at /usr/src/sys/i386/i386/
>> >> >>> exception.s:275
>> >> >>> (kgdb)
>> >> >>>
>> >> >>>
>> >> >>> ################## pf.conf ##################
>> >> >>> ext_if = "em0"
>> >> >>>
>> >> >>> public_tcp_ports = "{21,25,53,80,143,443,873,993,50021:50121}"
>> >> >>> public_udp_ports = "53"
>> >> >>>
>> >> >>> table <secure> {someip}
>> >> >>> table <ssh_brute> persist counters
>> >> >>>
>> >> >>> ### Redirection for SMTP
>> >> >>> rdr on $ext_if proto tcp from any to $ext_if port 225 ->
>> >> >>> $ext_if port 25
>> >> >>>
>> >> >>> ### Block everything in an pass everything out
>> >> >>> pass out on $ext_if all modulate state
>> >> >>> block in on $ext_if all
>> >> >>>
>> >> >>> ### secure users
>> >> >>> pass in quick on $ext_if proto tcp from <secure> to any flags
>> >> >>> S/SA \ modulate state
>> >> >>>
>> >> >>> ### public tcp/udp ports rules
>> >> >>> pass in on $ext_if proto udp to $ext_if port $public_udp_ports
>> >> >>> pass in on $ext_if proto tcp to $ext_if port $public_tcp_ports
>> >> >>> flags S/SA \
>> >> >>> modulate state
>> >> >>>
>> >> >>> ### block ssh bruteforce
>> >> >>> block in quick from <ssh_brute>
>> >> >>> pass in quick on $ext_if proto tcp to $ext_if port 22 flags
>> >> >>> S/SA modulate state \
>> >> >>> (max-src-conn 5, max-src-conn-rate 10/60, overload <ssh_brute>
>> >> >>> flush global)
>> >> >>>
>> >> >>> ### block icmp timestamp request/response
>> >> >>> block in quick on $ext_if inet proto icmp all icmp-type {13,
>> >> >>> 14} pass in quick on $ext_if proto icmp all
>> >> >>>
>> >> >>> ############ end pf.conf ##############
>> >> >>>
>> >> >>> --
>> >> >>> Ali Mdidech
>> >> >>> _______________________________________________
>> >> >>> 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"
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Ermal
>> >> >
>> >> > --
>> >> > Ali Mdidech
>> >> > _______________________________________________
>> >> > 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"
>> >>
>> >> ????????? ??????????
>> >> --------------------------
>> >> ????????? ?????????????
>> >> ??? "???"
>> >
>> > --
>> > Theo
>> > _______________________________________________
>> > 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"
>
> --
> Theo
> _______________________________________________
> 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"



-- 
Ermal
From glebius at FreeBSD.org  Sun Apr 15 11:10:03 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Sun Apr 15 11:10:09 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
Message-ID: <201204151110.q3FBA3Fr034331@freefall.freebsd.org>

The following reply was made to PR kern/164402; it has been noted by GNATS.

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: "Eugene M. Zheganin" <eugene@zhegan.in>
Cc: bug-followup@FreeBSD.org
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
Date: Sun, 15 Apr 2012 15:07:56 +0400

   Hi,
 
   I have a vague suspicion on what is happening. Your description of
 the problem looks like if a packet processing in the kernel has entered
 an endless loop.
 
   Looking at pf_route() I see such possibility. From OpenBSD we have
 this protection against endless looping:
 
         if ((*m)->m_pkthdr.pf.routed++ > 3) {
                 m0 = *m;
                 *m = NULL;
                 goto bad;
         }
 
 In our code this transforms to:
 
         if (pd->pf_mtag->routed++ > 3) {
                 m0 = *m;
                 *m = NULL;
                 goto bad;
         }
 
 The root difference between storing the tag on mbuf and on pfdesc
 is that we lose pfdesc, and thus the tag, when we enter pf_test()
 recursively. And pf_route() does this recursion:
 
         if (oifp != ifp) {
                 if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
                         goto bad;
 	....
 
 -- 
 Totus tuus, Glebius.
From glebius at FreeBSD.org  Sun Apr 15 11:51:29 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Sun Apr 15 11:51:35 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <201204151110.q3FBA3Fr034331@freefall.freebsd.org>
References: <201204151110.q3FBA3Fr034331@freefall.freebsd.org>
Message-ID: <20120415115124.GO9391@FreeBSD.org>

On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
T>    I have a vague suspicion on what is happening. Your description of
T>  the problem looks like if a packet processing in the kernel has entered
T>  an endless loop.
T>  
T>    Looking at pf_route() I see such possibility. From OpenBSD we have
T>  this protection against endless looping:
T>  
T>          if ((*m)->m_pkthdr.pf.routed++ > 3) {
T>                  m0 = *m;
T>                  *m = NULL;
T>                  goto bad;
T>          }
T>  
T>  In our code this transforms to:
T>  
T>          if (pd->pf_mtag->routed++ > 3) {
T>                  m0 = *m;
T>                  *m = NULL;
T>                  goto bad;
T>          }
T>  
T>  The root difference between storing the tag on mbuf and on pfdesc
T>  is that we lose pfdesc, and thus the tag, when we enter pf_test()
T>  recursively. And pf_route() does this recursion:
T>  
T>          if (oifp != ifp) {
T>                  if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
T>                          goto bad;
T>  	....

On second look I see that my suspicion may not be true. In the
beginning of pf_test() we do pf_get_mtag() which preserves already
present tag if there is one.

-- 
Totus tuus, Glebius.
From glebius at FreeBSD.org  Sun Apr 15 11:53:13 2012
From: glebius at FreeBSD.org (glebius@FreeBSD.org)
Date: Sun Apr 15 11:53:20 2012
Subject: kern/166411: [pf] simply enabling pf makes udpxy not to work
Message-ID: <201204151153.q3FBrDrx084837@freefall.freebsd.org>

Synopsis: [pf] simply enabling pf makes udpxy not to work

State-Changed-From-To: open->closed
State-Changed-By: glebius
State-Changed-When: Sun Apr 15 11:52:16 UTC 2012
State-Changed-Why: 
pf(4) dropping packets with IP options by default isn't
a bug, but a (annoying) feature.

http://www.freebsd.org/cgi/query-pr.cgi?pr=166411
From glebius at FreeBSD.org  Sun Apr 15 12:00:21 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Sun Apr 15 12:00:27 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
Message-ID: <201204151200.q3FC0LT5085161@freefall.freebsd.org>

The following reply was made to PR kern/164402; it has been noted by GNATS.

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: freebsd-pf@FreeBSD.org
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
Date: Sun, 15 Apr 2012 15:51:24 +0400

 On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
 T>    I have a vague suspicion on what is happening. Your description of
 T>  the problem looks like if a packet processing in the kernel has entered
 T>  an endless loop.
 T>  
 T>    Looking at pf_route() I see such possibility. From OpenBSD we have
 T>  this protection against endless looping:
 T>  
 T>          if ((*m)->m_pkthdr.pf.routed++ > 3) {
 T>                  m0 = *m;
 T>                  *m = NULL;
 T>                  goto bad;
 T>          }
 T>  
 T>  In our code this transforms to:
 T>  
 T>          if (pd->pf_mtag->routed++ > 3) {
 T>                  m0 = *m;
 T>                  *m = NULL;
 T>                  goto bad;
 T>          }
 T>  
 T>  The root difference between storing the tag on mbuf and on pfdesc
 T>  is that we lose pfdesc, and thus the tag, when we enter pf_test()
 T>  recursively. And pf_route() does this recursion:
 T>  
 T>          if (oifp != ifp) {
 T>                  if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
 T>                          goto bad;
 T>  	....
 
 On second look I see that my suspicion may not be true. In the
 beginning of pf_test() we do pf_get_mtag() which preserves already
 present tag if there is one.
 
 -- 
 Totus tuus, Glebius.
From bugmaster at FreeBSD.org  Mon Apr 16 11:07:24 2012
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 16 11:09:26 2012
Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org
Message-ID: <201204161107.q3GB7NZa022474@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/166336  pf         [pf] kern.securelevel 3 +pf reload
o kern/165315  pf         [pf] States never cleared in PF with DEVICE_POLLING
o kern/164402  pf         [pf] pf crashes with a particular set of rules when fi
o kern/164271  pf         [pf] not working pf nat on FreeBSD 9.0 [regression]
o kern/163208  pf         [pf] PF state key linking mismatch
o kern/160370  pf         [pf] Incorrect pfctl check of pf.conf
o kern/155736  pf         [pf] [altq] borrow from parent queue does not work wit
o kern/153307  pf         [pf] Bug with PF firewall
o kern/148290  pf         [pf] "sticky-address" option of Packet Filter (PF) blo
o kern/148260  pf         [pf] [patch] pf rdr incompatible with dummynet
o kern/147789  pf         [pf] Firewall PF no longer drops connections by sendin
o kern/143543  pf         [pf] [panic] PF route-to causes kernel panic
o bin/143504   pf         [patch] outgoing states are not killed by authpf(8)
o conf/142961  pf         [pf] No way to adjust pidfile in pflogd
o conf/142817  pf         [patch] etc/rc.d/pf: silence pfctl
o kern/141905  pf         [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697  pf         [pf] pf behaviour changes - must be documented
o kern/137982  pf         [pf] when pf can hit state limits, random IP failures 
o kern/136781  pf         [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948  pf         [pf] [gre] pf not natting gre protocol
o kern/135162  pf         [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996  pf         [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732  pf         [pf] max-src-conn issue
o kern/132769  pf         [pf] [lor] 2 LOR's with pf task mtx / ifnet and  rtent
f kern/132176  pf         [pf] pf stalls connection when using route-to [regress
o conf/130381  pf         [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861  pf         [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920  pf         [pf] ipv6 and synproxy don't play well together
o conf/127814  pf         [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439  pf         [pf] deadlock in pf
o kern/127121  pf         [pf] [patch] pf incorrect log priority
o kern/127042  pf         [pf] [patch] pf recursion panic if interface group is 
o kern/125467  pf         [pf] pf keep state bug while handling sessions between
s kern/124933  pf         [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364  pf         [pf] [panic] Kernel panic with pf + bridge
o kern/122773  pf         [pf] pf doesn't log uid or pid when configured to
o kern/122014  pf         [pf] [panic] FreeBSD 6.2 panic in pf
o kern/120281  pf         [pf] [request] lost returning packets to PF for a rdr 
o kern/120057  pf         [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355   pf         [pf] [patch] pfctl(8) help message options order false
o kern/114567  pf         [pf] [lor] pf_ioctl.c + if.c
s conf/110838  pf         [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283  pf         pfsync fails to sucessfully transfer some sessions
o kern/103281  pf         pfsync reports bulk update failures
o kern/93825   pf         [pf] pf reply-to doesn't work
o sparc/93530  pf         [pf] Incorrect checksums when using pf's route-to on s
o kern/92949   pf         [pf] PF + ALTQ problems with latency
o bin/86635    pf         [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271   pf         [pf] cbq scheduler cause bad latency

49 problems total.

From glebius at FreeBSD.org  Mon Apr 16 18:59:51 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Mon Apr 16 18:59:57 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
Message-ID: <20120416185949.GC92286@FreeBSD.org>

On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
T>  On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
T>  T>    I have a vague suspicion on what is happening. Your description of
T>  T>  the problem looks like if a packet processing in the kernel has entered
T>  T>  an endless loop.
T>  T>  
T>  T>    Looking at pf_route() I see such possibility. From OpenBSD we have
T>  T>  this protection against endless looping:
T>  T>  
T>  T>          if ((*m)->m_pkthdr.pf.routed++ > 3) {
T>  T>                  m0 = *m;
T>  T>                  *m = NULL;
T>  T>                  goto bad;
T>  T>          }
T>  T>  
T>  T>  In our code this transforms to:
T>  T>  
T>  T>          if (pd->pf_mtag->routed++ > 3) {
T>  T>                  m0 = *m;
T>  T>                  *m = NULL;
T>  T>                  goto bad;
T>  T>          }
T>  T>  
T>  T>  The root difference between storing the tag on mbuf and on pfdesc
T>  T>  is that we lose pfdesc, and thus the tag, when we enter pf_test()
T>  T>  recursively. And pf_route() does this recursion:
T>  T>  
T>  T>          if (oifp != ifp) {
T>  T>                  if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
T>  T>                          goto bad;
T>  T>  	....
T>  
T>  On second look I see that my suspicion may not be true. In the
T>  beginning of pf_test() we do pf_get_mtag() which preserves already
T>  present tag if there is one.

Further investigation showed that problem exist when route applied
ends in lo0, and packet passes to if_simloop(). There all mtags are
stripped from the mbuf, including the pf mtag. Then packet is again
processed by ip_input() again entering pf(4), if it again matches
a routing rule, then we got an endless loop.

We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.

-- 
Totus tuus, Glebius.
From eri at freebsd.org  Tue Apr 17 08:06:16 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Tue Apr 17 08:06:22 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <20120416185949.GC92286@FreeBSD.org>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
Message-ID: <CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>

2012/4/16 Gleb Smirnoff <glebius@freebsd.org>:
> On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
> T> ?On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
> T> ?T> ? ?I have a vague suspicion on what is happening. Your description of
> T> ?T> ?the problem looks like if a packet processing in the kernel has entered
> T> ?T> ?an endless loop.
> T> ?T>
> T> ?T> ? ?Looking at pf_route() I see such possibility. From OpenBSD we have
> T> ?T> ?this protection against endless looping:
> T> ?T>
> T> ?T> ? ? ? ? ?if ((*m)->m_pkthdr.pf.routed++ > 3) {
> T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
> T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
> T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
> T> ?T> ? ? ? ? ?}
> T> ?T>
> T> ?T> ?In our code this transforms to:
> T> ?T>
> T> ?T> ? ? ? ? ?if (pd->pf_mtag->routed++ > 3) {
> T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
> T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
> T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
> T> ?T> ? ? ? ? ?}
> T> ?T>
> T> ?T> ?The root difference between storing the tag on mbuf and on pfdesc
> T> ?T> ?is that we lose pfdesc, and thus the tag, when we enter pf_test()
> T> ?T> ?recursively. And pf_route() does this recursion:
> T> ?T>
> T> ?T> ? ? ? ? ?if (oifp != ifp) {
> T> ?T> ? ? ? ? ? ? ? ? ?if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
> T> ?T> ? ? ? ? ? ? ? ? ? ? ? ? ?goto bad;
> T> ?T> ? ? ? ? ?....
> T>
> T> ?On second look I see that my suspicion may not be true. In the
> T> ?beginning of pf_test() we do pf_get_mtag() which preserves already
> T> ?present tag if there is one.
>
> Further investigation showed that problem exist when route applied
> ends in lo0, and packet passes to if_simloop(). There all mtags are
> stripped from the mbuf, including the pf mtag. Then packet is again
> processed by ip_input() again entering pf(4), if it again matches
> a routing rule, then we got an endless loop.
>
> We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
>

That seems like the best fix for this case.

> --
> Totus tuus, Glebius.
> _______________________________________________
> 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"



-- 
Ermal
From glebius at FreeBSD.org  Tue Apr 17 08:14:09 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Tue Apr 17 08:14:15 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
Message-ID: <20120417081406.GA93887@glebius.int.ru>

On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote:
E> 2012/4/16 Gleb Smirnoff <glebius@freebsd.org>:
E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
E> > T> ?On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
E> > T> ?T> ? ?I have a vague suspicion on what is happening. Your description of
E> > T> ?T> ?the problem looks like if a packet processing in the kernel has entered
E> > T> ?T> ?an endless loop.
E> > T> ?T>
E> > T> ?T> ? ?Looking at pf_route() I see such possibility. From OpenBSD we have
E> > T> ?T> ?this protection against endless looping:
E> > T> ?T>
E> > T> ?T> ? ? ? ? ?if ((*m)->m_pkthdr.pf.routed++ > 3) {
E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
E> > T> ?T> ? ? ? ? ?}
E> > T> ?T>
E> > T> ?T> ?In our code this transforms to:
E> > T> ?T>
E> > T> ?T> ? ? ? ? ?if (pd->pf_mtag->routed++ > 3) {
E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
E> > T> ?T> ? ? ? ? ?}
E> > T> ?T>
E> > T> ?T> ?The root difference between storing the tag on mbuf and on pfdesc
E> > T> ?T> ?is that we lose pfdesc, and thus the tag, when we enter pf_test()
E> > T> ?T> ?recursively. And pf_route() does this recursion:
E> > T> ?T>
E> > T> ?T> ? ? ? ? ?if (oifp != ifp) {
E> > T> ?T> ? ? ? ? ? ? ? ? ?if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
E> > T> ?T> ? ? ? ? ? ? ? ? ? ? ? ? ?goto bad;
E> > T> ?T> ? ? ? ? ?....
E> > T>
E> > T> ?On second look I see that my suspicion may not be true. In the
E> > T> ?beginning of pf_test() we do pf_get_mtag() which preserves already
E> > T> ?present tag if there is one.
E> >
E> > Further investigation showed that problem exist when route applied
E> > ends in lo0, and packet passes to if_simloop(). There all mtags are
E> > stripped from the mbuf, including the pf mtag. Then packet is again
E> > processed by ip_input() again entering pf(4), if it again matches
E> > a routing rule, then we got an endless loop.
E> >
E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
E> 
E> That seems like the best fix for this case.

In this case crash or freeze is fixed, but still packet is dropped. Example
of such rule:

pass in on igb0 fastroute proto tcp from any to $localip

Anyway, dropping packets is much better than crashing.

-- 
Totus tuus, Glebius.
From eri at freebsd.org  Tue Apr 17 08:38:32 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Tue Apr 17 08:39:16 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <20120417081406.GA93887@glebius.int.ru>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
Message-ID: <CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>

2012/4/17 Gleb Smirnoff <glebius@freebsd.org>:
> On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote:
> E> 2012/4/16 Gleb Smirnoff <glebius@freebsd.org>:
> E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
> E> > T> ?On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
> E> > T> ?T> ? ?I have a vague suspicion on what is happening. Your description of
> E> > T> ?T> ?the problem looks like if a packet processing in the kernel has entered
> E> > T> ?T> ?an endless loop.
> E> > T> ?T>
> E> > T> ?T> ? ?Looking at pf_route() I see such possibility. From OpenBSD we have
> E> > T> ?T> ?this protection against endless looping:
> E> > T> ?T>
> E> > T> ?T> ? ? ? ? ?if ((*m)->m_pkthdr.pf.routed++ > 3) {
> E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
> E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
> E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
> E> > T> ?T> ? ? ? ? ?}
> E> > T> ?T>
> E> > T> ?T> ?In our code this transforms to:
> E> > T> ?T>
> E> > T> ?T> ? ? ? ? ?if (pd->pf_mtag->routed++ > 3) {
> E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
> E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
> E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
> E> > T> ?T> ? ? ? ? ?}
> E> > T> ?T>
> E> > T> ?T> ?The root difference between storing the tag on mbuf and on pfdesc
> E> > T> ?T> ?is that we lose pfdesc, and thus the tag, when we enter pf_test()
> E> > T> ?T> ?recursively. And pf_route() does this recursion:
> E> > T> ?T>
> E> > T> ?T> ? ? ? ? ?if (oifp != ifp) {
> E> > T> ?T> ? ? ? ? ? ? ? ? ?if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
> E> > T> ?T> ? ? ? ? ? ? ? ? ? ? ? ? ?goto bad;
> E> > T> ?T> ? ? ? ? ?....
> E> > T>
> E> > T> ?On second look I see that my suspicion may not be true. In the
> E> > T> ?beginning of pf_test() we do pf_get_mtag() which preserves already
> E> > T> ?present tag if there is one.
> E> >
> E> > Further investigation showed that problem exist when route applied
> E> > ends in lo0, and packet passes to if_simloop(). There all mtags are
> E> > stripped from the mbuf, including the pf mtag. Then packet is again
> E> > processed by ip_input() again entering pf(4), if it again matches
> E> > a routing rule, then we got an endless loop.
> E> >
> E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
> E>
> E> That seems like the best fix for this case.
>
> In this case crash or freeze is fixed, but still packet is dropped. Example
> of such rule:
>
> pass in on igb0 fastroute proto tcp from any to $localip
>
> Anyway, dropping packets is much better than crashing.
>

Actually after some coffee :) i think its better marking the packet
with M_SKIP_FIREWALL since
it has already taken its decision on this packet.

The simloop consumers seem to be just facilities of how things work
from what i can see.

So just delivering the packet by sending skipping the firewalls seems
more sensibile!

Though the persistent case for the tags should be revisited since it
may fix some other issues with pf(4) tags, and some others.

> --
> Totus tuus, Glebius.



-- 
Ermal
From eri at freebsd.org  Tue Apr 17 08:42:52 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Tue Apr 17 08:42:59 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
Message-ID: <CAPBZQG1W3DeBQmsTJhg2RFLA7Zdjx6BwRuRZJBzbjRL++vx7-w@mail.gmail.com>

On Tue, Apr 17, 2012 at 10:38 AM, Ermal Lu?i <eri@freebsd.org> wrote:
> 2012/4/17 Gleb Smirnoff <glebius@freebsd.org>:
>> On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote:
>> E> 2012/4/16 Gleb Smirnoff <glebius@freebsd.org>:
>> E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
>> E> > T> ?On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
>> E> > T> ?T> ? ?I have a vague suspicion on what is happening. Your description of
>> E> > T> ?T> ?the problem looks like if a packet processing in the kernel has entered
>> E> > T> ?T> ?an endless loop.
>> E> > T> ?T>
>> E> > T> ?T> ? ?Looking at pf_route() I see such possibility. From OpenBSD we have
>> E> > T> ?T> ?this protection against endless looping:
>> E> > T> ?T>
>> E> > T> ?T> ? ? ? ? ?if ((*m)->m_pkthdr.pf.routed++ > 3) {
>> E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
>> E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
>> E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
>> E> > T> ?T> ? ? ? ? ?}
>> E> > T> ?T>
>> E> > T> ?T> ?In our code this transforms to:
>> E> > T> ?T>
>> E> > T> ?T> ? ? ? ? ?if (pd->pf_mtag->routed++ > 3) {
>> E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
>> E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
>> E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
>> E> > T> ?T> ? ? ? ? ?}
>> E> > T> ?T>
>> E> > T> ?T> ?The root difference between storing the tag on mbuf and on pfdesc
>> E> > T> ?T> ?is that we lose pfdesc, and thus the tag, when we enter pf_test()
>> E> > T> ?T> ?recursively. And pf_route() does this recursion:
>> E> > T> ?T>
>> E> > T> ?T> ? ? ? ? ?if (oifp != ifp) {
>> E> > T> ?T> ? ? ? ? ? ? ? ? ?if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
>> E> > T> ?T> ? ? ? ? ? ? ? ? ? ? ? ? ?goto bad;
>> E> > T> ?T> ? ? ? ? ?....
>> E> > T>
>> E> > T> ?On second look I see that my suspicion may not be true. In the
>> E> > T> ?beginning of pf_test() we do pf_get_mtag() which preserves already
>> E> > T> ?present tag if there is one.
>> E> >
>> E> > Further investigation showed that problem exist when route applied
>> E> > ends in lo0, and packet passes to if_simloop(). There all mtags are
>> E> > stripped from the mbuf, including the pf mtag. Then packet is again
>> E> > processed by ip_input() again entering pf(4), if it again matches
>> E> > a routing rule, then we got an endless loop.
>> E> >
>> E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
>> E>
>> E> That seems like the best fix for this case.
>>
>> In this case crash or freeze is fixed, but still packet is dropped. Example
>> of such rule:
>>
>> pass in on igb0 fastroute proto tcp from any to $localip
>>
>> Anyway, dropping packets is much better than crashing.

To be more explicit, this breaks functionality.
Since as i said the firewall has already taken descision and the state
keeping for sure will drop this matching tcp packets.
You will not see it for other protos that do not have the state
transition like tcp though your statistics will be wrong.
This is not justifible and its better to crash :)

Though as i said the skip firewall flag seems more sensible.
>>
>
> Actually after some coffee :) i think its better marking the packet
> with M_SKIP_FIREWALL since
> it has already taken its decision on this packet.
>
> The simloop consumers seem to be just facilities of how things work
> from what i can see.
>
> So just delivering the packet by sending skipping the firewalls seems
> more sensibile!
>
> Though the persistent case for the tags should be revisited since it
> may fix some other issues with pf(4) tags, and some others.
>
>> --
>> Totus tuus, Glebius.
>
>
>
> --
> Ermal



-- 
Ermal
From glebius at FreeBSD.org  Tue Apr 17 08:46:10 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Tue Apr 17 08:46:16 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
Message-ID: <20120417084608.GA99119@glebius.int.ru>

On Tue, Apr 17, 2012 at 10:38:31AM +0200, Ermal Lu?i wrote:
E> 2012/4/17 Gleb Smirnoff <glebius@freebsd.org>:
E> > On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote:
E> > E> 2012/4/16 Gleb Smirnoff <glebius@freebsd.org>:
E> > E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
E> > E> > T> ?On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
E> > E> > T> ?T> ? ?I have a vague suspicion on what is happening. Your description of
E> > E> > T> ?T> ?the problem looks like if a packet processing in the kernel has entered
E> > E> > T> ?T> ?an endless loop.
E> > E> > T> ?T>
E> > E> > T> ?T> ? ?Looking at pf_route() I see such possibility. From OpenBSD we have
E> > E> > T> ?T> ?this protection against endless looping:
E> > E> > T> ?T>
E> > E> > T> ?T> ? ? ? ? ?if ((*m)->m_pkthdr.pf.routed++ > 3) {
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
E> > E> > T> ?T> ? ? ? ? ?}
E> > E> > T> ?T>
E> > E> > T> ?T> ?In our code this transforms to:
E> > E> > T> ?T>
E> > E> > T> ?T> ? ? ? ? ?if (pd->pf_mtag->routed++ > 3) {
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ?m0 = *m;
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ?*m = NULL;
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ?goto bad;
E> > E> > T> ?T> ? ? ? ? ?}
E> > E> > T> ?T>
E> > E> > T> ?T> ?The root difference between storing the tag on mbuf and on pfdesc
E> > E> > T> ?T> ?is that we lose pfdesc, and thus the tag, when we enter pf_test()
E> > E> > T> ?T> ?recursively. And pf_route() does this recursion:
E> > E> > T> ?T>
E> > E> > T> ?T> ? ? ? ? ?if (oifp != ifp) {
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ?if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
E> > E> > T> ?T> ? ? ? ? ? ? ? ? ? ? ? ? ?goto bad;
E> > E> > T> ?T> ? ? ? ? ?....
E> > E> > T>
E> > E> > T> ?On second look I see that my suspicion may not be true. In the
E> > E> > T> ?beginning of pf_test() we do pf_get_mtag() which preserves already
E> > E> > T> ?present tag if there is one.
E> > E> >
E> > E> > Further investigation showed that problem exist when route applied
E> > E> > ends in lo0, and packet passes to if_simloop(). There all mtags are
E> > E> > stripped from the mbuf, including the pf mtag. Then packet is again
E> > E> > processed by ip_input() again entering pf(4), if it again matches
E> > E> > a routing rule, then we got an endless loop.
E> > E> >
E> > E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
E> > E>
E> > E> That seems like the best fix for this case.
E> >
E> > In this case crash or freeze is fixed, but still packet is dropped. Example
E> > of such rule:
E> >
E> > pass in on igb0 fastroute proto tcp from any to $localip
E> >
E> > Anyway, dropping packets is much better than crashing.
E> >
E> 
E> Actually after some coffee :) i think its better marking the packet
E> with M_SKIP_FIREWALL since
E> it has already taken its decision on this packet.
E> 
E> The simloop consumers seem to be just facilities of how things work
E> from what i can see.
E> 
E> So just delivering the packet by sending skipping the firewalls seems
E> more sensibile!
E> 
E> Though the persistent case for the tags should be revisited since it
E> may fix some other issues with pf(4) tags, and some others.

We can make the assignment like:

if (ifp->if_flags & IFF_LOOPBACK)
	m->m_flags |= M_SKIP_FIREWALL;

Because only loopback interface is special: processing its ifp->if_output()
leads to re-entering ip_input().

I'm afraid that if we mark all pf-routed packets as M_SKIP_FIREWALL, that
can lead to a case when packet is routed by pf processing on input hook, and
then it skips processing the output hook, and that can lead to state
not being updated and session stuck.

Still, I think that pf tag deserves MTAG_PERSISTENT. That would keep us
in-line with OpenBSD, since they store pf information right in the pkthdr,
and I don't think that they erase it anywhere until mbuf is freed.

-- 
Totus tuus, Glebius.
From eri at freebsd.org  Tue Apr 17 09:33:28 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Tue Apr 17 09:33:34 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <20120417084608.GA99119@glebius.int.ru>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
	<20120417084608.GA99119@glebius.int.ru>
Message-ID: <CAPBZQG0ujzB+7xTFpvhjRVbrtBEeABXHeKDx-WjbSOaAWX0-sA@mail.gmail.com>

2012/4/17 Gleb Smirnoff <glebius@freebsd.org>:
> On Tue, Apr 17, 2012 at 10:38:31AM +0200, Ermal Lu?i wrote:
> E> 2012/4/17 Gleb Smirnoff <glebius@freebsd.org>:

<removed some comments>

> E> >
> E> > In this case crash or freeze is fixed, but still packet is dropped. Example
> E> > of such rule:
> E> >
> E> > pass in on igb0 fastroute proto tcp from any to $localip
> E> >
> E> > Anyway, dropping packets is much better than crashing.
> E> >
> E>
> E> Actually after some coffee :) i think its better marking the packet
> E> with M_SKIP_FIREWALL since
> E> it has already taken its decision on this packet.
> E>
> E> The simloop consumers seem to be just facilities of how things work
> E> from what i can see.
> E>
> E> So just delivering the packet by sending skipping the firewalls seems
> E> more sensibile!
> E>
> E> Though the persistent case for the tags should be revisited since it
> E> may fix some other issues with pf(4) tags, and some others.
>
> We can make the assignment like:
>
> if (ifp->if_flags & IFF_LOOPBACK)
> ? ? ? ?m->m_flags |= M_SKIP_FIREWALL;

Yeah the protection seems sensible enough, probably needs some more
testing first.
I will try to do some asap.

The issue is that pf(4) with state keeping is not designed to see a
looping packet.
Also the pf(4) route-to/reply-to logic is not meant to loop packet
back but deliver them to final configured destination.
Hence the skip firewall.

The only problem i might see is when running more than one firewall
together but still there are other issues when you do that at pfil(9)
level.
Also, if_simloop is not meant for packet leaving the host so that
should be safe no?

>
> Because only loopback interface is special: processing its ifp->if_output()
> leads to re-entering ip_input().
>
> I'm afraid that if we mark all pf-routed packets as M_SKIP_FIREWALL, that
> can lead to a case when packet is routed by pf processing on input hook, and
> then it skips processing the output hook, and that can lead to state
> not being updated and session stuck.
>
> Still, I think that pf tag deserves MTAG_PERSISTENT. That would keep us
> in-line with OpenBSD, since they store pf information right in the pkthdr,
> and I don't think that they erase it anywhere until mbuf is freed.

Do agree

>
> --
> Totus tuus, Glebius.



-- 
Ermal
From glebius at FreeBSD.org  Tue Apr 17 09:48:27 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Tue Apr 17 09:48:33 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <CAPBZQG0ujzB+7xTFpvhjRVbrtBEeABXHeKDx-WjbSOaAWX0-sA@mail.gmail.com>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
	<20120417084608.GA99119@glebius.int.ru>
	<CAPBZQG0ujzB+7xTFpvhjRVbrtBEeABXHeKDx-WjbSOaAWX0-sA@mail.gmail.com>
Message-ID: <20120417094825.GC99119@glebius.int.ru>

  Replying on only on paragrapg, everything else agreed.

On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote:
E> The only problem i might see is when running more than one firewall
E> together but still there are other issues when you do that at pfil(9)
E> level.

Well, playing with two firewalls was never safe and clear, there always
be edge cases in such setups.

E> Also, if_simloop is not meant for packet leaving the host so that
E> should be safe no?

Shouldn't live, but it still enters pfil(9) and there one or other
firewall can again bounce it in any direction. Probable M_SKIP_FIREWALL
is good idea.

-- 
Totus tuus, Glebius.
From glebius at FreeBSD.org  Tue Apr 17 14:02:07 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Tue Apr 17 14:02:13 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <20120417084608.GA99119@glebius.int.ru>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
	<20120417084608.GA99119@glebius.int.ru>
Message-ID: <20120417140205.GA2140@glebius.int.ru>

On Tue, Apr 17, 2012 at 12:46:08PM +0400, Gleb Smirnoff wrote:
T> We can make the assignment like:
T> 
T> if (ifp->if_flags & IFF_LOOPBACK)
T> 	m->m_flags |= M_SKIP_FIREWALL;

I've tested this plus MTAG_PERSISTENT on pf tags, and it looks like this
works.

At least for the "fastroute" case, which was defnitely not working before.

-- 
Totus tuus, Glebius.
From bzeeb-lists at lists.zabbadoz.net  Tue Apr 17 16:32:36 2012
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Tue Apr 17 16:32:44 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules
	when first matching packet arrives
In-Reply-To: <20120417094825.GC99119@glebius.int.ru>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
	<20120417084608.GA99119@glebius.int.ru>
	<CAPBZQG0ujzB+7xTFpvhjRVbrtBEeABXHeKDx-WjbSOaAWX0-sA@mail.gmail.com>
	<20120417094825.GC99119@glebius.int.ru>
Message-ID: <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net>


On 17. Apr 2012, at 09:48 , Gleb Smirnoff wrote:

>  Replying on only on paragrapg, everything else agreed.
> 
> On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote:
> E> The only problem i might see is when running more than one firewall
> E> together but still there are other issues when you do that at pfil(9)
> E> level.
> 
> Well, playing with two firewalls was never safe and clear, there always
> be edge cases in such setups.

A lot of people have used ipfw to filter L2 MAC addresses etc and pf for everything else in the past.  So certainly is not an edge case.

-- 
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!

From glebius at FreeBSD.org  Tue Apr 17 16:33:36 2012
From: glebius at FreeBSD.org (Gleb Smirnoff)
Date: Tue Apr 17 16:33:43 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
	<20120417084608.GA99119@glebius.int.ru>
	<CAPBZQG0ujzB+7xTFpvhjRVbrtBEeABXHeKDx-WjbSOaAWX0-sA@mail.gmail.com>
	<20120417094825.GC99119@glebius.int.ru>
	<5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net>
Message-ID: <20120417163334.GB2140@glebius.int.ru>

On Tue, Apr 17, 2012 at 04:32:31PM +0000, Bjoern A. Zeeb wrote:
B> > On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote:
B> > E> The only problem i might see is when running more than one firewall
B> > E> together but still there are other issues when you do that at pfil(9)
B> > E> level.
B> > 
B> > Well, playing with two firewalls was never safe and clear, there always
B> > be edge cases in such setups.
B> 
B> A lot of people have used ipfw to filter L2 MAC addresses etc and pf for everything else in the past.  So certainly is not an edge case.

Enabling two firewalls isn't an edge case, but when two firewalls enabled
there are numerouse possibilities to do evil misconfigurations.

-- 
Totus tuus, Glebius.
From eri at freebsd.org  Tue Apr 17 19:19:51 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Tue Apr 17 19:20:00 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
	<20120417084608.GA99119@glebius.int.ru>
	<CAPBZQG0ujzB+7xTFpvhjRVbrtBEeABXHeKDx-WjbSOaAWX0-sA@mail.gmail.com>
	<20120417094825.GC99119@glebius.int.ru>
	<5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net>
Message-ID: <CAPBZQG1od1DJZi15oKQUO40R4SghoDv+QjEdK=+f8C92KZ5=gg@mail.gmail.com>

On Tue, Apr 17, 2012 at 6:32 PM, Bjoern A. Zeeb
<bzeeb-lists@lists.zabbadoz.net> wrote:
>
> On 17. Apr 2012, at 09:48 , Gleb Smirnoff wrote:
>
>> ?Replying on only on paragrapg, everything else agreed.
>>
>> On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote:
>> E> The only problem i might see is when running more than one firewall
>> E> together but still there are other issues when you do that at pfil(9)
>> E> level.
>>
>> Well, playing with two firewalls was never safe and clear, there always
>> be edge cases in such setups.
>
> A lot of people have used ipfw to filter L2 MAC addresses etc and pf for everything else in the past. ?So certainly is not an edge case.

I know that since pfSense uses that extenively.
But this does not break this case.
It only affects packets going back at ip level.

with ipfw you cannot filter L2 MAC on pfil(9) level AFAIR.

>
> --
> Bjoern A. Zeeb ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? You have to have visions!
> ? It does not matter how good you are. It matters what good you do!
>



-- 
Ermal
From eri at freebsd.org  Tue Apr 17 19:21:28 2012
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Tue Apr 17 19:21:34 2012
Subject: kern/164402: [pf] pf crashes with a particular set of rules when
 first matching packet arrives
In-Reply-To: <20120417140205.GA2140@glebius.int.ru>
References: <201204151200.q3FC0LT5085161@freefall.freebsd.org>
	<20120416185949.GC92286@FreeBSD.org>
	<CAPBZQG2Tjg36GNCBetRZ20FhQnL1sK9i_-oQDDb97bcb4N=sLA@mail.gmail.com>
	<20120417081406.GA93887@glebius.int.ru>
	<CAPBZQG2gF8GSx6eE4jkFuOf29c-jB09Gz6=+kbpXprN8XiEE4w@mail.gmail.com>
	<20120417084608.GA99119@glebius.int.ru>
	<20120417140205.GA2140@glebius.int.ru>
Message-ID: <CAPBZQG3i6i-nxS2+ZEr=WbO+wHHLYqHjC2EtrFz8vM6qZmH95g@mail.gmail.com>

2012/4/17 Gleb Smirnoff <glebius@freebsd.org>:
> On Tue, Apr 17, 2012 at 12:46:08PM +0400, Gleb Smirnoff wrote:
> T> We can make the assignment like:
> T>
> T> if (ifp->if_flags & IFF_LOOPBACK)
> T> ? ? ?m->m_flags |= M_SKIP_FIREWALL;
>
> I've tested this plus MTAG_PERSISTENT on pf tags, and it looks like this
> works.
>
> At least for the "fastroute" case, which was defnitely not working before.
>

fastroute has been never of any good use if you asked me.
Though you can test reply-to quite easily the same you do with fastroute.

This fix should fix another tickets which reported massive storms of icmp
on lo0 as well. I have to find out the PR# though to merge it with this.

> --
> Totus tuus, Glebius.



-- 
Ermal
From zacisco at gmail.com  Thu Apr 19 06:54:40 2012
From: zacisco at gmail.com (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0J/QvtC60YDQvtCy0YHQutC40Lk=?=)
Date: Thu Apr 19 06:54:46 2012
Subject: PF NAT don't work
Message-ID: <CAG0vsXUwB6PjQLDbHQoM5wrrym63r+qn2M8bMm9JZeNPS1MvmA@mail.gmail.com>

hello
when you can fix problem with PF nat rules (they didn't work)
don't check on earlier versions FreeBSD,but on 9.0 not work
this function very very need
thx

i have two eth
eth0 - external
eth1 - internal
in pf.conf:
nat on $ext_if proto udp from $vpn_ip port 1194 to any -> $ext_ip port 2000
rdr on $ext_if proto udp from any to $ext_ip port 2000 -> $vpn_ip port 1194

rdr is work
nat didn't

vpnclient sent packets from internet to $vpn_ip,but not recieve
it was 1st ...

2nd:
and i have TeamSpeak 3 Server also
if policy set block all then TS3 Server can't run (some connect?)
i opened this ports:
http://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/44/16/which-ports-does-the-teamspeak-3-server-use
http://forum.configserver.com/viewtopic.php?f=6&t=4881
but i have still this problem
if policy set pass all then it will be work
i can run: pass all > TS3 > block all
but then TS3 was can't check license

can you help me?
thx
From andriy at irbisnet.com  Fri Apr 20 01:11:09 2012
From: andriy at irbisnet.com (Andriy Bakay)
Date: Fri Apr 20 01:11:17 2012
Subject: PF NAT don't work
In-Reply-To: <CAG0vsXUwB6PjQLDbHQoM5wrrym63r+qn2M8bMm9JZeNPS1MvmA@mail.gmail.com>
References: <CAG0vsXUwB6PjQLDbHQoM5wrrym63r+qn2M8bMm9JZeNPS1MvmA@mail.gmail.com>
Message-ID: <F98FCE1D-396A-4AD9-A946-76E0B3A6F648@irbisnet.com>


On 2012-04-19, at 02:54 , ?????????? ?????????? wrote:

> hello
> when you can fix problem with PF nat rules (they didn't work)
> don't check on earlier versions FreeBSD,but on 9.0 not work
> this function very very need
> thx
> 
> i have two eth
> eth0 - external
> eth1 - internal
> in pf.conf:
> nat on $ext_if proto udp from $vpn_ip port 1194 to any -> $ext_ip port 2000
> rdr on $ext_if proto udp from any to $ext_ip port 2000 -> $vpn_ip port 1194
> 

I am not sure about '$ext_ip port 2000' condition in your NAT rule. Are you using any proxy? Why do you need to explicitly specify outgoing port? Make sure you have 'pass' rules for your RDR and NAT. Could you provide more info about you VPN setup?

As a general recommendation, you can always "debug" you ruleset with 'tcpdump' utility, for example:

$ sudo tcpdump -ttttnpei pflog0 <you_extra_filter>

Or you can use 'pftop' from ports.

> rdr is work
> nat didn't
> 
> vpnclient sent packets from internet to $vpn_ip,but not recieve
> it was 1st ...
> 
> 2nd:
> and i have TeamSpeak 3 Server also
> if policy set block all then TS3 Server can't run (some connect?)
> i opened this ports:
> http://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/44/16/which-ports-does-the-teamspeak-3-server-use
> http://forum.configserver.com/viewtopic.php?f=6&t=4881
> but i have still this problem
> if policy set pass all then it will be work
> i can run: pass all > TS3 > block all
> but then TS3 was can't check license
> 
> can you help me?
> thx
> _______________________________________________
> 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"

From linimon at FreeBSD.org  Mon Apr 23 03:07:04 2012
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Mon Apr 23 03:07:16 2012
Subject: kern/167057: [pf] PF firewall version 4.5 in FreeBSD 9.0 & 8.2
	nolonger supported by upstream
Message-ID: <201204230307.q3N373NQ065767@freefall.freebsd.org>

Old Synopsis: PF firewall version 4.5 in FreeBSD 9.0 & 8.2 nolonger supported
New Synopsis: [pf] PF firewall version 4.5 in FreeBSD 9.0 & 8.2 nolonger supported by upstream

State-Changed-From-To: open->suspended
State-Changed-By: linimon
State-Changed-When: Mon Apr 23 03:03:28 UTC 2012
State-Changed-Why: 
The problem is that the upstream changes seriously break backwards
compatibility.  My understanding is that for now we are staying with
the existing version so as not to create a problem for our users, via
POLA.  I don't know if this decision will be revisited for 10.0.

In any case, 8.3 is already released, so the first part of this PR
is moot.


Responsible-Changed-From-To: freebsd-bugs->freebsd-pf
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Apr 23 03:03:28 UTC 2012
Responsible-Changed-Why: 

http://www.freebsd.org/cgi/query-pr.cgi?pr=167057
From bugmaster at FreeBSD.org  Mon Apr 23 11:07:22 2012
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 23 11:09:11 2012
Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org
Message-ID: <201204231107.q3NB7LtI047661@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
s kern/167057  pf         [pf] PF firewall version 4.5 in FreeBSD 9.0 & 8.2 nolo
o kern/166336  pf         [pf] kern.securelevel 3 +pf reload
o kern/165315  pf         [pf] States never cleared in PF with DEVICE_POLLING
o kern/164402  pf         [pf] pf crashes with a particular set of rules when fi
o kern/164271  pf         [pf] not working pf nat on FreeBSD 9.0 [regression]
o kern/163208  pf         [pf] PF state key linking mismatch
o kern/160370  pf         [pf] Incorrect pfctl check of pf.conf
o kern/155736  pf         [pf] [altq] borrow from parent queue does not work wit
o kern/153307  pf         [pf] Bug with PF firewall
o kern/148290  pf         [pf] "sticky-address" option of Packet Filter (PF) blo
o kern/148260  pf         [pf] [patch] pf rdr incompatible with dummynet
o kern/147789  pf         [pf] Firewall PF no longer drops connections by sendin
o kern/143543  pf         [pf] [panic] PF route-to causes kernel panic
o bin/143504   pf         [patch] outgoing states are not killed by authpf(8)
o conf/142961  pf         [pf] No way to adjust pidfile in pflogd
o conf/142817  pf         [patch] etc/rc.d/pf: silence pfctl
o kern/141905  pf         [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697  pf         [pf] pf behaviour changes - must be documented
o kern/137982  pf         [pf] when pf can hit state limits, random IP failures 
o kern/136781  pf         [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948  pf         [pf] [gre] pf not natting gre protocol
o kern/135162  pf         [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996  pf         [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732  pf         [pf] max-src-conn issue
o kern/132769  pf         [pf] [lor] 2 LOR's with pf task mtx / ifnet and  rtent
f kern/132176  pf         [pf] pf stalls connection when using route-to [regress
o conf/130381  pf         [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861  pf         [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920  pf         [pf] ipv6 and synproxy don't play well together
o conf/127814  pf         [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439  pf         [pf] deadlock in pf
o kern/127121  pf         [pf] [patch] pf incorrect log priority
o kern/127042  pf         [pf] [patch] pf recursion panic if interface group is 
o kern/125467  pf         [pf] pf keep state bug while handling sessions between
s kern/124933  pf         [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364  pf         [pf] [panic] Kernel panic with pf + bridge
o kern/122773  pf         [pf] pf doesn't log uid or pid when configured to
o kern/122014  pf         [pf] [panic] FreeBSD 6.2 panic in pf
o kern/120281  pf         [pf] [request] lost returning packets to PF for a rdr 
o kern/120057  pf         [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355   pf         [pf] [patch] pfctl(8) help message options order false
o kern/114567  pf         [pf] [lor] pf_ioctl.c + if.c
s conf/110838  pf         [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283  pf         pfsync fails to sucessfully transfer some sessions
o kern/103281  pf         pfsync reports bulk update failures
o kern/93825   pf         [pf] pf reply-to doesn't work
o sparc/93530  pf         [pf] Incorrect checksums when using pf's route-to on s
o kern/92949   pf         [pf] PF + ALTQ problems with latency
o bin/86635    pf         [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271   pf         [pf] cbq scheduler cause bad latency

50 problems total.

From Email at Cover-My-Life.co.za  Thu Apr 26 09:30:35 2012
From: Email at Cover-My-Life.co.za (Cover-My-Life.co.za)
Date: Thu Apr 26 09:30:43 2012
Subject: FREEBSD PF,
 Get R3M in Life Cover for under R10 per day (No Medicals) -
 Cover-My-Life.co.za
Message-ID: <25F85D91-3293-4EAD-BB47-A22EF1607745@Sender>

Hi FREEBSD PF,

Let's face facts - One day you (and I) will die.  Maybe we will see it coming.  Maybe we won't.

BUT, have you considered what will happen to your family if you were to pass away?

-Do you have a will and is it up-to-date?
-Do you have loans (like a home loan) or credit that would need to be paid off?
-Will your loved ones be able to live comfortably without your income?
-Do have enough cash sitting in the bank to cover an unforeseen funeral?

No one likes to think about this stuff but frankly we must.  And if you have read this far, you are probably just as concerned about these issues as you should be.

Well not to worry, here is the good news: Cover-My-Life.co.za is here to help!  Not only have we made the process of getting the right Life Cover for you as simple as a few clicks but we have also sourced some of the best deals in the market.

As an example a 35 year old South African female can get R3 Million Life Cover for under R10 per day!

So why not try us out and get a quote for one of the following products we have available:

Life Insurance - Get upto R6M cover (no medical); Quote in minutes; Save upto 50%
Disability Insurance - Cover for if you become disabled (eg From an accident)
Salary Protection - Cover for if you are unable to earn an income (eg Retrenchment, Injury etc)
Critical Illness Cover - Cover for if you become critically ill (eg Cancer)
Cover for HIV - Life Cover for those suffering from HIV
FREE Financial Plan - Let us provide you with a Financial Plan absolutely FREE

This takes all the hassle and hard work out of finding the best insurance for you and what?s more, you can do it from the privacy of your own home / office / wherever you are reading this.

Give us a try, go to www.Cover-My-Life.co.za, or apply now

Thanks

The Cover-My-Life.co.za team

 



Our Services include:
1) Online automated quote management process
2) Step by step guidance and advice from professionally trained staff
3) Best quote provided usually within the same day based on your personal circumstance
4) Totally secure application process using SSL Encryption


Email sent by SA Consumer Foundation 
SA Consumer Foundation | 120 1st Avenue | Hyde Park, JHB, Gauteng 2196
2012 SA Consumer Foundation All Rights Reserved.

If you did not wish to receive this, please unsubscribe from further emails  at http://www.formstack.com/forms/sa-emailunsubscribe?email=freebsd-pf@freebsd.org

If you consider this email unsolicited bulk mail, please report SPAM at http://www.formstack.com/forms/sa-reportspam?email=freebsd-pf@freebsd.org&email_from=Email@Cover-My-Life.co.za
From john at ellissey.co.za  Thu Apr 26 13:05:05 2012
From: john at ellissey.co.za (John Viljoen)
Date: Thu Apr 26 13:05:14 2012
Subject: Drive A New Car from R499 P/M
Message-ID: <000001cd23a9$7da01220$78e03660$@ellissey.co.za>

Hi

Im interested in this deal, whats the catch?

 

 

Kind Regards

 

John Viljoen

Technical Manager

Ellissey Technologies (CC)

Description: Description: Description: cid:image007.jpg@01CBBD60.37541B00
+27 (0)83 669 1693  Description: Description: Description:
cid:image008.jpg@01CBBD60.37541B00 +27 (0)86 661 6079

Description: Description: Description: Description:
cid:image004.gif@01C90438.14754840    <http://www.ellissey.com/>
www.ellissey.com

Description: Description: Description: Description: Odyssey

This email and any accompanying attachments may contain confidential,
proprietary and copyright information. This information is private and
protected by law and, accordingly, if you are not the intended recipient,
you are requested to delete this entire communication immediately and are
notified that any disclosure, copying or distribution of or taking any
action based on this information is prohibited.

The entity which owns the domain from which this email originates, and its
subsidiaries do not accept liability for the views expressed in the email
(which may be the private views of the sender), or for the consequences of
any computer viruses that may be transmitted with this email. Emails cannot
be guaranteed to be secure or free of errors or viruses.  The sender does
not accept any liability or responsibility for any interception, corruption,
destruction, loss, late arrival or incompleteness of or tampering or
interference with any of the information contained in this email or for its
incorrect delivery or non- delivery for whatsoever reason or for its effect
on any electronic device of the recipient. If verification of this email or
any attachment is required, please request a hard-copy version from the
sender.

 

From bugmaster at FreeBSD.org  Mon Apr 30 11:07:38 2012
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 30 11:09:14 2012
Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org
Message-ID: <201204301107.q3UB7bjC053973@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
s kern/167057  pf         [pf] PF firewall version 4.5 in FreeBSD 9.0 & 8.2 nolo
o kern/166336  pf         [pf] kern.securelevel 3 +pf reload
o kern/165315  pf         [pf] States never cleared in PF with DEVICE_POLLING
o kern/164402  pf         [pf] pf crashes with a particular set of rules when fi
o kern/164271  pf         [pf] not working pf nat on FreeBSD 9.0 [regression]
o kern/163208  pf         [pf] PF state key linking mismatch
o kern/160370  pf         [pf] Incorrect pfctl check of pf.conf
o kern/155736  pf         [pf] [altq] borrow from parent queue does not work wit
o kern/153307  pf         [pf] Bug with PF firewall
o kern/148290  pf         [pf] "sticky-address" option of Packet Filter (PF) blo
o kern/148260  pf         [pf] [patch] pf rdr incompatible with dummynet
o kern/147789  pf         [pf] Firewall PF no longer drops connections by sendin
o kern/143543  pf         [pf] [panic] PF route-to causes kernel panic
o bin/143504   pf         [patch] outgoing states are not killed by authpf(8)
o conf/142961  pf         [pf] No way to adjust pidfile in pflogd
o conf/142817  pf         [patch] etc/rc.d/pf: silence pfctl
o kern/141905  pf         [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697  pf         [pf] pf behaviour changes - must be documented
o kern/137982  pf         [pf] when pf can hit state limits, random IP failures 
o kern/136781  pf         [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948  pf         [pf] [gre] pf not natting gre protocol
o kern/135162  pf         [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996  pf         [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732  pf         [pf] max-src-conn issue
o kern/132769  pf         [pf] [lor] 2 LOR's with pf task mtx / ifnet and  rtent
f kern/132176  pf         [pf] pf stalls connection when using route-to [regress
o conf/130381  pf         [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861  pf         [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920  pf         [pf] ipv6 and synproxy don't play well together
o conf/127814  pf         [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439  pf         [pf] deadlock in pf
o kern/127121  pf         [pf] [patch] pf incorrect log priority
o kern/127042  pf         [pf] [patch] pf recursion panic if interface group is 
o kern/125467  pf         [pf] pf keep state bug while handling sessions between
s kern/124933  pf         [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364  pf         [pf] [panic] Kernel panic with pf + bridge
o kern/122773  pf         [pf] pf doesn't log uid or pid when configured to
o kern/122014  pf         [pf] [panic] FreeBSD 6.2 panic in pf
o kern/120281  pf         [pf] [request] lost returning packets to PF for a rdr 
o kern/120057  pf         [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355   pf         [pf] [patch] pfctl(8) help message options order false
o kern/114567  pf         [pf] [lor] pf_ioctl.c + if.c
s conf/110838  pf         [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283  pf         pfsync fails to sucessfully transfer some sessions
o kern/103281  pf         pfsync reports bulk update failures
o kern/93825   pf         [pf] pf reply-to doesn't work
o sparc/93530  pf         [pf] Incorrect checksums when using pf's route-to on s
o kern/92949   pf         [pf] PF + ALTQ problems with latency
o bin/86635    pf         [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271   pf         [pf] cbq scheduler cause bad latency

50 problems total.