Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-pf Digest, Vol 278, Issue 1

14 views

Skip to first unread message

freebsd-p...@freebsd.org

unread,

Mar 18, 2010, 12:39:45 PM3/18/10

to freeb...@freebsd.org

Send freebsd-pf mailing list submissions to
freeb...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
or, via email, send a message with subject or body 'help' to
freebsd-p...@freebsd.org

You can reach the person managing the list at
freebsd-...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-pf digest..."

Today's Topics:

1. Re: Network simulation using jails & vimage (Ermal Lu?i)
2. Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs
when using pf(4) 'reply-to' (lin...@FreeBSD.org)
3. a transmit problem with pf (Yavuz Ma?lak)
4. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
5. FIN packets blocked (Olivier Thibault)
6. Re: Network simulation using jails & vimage (j...@sifferle.net)
7. Re: Network simulation using jails & vimage (Julian Elischer)
8. Re: Network simulation using jails & vimage (j...@sifferle.net)
9. Re: Network simulation using jails & vimage (Jim Sifferle)
10. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
11. Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
(Nick Leuta)
12. Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
(?????????)
13. Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
(Nick Leuta)
14. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
15. PF + BRIDGE + PFSYNC causes system freezing (kevin)
16. Re: PF + BRIDGE + PFSYNC causes system freezing (Daniel Hartmeier)
17. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
18. RE: PF + BRIDGE + PFSYNC causes system freezing (kevin)
19. RE: PF + BRIDGE + PFSYNC causes system freezing (kevin)
20. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
21. RE: PF + BRIDGE + PFSYNC causes system freezing (Greg Hennessy)
22. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
23. Re: PF + BRIDGE + PFSYNC causes system freezing (Max Laier)
24. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
25. Re: PF + BRIDGE + PFSYNC causes system freezing (Max Laier)
26. Re: PF + BRIDGE + PFSYNC causes system freezing (Greg Hennessy)
27. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)
28. Re: PF + BRIDGE + PFSYNC causes system freezing (Max Laier)
29. Synproxy state - advertising 0 window size (pawe...@gmail.com)
30. Re: PF + BRIDGE + PFSYNC causes system freezing (Giulio Ferro)

----------------------------------------------------------------------

Message: 1
Date: Tue, 23 Feb 2010 11:11:03 +0100
From: Ermal Lu?i <e...@freebsd.org>
Subject: Re: Network simulation using jails & vimage
To: Julian Elischer <jul...@elischer.org>
Cc: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>, Jim Sifferle
<j...@sifferle.net>, FreeBSD virtualization mailing list
<freebsd-vir...@freebsd.org>, p...@freebsd.org
Message-ID:
<9a542da31002230211k2fb...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 21, 2010 at 6:14 PM, Julian Elischer <jul...@elischer.org>wrote:

> Bjoern A. Zeeb wrote:
>
>> On Sun, 21 Feb 2010, Julian Elischer wrote:
>>
>> Hi,
>>
>> Jim Sifferle wrote:
>>>
>>>> Hi,
>>>>
>>>> I've used ipfw and Dummynet as well as ipfw + DSCP recognition patch and
>>>> pf/altq to simulate Internet and MPLS WAN environments for several
>>>> years. All of my setups have run under VMWare, which for many reasons
>>>> isn't ideal. I would like to collapse all of these VMs into one FreeBSD
>>>> box using jails and vimages.
>>>>
>>>> Does any FreeBSD branch / vimage release combination support separate pf
>>>> AND ipfw configurations per jail? I need ipfw+pf/altq for HFSC queuing
>>>> to simulate the queueing effects of MPLS provider edge and core
>>>> routers.
>>>>
>>>
>>> -current (9) should be close, with patches for pf supplied by ceri.
>>>
>>
>> s,ceri,eri, (Ermal Luçi)
>>
>
> err yeah..
>
> it'd be nice if itcould get committed
>
> Ermal, is it ready?
>
>
It is usable look at http://svn.freebsd.org/base/user/eri/pf45/head/.
For vnet pfsync/pflow/pflog needs some fixes still.

>
>
>>
>> 8 can do separate ipfw but pf is not changed.
>>> 9 has bugs fixed. but I'm not sure if the changes for pf went in..
>>> they do exis tif they are not in already.
>>>
>>
>> No, pf hasn't gone in yet; it lives in user/eri/pf45/ in svn and I am
>> not sure what the plans are.
>>
>> Apart from the latest changes 8 and 9 should be pretty much in sync
>> wrt to VIMAGE I think.
>>
>>
>> I'm hoping the latest 7.2-STABLE-201001 snapshot will work. The DSCP
>>>> recognition patch for ipfw that I rely on doesn't seem to work with
>>>> 8.0. If 7.2 won't work for my needs, but 8 or 9-CURRENT will, is anyone
>>>> aware
>>>> of an updated ipfw DSCP patch? I haven't seen anything on Google or the
>>>> freebsd-ipfw mailing list.
>>>>
>>>
>>> what is DSCP?
>>>
>>
>> I guess Differentiated Services CodePoint (if talking MPLS).
>>
>>
>> /bz
>>
>>
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>

--
Ermal

------------------------------

Message: 2
Date: Fri, 26 Feb 2010 11:23:53 GMT
From: lin...@FreeBSD.org
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs
when using pf(4) 'reply-to'
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201002261123....@freefall.freebsd.org>

Old Synopsis: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
New Synopsis: [pf] [icmp] massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'

Responsible-Changed-From-To: freebsd-bugs->freebsd-pf
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Feb 26 11:23:27 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=144311

------------------------------

Message: 3
Date: Fri, 26 Feb 2010 18:39:10 +0200
From: Yavuz Ma?lak <yavuz....@netiletisim.net>
Subject: a transmit problem with pf
To: <freeb...@freebsd.org>
Message-ID: <112F6287D4FF4F00BC460F8E7D0B71C3@desktop2002>
Content-Type: text/plain; format=flowed; charset="iso-8859-9";
reply-type=original

I have 2 leasedlines to reach to the internet.

I use 2 routers for these leasedlines. One of them is a freebsd7.2.

I activated pf on freebsd7.2.

I have a fileserver which has a real ip.
the fileserver's default gateway is other gateway server.
When a traffic comes from internet via freebsd gateway towards the
fileserver, if I try to upload a file which has about 10Mbyte from a remote
pc to the file server, file transfer performance will be very bad. if I try
to download a file from the file server, the file transfer performance will
be very well. it is no problem.
Or if I disable the pf, the problem will be finish and upload/download
transfer speed
is very well.

Or incoming and outgoing traffic via my pf server , there is no problem.
on pf.conf, all packets are set as pass;
pass in all
pass out all
How can I sort this problem out ?

------------------------------

Message: 4
Date: Mon, 1 Mar 2010 11:07:06 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201003011107....@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/144311 pf [pf] [icmp] massive ICMP storm on lo0 occurs when usin
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
f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression]
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/121704 pf [pf] PF mangles loopback packets
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
o kern/114095 pf [carp] carp+pf delay with high state limit
o kern/111220 pf [pf] repeatable hangs while manipulating pf tables
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

43 problems total.

------------------------------

Message: 5
Date: Tue, 02 Mar 2010 17:33:50 +0100
From: Olivier Thibault <Olivier....@lmpt.univ-tours.fr>
Subject: FIN packets blocked
To: freeb...@freebsd.org
Message-ID: <4B8D3DE...@lmpt.univ-tours.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello,

I have a web server with apache+modproxy running FreeBSD 7.2-RELEASE-p7.
I filter incoming and outgoing traffic with pf.
I have some packets (about 20 per day) which are blocked and I don't understand why.
My config is :
Internet -> ServerA(modproxy) -> ServerB(apache).

Here is the log for one blocked packet :
2010-03-02 15:40:29.573890 rule 7/0(match): block out on le0: serverA.62228 >
serverB.80: F 3525425568:3525425568(0) ack 459935989 win 8326 <nop,nop,timestamp
9801116 1193432194>

All logs are similar.

Rule 7 is :
block return out log all

I have a rule allowing the traffic towards serverB :
pass out quick on le0 inet proto tcp from serverA to serverB port = http

As the packet has the FIN flag, I change this rule to :
pass out quick on le0 inet proto tcp from serverA to serverB port = http flags
S/SA keep state (if-bound, tcp.finwait 90)

but it doesn't change anything.

I used tcpdump to dump all traffic between the 2 servers, and the conversation
outgoing from port 62228 (shown in the log of the blocked packet) ended at
15h22, and the packet is block at 15h40.

I guess there is something I mis-understood, but I don't know what.

Could you help me understand ?

Best regards,

--
Olivier THIBAULT
Université François Rabelais - UFR Sciences et Techniques
Laboratoire de Mathématiques et Physique Théorique (UMR CNRS 6083)
Service Informatique de l'UFR
Parc de Grandmont
37200 Tours - France
Email: olivier.thibault at lmpt.univ-tours.fr
Tel: (33)(0)2 47 36 69 12
Fax: (33)(0)2 47 36 70 68
Mobile : (33)(0)6 62 60 80 44

------------------------------

Message: 6
Date: Fri, 5 Mar 2010 14:16:00 -0500 (EST)
From: "j...@sifferle.net" <j...@sifferle.net>
Subject: Re: Network simulation using jails & vimage
To: Julian Elischer <jul...@elischer.org>, "Ermal Lu?i"
<e...@freebsd.org>
Cc: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>, FreeBSD
virtualization mailing list <freebsd-vir...@freebsd.org>,
p...@freebsd.org
Message-ID:
<900375163.294375.126781656...@oxusltgw09.schlund.de>

Content-Type: text/plain; charset=UTF-8

On February 23, 2010 at 10:11 AM "Ermal LuÃ§i" <e...@freebsd.org> wrote:

> On Sun, Feb 21, 2010 at 6:14 PM, Julian Elischer <jul...@elischer.org>wrote:
>
> > Bjoern A. Zeeb wrote:
> >
> >> On Sun, 21 Feb 2010, Julian Elischer wrote:
> >>
> >> Hi,
> >>
> >>Â Jim Sifferle wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Does any FreeBSD branch / vimage release combination support separate pf
> >>>> AND ipfw configurations per jail?Â I need ipfw+pf/altq for HFSC queuing
> >>>
> >>> -current (9) should be close, with patches for pf supplied by ceri.
> >>
> >> s,ceri,eri,Â (Ermal LuÃ§i)
> >
> > it'd be nice if itcould get committed
> >
> > Ermal, is it ready?
> >
> It is usable look at http://svn.freebsd.org/base/user/eri/pf45/head/.
> For vnet pfsync/pflow/pflog needs some fixes still.
>
I just now had some time to put together a CURRENT box for testing.Â I'm getting
a 'Fatal trap 12: page fault while in kernel mode' whenever I boot with
pf_enable set to YES in rc.conf.Â Here's my current setup:
Â
- FreeBSD CURRENT cvs snapshot as of 2/25/10, running AMD64 kernel
- GENERIC kernel compiled with ALTQ and VIMAGE options,Â invariants and witness
options disabled, plus Imunes patch for FreeBSDÂ 8 RC3Â available here:
http://imunes.net/imunes-8.0-RC3.diff
- pf loaded as module with very simple pass all pf.conf
- ipfw not loaded
Â
The Fatal trap seems to occur when pfctl is run.
Â
I am recompiling my kernel with all debugging options turned on.Â Hopefully I
can get a good kernel dump.Â I will also try with fresh kernel sources skipping
the Imunes patch.Â Anything else I should try?
Â
Thanks for your help,
Â
Jim

------------------------------

Message: 7
Date: Fri, 05 Mar 2010 11:34:13 -0800
From: Julian Elischer <jul...@elischer.org>
Subject: Re: Network simulation using jails & vimage
To: "j...@sifferle.net" <j...@sifferle.net>
Cc: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>, FreeBSD
virtualization mailing list <freebsd-vir...@freebsd.org>,
p...@freebsd.org
Message-ID: <4B915CB5...@elischer.org>
Content-Type: text/plain; charset=UTF-8; format=flowed

j...@sifferle.net wrote:
>
> On February 23, 2010 at 10:11 AM "Ermal LuÃ§i" <e...@freebsd.org> wrote:
>
> > On Sun, Feb 21, 2010 at 6:14 PM, Julian Elischer
> <jul...@elischer.org>wrote:
> >
> > > Bjoern A. Zeeb wrote:
> > >
> > >> On Sun, 21 Feb 2010, Julian Elischer wrote:
> > >>
> > >> Hi,
> > >>
> > >> Jim Sifferle wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> Does any FreeBSD branch / vimage release combination support
> separate pf
> > >>>> AND ipfw configurations per jail? I need ipfw+pf/altq for HFSC
> queuing
> > >>>
> > >>> -current (9) should be close, with patches for pf supplied by ceri.
> > >>
> > >> s,ceri,eri, (Ermal LuÃ§i)
> > >
> > > it'd be nice if itcould get committed
> > >
> > > Ermal, is it ready?
> > >
> > It is usable look at http://svn.freebsd.org/base/user/eri/pf45/head/.
> > For vnet pfsync/pflow/pflog needs some fixes still.
> >
>
> I just now had some time to put together a CURRENT box for testing. I'm
> getting a 'Fatal trap 12: page fault while in kernel mode' whenever I
> boot with pf_enable set to YES in rc.conf. Here's my current setup:
>
>
>
> - FreeBSD CURRENT cvs snapshot as of 2/25/10, running AMD64 kernel
>
> - GENERIC kernel compiled with ALTQ and VIMAGE options, invariants and
> witness options disabled, plus Imunes patch for FreeBSD 8 RC3 available
> here: http://imunes.net/imunes-8.0-RC3.diff
>
> - pf loaded as module with very simple pass all pf.conf
>
> - ipfw not loaded
>
>
>
> The Fatal trap seems to occur when pfctl is run.

This is unfortunately one for Ermal, as I wouldn't know a pfctl
command if it came up and kicked me in the shins. :-)

We really should try get the new pf stuff into -current so that
it gets more testing.

>
> I am recompiling my kernel with all debugging options turned on.
> Hopefully I can get a good kernel dump. I will also try with fresh
> kernel sources skipping the Imunes patch. Anything else I should try?
>
>
>
> Thanks for your help,
>
>
>
> Jim
>

------------------------------

Message: 8
Date: Fri, 5 Mar 2010 15:15:36 -0500 (EST)
From: "j...@sifferle.net" <j...@sifferle.net>
Subject: Re: Network simulation using jails & vimage
To: Julian Elischer <jul...@elischer.org>
Cc: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>, FreeBSD
virtualization mailing list <freebsd-vir...@freebsd.org>,
p...@freebsd.org
Message-ID:
<477684154.296223.126782013...@oxusltgw09.schlund.de>

Content-Type: text/plain; charset=UTF-8

On March 5, 2010 at 7:34 PM Julian Elischer <jul...@elischer.org> wrote:

> j...@sifferle.net wrote:
> >
> > I just now had some time to put together a CURRENT box for testing.Â I'm
> > getting a 'Fatal trap 12: page fault while in kernel mode' whenever I
> > boot with pf_enable set to YES in rc.conf.Â Here's my current setup:
> >
>
> This is unfortunately one for Ermal, as I wouldn't know a pfctl
> command if it came up and kicked me in the shins.Â :-)
>
> We really should try get the new pf stuff into -current so that
> it gets more testing.
>
Thanks for your quick reply...
Â
I think my first problem is I didn't pull the sources from the folder Ermal
mentioned: http://svn.freebsd.org/base/user/eri/pf45/head/.Â
Â
I misunderstood and thought it had been put in CURRENT.Â I will download
theÂ correct
sources and try again.
Â
Regards,
Â
Jim
Â
Â

------------------------------

Message: 9
Date: Sat, 06 Mar 2010 00:04:34 -0800
From: Jim Sifferle <j...@sifferle.net>
Subject: Re: Network simulation using jails & vimage
To: Ermal Lu?i <e...@freebsd.org>, Julian Elischer
<jul...@elischer.org>
Cc: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>, FreeBSD
virtualization mailing list <freebsd-vir...@freebsd.org>,
p...@freebsd.org
Message-ID: <1267862674.29050.25.camel@localhost>
Content-Type: text/plain; charset="UTF-8"

On Fri, 2010-03-05 at 15:15 -0500, j...@sifferle.net wrote:
> On March 5, 2010 at 7:34 PM Julian Elischer <jul...@elischer.org> wrote:
>
> > j...@sifferle.net wrote:
> > >
> > > I just now had some time to put together a CURRENT box for testing. I'm
> > > getting a 'Fatal trap 12: page fault while in kernel mode' whenever I
> > > boot with pf_enable set to YES in rc.conf. Here's my current setup:
> > >
> >
> > This is unfortunately one for Ermal, as I wouldn't know a pfctl
> > command if it came up and kicked me in the shins. :-)
> >
> > We really should try get the new pf stuff into -current so that
> > it gets more testing.
> >
> Thanks for your quick reply...
>
> I think my first problem is I didn't pull the sources from the folder Ermal
> mentioned: http://svn.freebsd.org/base/user/eri/pf45/head/.
>
> I misunderstood and thought it had been put in CURRENT. I will download
> the correct
> sources and try again.
>

Hi Ermal,

Forgive my ignorance, but how would you recommend I build my system to
test the new pf code? Here's what I tried earlier today:

1) Start with a CURRENT system with sources from 2/25
2) Download the new sources from svn using the link you provided

na-lab-wan-3# svn info
Path: .
URL: http://svn.freebsd.org/base/user/eri/pf45/head
Repository Root: http://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 204768
Node Kind: directory
Schedule: normal
Last Changed Author: eri
Last Changed Rev: 204245
Last Changed Date: 2010-02-23 01:58:12 -0800 (Tue, 23 Feb 2010)

3) Build and install a new kernel with the updated sources. But, I
could not compile with ALTQ support enabled. Is ALTQ available yet with
the new pf, or is it still a work in progress like pflog and pfsync?

cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
<SNIP>
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c: In
function 'pf_begin_altq':
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:894:
error: 'altqs_inactive_open' undeclared (first use in this function)
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:894:
error: (Each undeclared identifier is reported only once
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:894:
error: for each function it appears in.)
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c: In
function 'pf_rollback_altq':
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:934:
error: 'altqs_inactive_open' undeclared (first use in this function)
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c: In
function 'pf_commit_altq':
/usr/src_new/head/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1024:
error: 'altqs_inactive_open' undeclared (first use in this function)
*** Error code 1
<SNIP>

4) Reboot, load pf module, attempt to run pfctl -f /etc/pf.conf with
this error:

No ALTQ support in kernel
ALTQ related functions disabled
pfctl: DIOCADDRULE: Operation not supported by device

5) Attempt to rebuild pfctl from /usr/src_new/sbin/pfctl to deal with
the 'Operation not supported by device' error. I get this error:

cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized
-Wstrict-prototypes
-I/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl -DENABLE_ALTQ
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
-c /usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c
cc1: warnings being treated as errors
In file included
from /usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:64:
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.h:119:
warning: 'struct pfsync_state_peer' declared inside parameter list
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.h:119:
warning: its scope is only this definition or declaration, which is
probably not what you want
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.h:120:
warning: 'struct pfsync_state' declared inside parameter list
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_clear_states':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:393: error:
'struct pfioc_state_kill' has no member named 'psk_killed'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_kill_src_nodes':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:532: error:
'struct pfioc_src_node_kill' has no member named 'psnk_killed'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:538: error:
'struct pfioc_src_node_kill' has no member named 'psnk_killed'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_net_kill_states':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:638: error:
'struct pfioc_state_kill' has no member named 'psk_killed'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:644: error:
'struct pfioc_state_kill' has no member named 'psk_killed'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_label_kill_states':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:670: error:
'struct pfioc_state_kill' has no member named 'psk_label'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:670: error:
'struct pfioc_state_kill' has no member named 'psk_label'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:671: error:
'struct pfioc_state_kill' has no member named 'psk_label'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:678: error:
'struct pfioc_state_kill' has no member named 'psk_killed'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_id_kill_states':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:695: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:695: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:696: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:696: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:697: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:698: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:703: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:708: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:708: error:
'struct pfioc_state_kill' has no member named 'psk_pfcmp'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:713: error:
'struct pfioc_state_kill' has no member named 'psk_killed'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_print_rule_counters':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:805: error:
'struct pf_rule' has no member named 'states_cur'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:810: error:
'struct pf_rule' has no member named 'states_tot'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_show_rules':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:922: error:
'struct pf_rule' has no member named 'states_tot'
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c: In function
'pfctl_show_states':
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:1087:
warning: assignment from incompatible pointer type
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:1088: error:
dereferencing pointer to incomplete type
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:1088: error:
increment of pointer to unknown structure
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:1088: error:
arithmetic on pointer to an incomplete type
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:1088:
warning: left-hand operand of comma expression has no effect
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:1089: error:
dereferencing pointer to incomplete type
/usr/src_new/head/sbin/pfctl/../../contrib/pf/pfctl/pfctl.c:1095:
warning: passing argument 1 of 'print_state' from incompatible pointer
type
*** Error code 1

Thanks for any help you can provide...

Jim

------------------------------

Message: 10
Date: Mon, 8 Mar 2010 11:07:02 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201003081107....@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.

43 problems total.

------------------------------

Message: 11
Date: Sun, 14 Mar 2010 00:50:03 GMT
From: Nick Leuta <sky...@mail.sc.ru>
Subject: Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
To: freeb...@FreeBSD.org
Message-ID: <201003140050....@freefall.freebsd.org>

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

From: Nick Leuta <sky...@mail.sc.ru>
To: bug-fo...@FreeBSD.org, sl...@aprec.ru
Cc:
Subject: Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
Date: Sun, 14 Mar 2010 03:34:50 +0300

I have the similar problem but in a bit different situation...

the rule is:
pass out quick route-to (vlan2 192.168.0.1) from 192.168.0.2 to any
where 192.168.0.2 is binded to the vlan2 interface. The default gateway
is 192.168.1.1 and is accessible through another interface.

The "ping -S 192.168.0.2 192.168.0.1" command is used for test purposes,
and (sic!) the 192.168.0.1 is unreachable (really down...).

Without that rule we have:

PING 192.168.0.1 (192.168.0.1) from 192.168.0.2: 56 data bytes
<some timeout there>
ping: sendto: Host is down
<this message is repeated until Ctrl-C is pressed>

With the rule we obtain the kernel panic (in "ping" process) instead of
the "ping: sendto: Host is down" message after the same timeout as in
the case without rule.

------------------------------

Message: 12
Date: Sun, 14 Mar 2010 16:20:09 GMT
From: ????????? <sl...@aprec.ru>
Subject: Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
To: freeb...@FreeBSD.org
Message-ID: <201003141620....@freefall.freebsd.org>

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

From: =?windows-1251?B?0eL/8u7x6+Di?= <sl...@aprec.ru>
To: bug-fo...@FreeBSD.org, sl...@aprec.ru
Cc:
Subject: Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
Date: Sun, 14 Mar 2010 19:00:25 +0300

I'm now using ipfw setfib command as workaround, PF as NAT + ipfw
works fine for me.

--=20
=D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC,
=C1=E5=EB=EE=E3=F3=F0=EE=E2 =D1=E2=FF=F2=EE=F1=EB=E0=E2
8 (81555) 7-40-99
=D0=E5=EB=E0=ED=F2, http://www.relant.ru
mailto:sl...@aprec.ru

------------------------------

Message: 13
Date: Sun, 14 Mar 2010 20:30:10 GMT
From: Nick Leuta <sky...@mail.sc.ru>
Subject: Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
To: freeb...@FreeBSD.org
Message-ID: <201003142030....@freefall.freebsd.org>

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

From: Nick Leuta <sky...@mail.sc.ru>
To: bug-fo...@FreeBSD.org, sl...@aprec.ru
Cc:
Subject: Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
Date: Sun, 14 Mar 2010 23:20:44 +0300

Hmm... Im my case "ipfw fwd" command doesn't work too - it forwards
locally generated packets using the routing table (???)... but yes, it
has some effect - it changes the interface where the packets are
originated. PF's "route-to" command works fine, but only if the
destination host is reachable...

------------------------------

Message: 14
Date: Mon, 15 Mar 2010 11:07:18 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201003151107....@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.

43 problems total.

------------------------------

Message: 15
Date: Tue, 16 Mar 2010 15:19:51 -0400
From: "kevin" <k...@kevinkevin.com>
Subject: PF + BRIDGE + PFSYNC causes system freezing
To: <freeb...@freebsd.org>, <freeb...@freebsd.org>
Message-ID: <00bc01cac53d$a92f0b70$fb8d2250$@com>
Content-Type: text/plain; charset="us-ascii"

I have been experiencing this problem with 2x freebsd firewall
implementations running pf + transparent bridging + pfsync between both
boxes.

Today in an effort to narrow down and troubleshoot the issue further, I have
decided to build two FreeBSD 7.2-RELEASE implementations using virtualbox.
Each box was allocated 256mb ram, 3 NIC's (internal network only) and a 4GB
hard drive. I compiled PF/ALTQ/MROUTING into the kernel and installed it. No
other fundamental modifications were made.

The intent is to reproduce the problem in a controlled environment. And
provide any information to @freebsd.org if requested.

Here is the pertinent information below. Note both boxes are identical :

[UNAME]
# uname -a
FreeBSD fw 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue Mar 16 13:18:05 UTC 2010
root@:/usr/obj/usr/src/sys/FW i386

[IFCONFIG]
# ifconfig
em0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 08:00:27:91:2d:fd
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
em1: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 08:00:27:c7:3f:6b
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 08:00:27:de:66:c6
inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
pfsync0: flags=41<UP,RUNNING> metric 0 mtu 1460
pfsync: syncdev: em2 syncpeer: 10.0.0.11 maxupd: 128
bridge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 1e:29:e0:82:6e:d6
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000
member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 1 priority 128 path cost 20000

[KERNEL OPTIONS]
# Multicast routing support
options MROUTING

# PF Firewall
device pf
device pflog
device pfsync

options ALTQ
options ALTQ_CBQ # Class Bases Queuing (CBQ)
options ALTQ_RED # Random Early Detection (RED)
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)
options ALTQ_PRIQ # Priority Queuing (PRIQ)
options ALTQ_NOPCC # Required for SMP build

[RC.CONF]
keymap="us.iso"

hostname="fw"
gateway_enable="YES"
sshd_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm em0 addm em1 up"
ifconfig_em0="up"
ifconfig_em1="up"
ifconfig_em2="inet 10.0.0.10 netmask 255.255.255.0"

pf_enable="YES"
pf_rules="/etc/pf.conf"
pf_flags=""
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""
pfsync_enable="YES"
pfsync_syncdev="em2"

ifconfig_pfsync0="up syncpeer 10.0.0.11 syncif em2"

[PF.CONF]

# macros
ext_if="em0"
int_if="em1"
mng_if="em2"

tcp_services="{ 22, 113, 53, 80 }"
icmp_types="echoreq"

# options
set block-policy return
set loginterface $ext_if

set skip on lo

# scrub
scrub in all random-id fragment reassemble
scrub out on $ext_if random-id

# filter rules
pass in quick
pass out quick

pass quick on $mng_if proto pfsync

Note the only difference in config is the ip address of the pfsycn
interface. When both boxes are on , one or both of them start to really slow
down and ultimately freeze. No messages are pasted on the console and
/var/log/messages is inaccessible during this point.

I would like to assist in diagnosing this issue so if anyone wants me to
check anything or test, please let me know. I would really like to
understand this problem.

Thanks,

Kevin K.

------------------------------

Message: 16
Date: Wed, 17 Mar 2010 09:12:56 +0100
From: Daniel Hartmeier <dan...@benzedrine.cx>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: kevin <k...@kevinkevin.com>
Cc: freeb...@freebsd.org, freeb...@freebsd.org
Message-ID: <20100317081...@insomnia.benzedrine.cx>
Content-Type: text/plain; charset=us-ascii

On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:

> I would like to assist in diagnosing this issue so if anyone wants me to
> check anything or test, please let me know. I would really like to
> understand this problem.

What are your settings for

$ sysctl -a | grep bridge.pfil

Have you tried filtering only on one of the physical bridge interfaces,
with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0, em1 }?

Daniel

------------------------------

Message: 17
Date: Wed, 17 Mar 2010 11:47:32 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Daniel Hartmeier <dan...@benzedrine.cx>
Cc: freeb...@freebsd.org, freeb...@freebsd.org
Message-ID: <4BA0B344...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 17.03.2010 09:12, Daniel Hartmeier wrote:
> On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:
>
>
>> I would like to assist in diagnosing this issue so if anyone wants me to
>> check anything or test, please let me know. I would really like to
>> understand this problem.
>>
> What are your settings for
>
> $ sysctl -a | grep bridge.pfil
>

net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 1
net.link.bridge.pfil_onlyip: 1

> Have you tried filtering only on one of the physical bridge interfaces,
> with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0, em1 }?
>
> Daniel
>

Ok, I'm trying "set skip on {lo0, bridge0}".
I'll let you know if there is any improvement.

Thanks.

------------------------------

Message: 18
Date: Wed, 17 Mar 2010 09:55:05 -0400
From: "kevin" <k...@kevinkevin.com>
Subject: RE: PF + BRIDGE + PFSYNC causes system freezing
To: "'Daniel Hartmeier'" <dan...@benzedrine.cx>
Cc: freeb...@freebsd.org, freeb...@freebsd.org
Message-ID: <012301cac5d9$73d933f0$5b8b9bd0$@com>
Content-Type: text/plain; charset="us-ascii"

>What are your settings for
>
> $ sysctl -a | grep bridge.pfil

#bridge options
net.link.bridge.pfil_onlyip=1
net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=0

> Have you tried filtering only on one of the physical bridge interfaces,
> with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0, em1 }?

I've only been filtering on one of the bridge interfaces , however I have
not 'set skip on' the other interfaces. I will try that.

------------------------------

Message: 19
Date: Wed, 17 Mar 2010 10:41:38 -0400
From: "kevin" <k...@kevinkevin.com>
Subject: RE: PF + BRIDGE + PFSYNC causes system freezing
To: "'kevin'" <k...@kevinkevin.com>, "'Daniel Hartmeier'"
<dan...@benzedrine.cx>
Cc: freeb...@freebsd.org, freeb...@freebsd.org
Message-ID: <013701cac5df$f4c3ec20$de4bc460$@com>
Content-Type: text/plain; charset="us-ascii"

>>What are your settings for
>>
>> $ sysctl -a | grep bridge.pfil

>#bridge options
>net.link.bridge.pfil_onlyip=1
>net.link.bridge.pfil_member=1
>net.link.bridge.pfil_bridge=0

>> Have you tried filtering only on one of the physical bridge interfaces,
>> with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0, em1}?

>I've only been filtering on one of the bridge interfaces , however I have
>not 'set skip on' the other interfaces. I will try that.

I have 'set skip' all interfaces except one of the bridged ones (em0) , in
pf.conf.

Interesting symptom currently is that the load on both servers is quite high
considering they are just virtual machines that aren't actually doing
anything :

[server1]
last pid: 1176; load averages: 2.66, 3.01, 2.87 up 0+00:36:26
10:34:24
22 processes: 1 running, 21 sleeping
CPU: % user, % nice, % system, % interrupt, % idle
Mem: 8140K Active, 9400K Inact, 27M Wired, 34M Buf, 195M Free
Swap: 120M Total, 120M Free

[server2]
last pid: 1116; load averages: 8.50, 10.11, 8.66 up 0+00:39:35
10:37:46
22 processes: 2 running, 20 sleeping
CPU: 0.0% user, 0.0% nice, 95.2% system, 4.8% interrupt, 0.0% idle
Mem: 8116K Active, 9560K Inact, 16M Wired, 8K Cache, 34M Buf, 205M Free
Swap: 120M Total, 120M Free

I decided to ping the pfsync0 interface from server 1 > server 2 :

# ping 10.0.0.11
PING 10.0.0.11 (10.0.0.11): 56 data bytes
64 bytes from 10.0.0.11: icmp_seq=3 ttl=64 time=91.159 ms
64 bytes from 10.0.0.11: icmp_seq=3 ttl=64 time=114.017 ms (DUP!)
64 bytes from 10.0.0.11: icmp_seq=4 ttl=64 time=206.446 ms
64 bytes from 10.0.0.11: icmp_seq=5 ttl=64 time=92.209 ms
64 bytes from 10.0.0.11: icmp_seq=5 ttl=64 time=181.774 ms (DUP!)
64 bytes from 10.0.0.11: icmp_seq=5 ttl=64 time=363.855 ms (DUP!)
^C
--- 10.0.0.11 ping statistics ---
9 packets transmitted, 3 packets received, +3 duplicates, 66.7% packet loss
round-trip min/avg/max/stddev = 91.159/174.910/363.855/95.135 ms

If theres anything else I could check , suggestions are welcome.

Thanks,

Kevin K.

------------------------------

Message: 20
Date: Wed, 17 Mar 2010 16:46:15 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Daniel Hartmeier <dan...@benzedrine.cx>
Cc: freeb...@freebsd.org, freeb...@freebsd.org
Message-ID: <4BA0F947...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 17.03.2010 11:47, Giulio Ferro wrote:
> On 17.03.2010 09:12, Daniel Hartmeier wrote:
>> On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:
>>
>>> I would like to assist in diagnosing this issue so if anyone wants
>>> me to
>>> check anything or test, please let me know. I would really like to
>>> understand this problem.
>> What are your settings for
>>
>> $ sysctl -a | grep bridge.pfil
>
> net.link.bridge.pfil_local_phys: 0
> net.link.bridge.pfil_member: 1
> net.link.bridge.pfil_bridge: 1
> net.link.bridge.pfil_onlyip: 1
>
>
>> Have you tried filtering only on one of the physical bridge interfaces,
>> with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0,
>> em1 }?
>>
>> Daniel
>
> Ok, I'm trying "set skip on {lo0, bridge0}".
> I'll let you know if there is any improvement.

No, no improvement.

The system froze anyway after about 3-4 hours this time.

Please advise!

------------------------------

Message: 21
Date: Wed, 17 Mar 2010 15:50:32 +0000
From: Greg Hennessy <Greg.H...@nviz.net>
Subject: RE: PF + BRIDGE + PFSYNC causes system freezing
To: Giulio Ferro <au...@zirakzigil.org>, Daniel Hartmeier
<dan...@benzedrine.cx>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>,
"freeb...@freebsd.org" <freeb...@freebsd.org>
Message-ID:
<9E8D76EC267C9444AC737...@PEMEXMBXVS02.jellyfishnet.co.uk.local>

Content-Type: text/plain; charset="us-ascii"

A possible corner case with the virtual hosting platform ?

Try changing the NICS from EM to something else supported RL on vmware IIRC.

Greg

________________________________________
From: owner-fr...@freebsd.org [owner-fr...@freebsd.org] On Behalf Of Giulio Ferro [au...@zirakzigil.org]
Sent: 17 March 2010 15:46
To: Daniel Hartmeier
Cc: freeb...@freebsd.org; freeb...@freebsd.org
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing

No, no improvement.

The system froze anyway after about 3-4 hours this time.

Please advise!

------------------------------

Message: 22
Date: Wed, 17 Mar 2010 17:37:31 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Greg Hennessy <Greg.H...@nviz.net>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>,
"freeb...@freebsd.org" <freeb...@freebsd.org>
Message-ID: <4BA105...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 17.03.2010 16:50, Greg Hennessy wrote:
> A possible corner case with the virtual hosting platform ?
>
> Try changing the NICS from EM to something else supported RL on vmware IIRC.
>
>
>

Nope, I'm not using virtualization, that's the other guy.

I'm using a physical machine...

> Greg
>
> ________________________________________
> From: owner-fr...@freebsd.org [owner-fr...@freebsd.org] On Behalf Of Giulio Ferro [au...@zirakzigil.org]
> Sent: 17 March 2010 15:46
> To: Daniel Hartmeier
> Cc: freeb...@freebsd.org; freeb...@freebsd.org
> Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
>
> On 17.03.2010 11:47, Giulio Ferro wrote:
>
>> On 17.03.2010 09:12, Daniel Hartmeier wrote:
>>
>>> On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:
>>>
>>>
>>>> I would like to assist in diagnosing this issue so if anyone wants
>>>> me to
>>>> check anything or test, please let me know. I would really like to
>>>> understand this problem.
>>>>
>>> What are your settings for
>>>
>>> $ sysctl -a | grep bridge.pfil
>>>
>> net.link.bridge.pfil_local_phys: 0
>> net.link.bridge.pfil_member: 1
>> net.link.bridge.pfil_bridge: 1
>> net.link.bridge.pfil_onlyip: 1
>>
>>
>>
>>> Have you tried filtering only on one of the physical bridge interfaces,
>>> with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0,
>>> em1 }?
>>>
>>> Daniel
>>>
>> Ok, I'm trying "set skip on {lo0, bridge0}".
>> I'll let you know if there is any improvement.
>>
>
> No, no improvement.
>
> The system froze anyway after about 3-4 hours this time.
>
> Please advise!
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"

------------------------------

Message: 23
Date: Wed, 17 Mar 2010 17:47:28 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: freeb...@freebsd.org
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>, Giulio Ferro
<au...@zirakzigil.org>, Greg Hennessy <Greg.H...@nviz.net>
Message-ID: <20100317174...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"

On Wednesday 17 March 2010 17:37:31 Giulio Ferro wrote:
> On 17.03.2010 16:50, Greg Hennessy wrote:
> > A possible corner case with the virtual hosting platform ?
> >
> > Try changing the NICS from EM to something else supported RL on vmware
> > IIRC.
>
> Nope, I'm not using virtualization, that's the other guy.
>
> I'm using a physical machine...

Can you enable WITNESS and compile in DDB. Make sure to report any LORs and
once the system freezes try to enter the debugger and get ps and locks
information.

show allchains
show alllocks
ps

After that you can try to "call doadump" so you get the information in the
coredump and don't have to transcribe it manually.

Thanks,
Max

------------------------------

Message: 24
Date: Wed, 17 Mar 2010 17:57:54 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Max Laier <m...@love2party.net>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>, Greg Hennessy
<Greg.H...@nviz.net>, freeb...@freebsd.org
Message-ID: <4BA10A12...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 17.03.2010 17:47, Max Laier wrote:
> On Wednesday 17 March 2010 17:37:31 Giulio Ferro wrote:
>
>> On 17.03.2010 16:50, Greg Hennessy wrote:
>>
>>> A possible corner case with the virtual hosting platform ?
>>>
>>> Try changing the NICS from EM to something else supported RL on vmware
>>> IIRC.
>>>
>> Nope, I'm not using virtualization, that's the other guy.
>>
>> I'm using a physical machine...
>>
> Can you enable WITNESS and compile in DDB. Make sure to report any LORs and
> once the system freezes try to enter the debugger and get ps and locks
> information.
>
> show allchains
> show alllocks
> ps
>
> After that you can try to "call doadump" so you get the information in the
> coredump and don't have to transcribe it manually.
>
> Thanks,
> Max
>

Sorry, I'm not really an expert of this, but how can I enter the debugger
if the system has frozen?

------------------------------

Message: 25
Date: Wed, 17 Mar 2010 18:00:51 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Giulio Ferro <au...@zirakzigil.org>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>, Greg Hennessy
<Greg.H...@nviz.net>, freeb...@freebsd.org
Message-ID: <20100317180...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"

On Wednesday 17 March 2010 17:57:54 Giulio Ferro wrote:
> On 17.03.2010 17:47, Max Laier wrote:
> > On Wednesday 17 March 2010 17:37:31 Giulio Ferro wrote:
> >> On 17.03.2010 16:50, Greg Hennessy wrote:
> >>> A possible corner case with the virtual hosting platform ?
> >>>
> >>> Try changing the NICS from EM to something else supported RL on vmware
> >>> IIRC.
> >>
> >> Nope, I'm not using virtualization, that's the other guy.
> >>
> >> I'm using a physical machine...
> >
> > Can you enable WITNESS and compile in DDB. Make sure to report any LORs
> > and once the system freezes try to enter the debugger and get ps and
> > locks information.
> >
> > show allchains
> > show alllocks
> > ps
> >
> > After that you can try to "call doadump" so you get the information in
> > the coredump and don't have to transcribe it manually.
> >
> > Thanks,
> > Max
>
> Sorry, I'm not really an expert of this, but how can I enter the debugger
> if the system has frozen?

Ctrl+Alt+ESC (in default configuration).

------------------------------

Message: 26
Date: Wed, 17 Mar 2010 17:38:50 +0000
From: Greg Hennessy <Greg.H...@nviz.net>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Giulio Ferro <au...@zirakzigil.org>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>,
"freeb...@freebsd.org" <freeb...@freebsd.org>
Message-ID:
<1893309981.58859.1268...@bda094.bisx.produk.on.blackberry>

Content-Type: text/plain; charset="Windows-1252"

My bad, that'll teach me to reply in haste :-)
Sent using BlackBerry® from Orange

-----Original Message-----
From: Giulio Ferro <au...@zirakzigil.org>
Date: Wed, 17 Mar 2010 16:37:31
To: Greg Hennessy<Greg.H...@nviz.net>
Cc: Daniel Hartmeier<dan...@benzedrine.cx>; freeb...@freebsd.org<freeb...@freebsd.org>; freeb...@freebsd.org<freeb...@freebsd.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing

On 17.03.2010 16:50, Greg Hennessy wrote:
> A possible corner case with the virtual hosting platform ?
>
> Try changing the NICS from EM to something else supported RL on vmware IIRC.
>
>
>

Nope, I'm not using virtualization, that's the other guy.

I'm using a physical machine...

> Greg
>
>________________________________________
> From: owner-fr...@freebsd.org [owner-fr...@freebsd.org] On Behalf Of Giulio Ferro [au...@zirakzigil.org]
> Sent: 17 March 2010 15:46
> To: Daniel Hartmeier
> Cc: freeb...@freebsd.org; freeb...@freebsd.org
> Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
>
> On 17.03.2010 11:47, Giulio Ferro wrote:
>
>> On 17.03.2010 09:12, Daniel Hartmeier wrote:
>>
>>> On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:
>>>
>>>
>>>> I would like to assist in diagnosing this issue so if anyone wants
>>>> me to
>>>> check anything or test, please let me know. I would really like to
>>>> understand this problem.
>>>>
>>> What are your settings for
>>>
>>> $ sysctl -a | grep bridge.pfil
>>>
>> net.link.bridge.pfil_local_phys: 0
>> net.link.bridge.pfil_member: 1
>> net.link.bridge.pfil_bridge: 1
>> net.link.bridge.pfil_onlyip: 1
>>
>>
>>
>>> Have you tried filtering only on one of the physical bridge interfaces,
>>> with net.link.bridge.pfil_bridge=0 and set skip on { lo0, bridge0,
>>> em1 }?
>>>
>>> Daniel
>>>
>> Ok, I'm trying "set skip on {lo0, bridge0}".
>> I'll let you know if there is any improvement.
>>
>
> No, no improvement.
>
> The system froze anyway after about 3-4 hours this time.
>
> Please advise!
>_______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"

------------------------------

Message: 27
Date: Thu, 18 Mar 2010 15:04:06 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Max Laier <m...@love2party.net>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>, Greg Hennessy
<Greg.H...@nviz.net>, freeb...@freebsd.org
Message-ID: <4BA232D6...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 17.03.2010 18:00, Max Laier wrote:
> Can you enable WITNESS and compile in DDB. Make sure to report any LORs
>>> and once the system freezes try to enter the debugger and get ps and
>>> locks information.
>>>
>>> show allchains
>>> show alllocks
>>> ps
>>>
>>> After that you can try to "call doadump" so you get the information in
>>> the coredump and don't have to transcribe it manually.
>>>
>>> Thanks,
>>> Max
>>>
>> Sorry, I'm not really an expert of this, but how can I enter the debugger
>> if the system has frozen?
>>
> Ctrl+Alt+ESC (in default configuration).
> _______________________________________________
>

I've added this to the kernel

option KDB
option WITNESS
option WITNESS_KDB
option DDB

Now it can't even boot properly. It stops when it tries to configure
networking:
uma_zalloc_arg: zone "256" with the following non-sleepable locks held:
exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
/usr/src/sys/net/if.c:414

show allchains
<no result>

show alllocks
exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
/usr/src/sys/net/if.c:414
exclusive sx ifnet_sx (ifnet_sx) r = 0 (0xffffffff80e31b40) locked @
/usr/src/sys/net/if.c:414

ps
<returns a lot of stuff. tell me to search something in particular>

call doadump
Cannot dump. Device not defined or unavailable

Hope it helps...

------------------------------

Message: 28
Date: Thu, 18 Mar 2010 15:26:00 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: freeb...@freebsd.org
Cc: Giulio Ferro <au...@zirakzigil.org>, Greg Hennessy
<Greg.H...@nviz.net>, freeb...@freebsd.org
Message-ID: <20100318152...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"

On Thursday 18 March 2010 15:04:06 Giulio Ferro wrote:
> On 17.03.2010 18:00, Max Laier wrote:
> > Can you enable WITNESS and compile in DDB. Make sure to report any LORs
> >
> >>> and once the system freezes try to enter the debugger and get ps and
> >>> locks information.
> >>>
> >>> show allchains
> >>> show alllocks
> >>> ps
> >>>
> >>> After that you can try to "call doadump" so you get the information in
> >>> the coredump and don't have to transcribe it manually.
> >>>
> >>> Thanks,
> >>> Max
> >>
> >> Sorry, I'm not really an expert of this, but how can I enter the
> >> debugger if the system has frozen?
> >
> > Ctrl+Alt+ESC (in default configuration).
> > _______________________________________________
>
> I've added this to the kernel
>
> option KDB
> option WITNESS
> option WITNESS_KDB

remove WITNESS_KDB, it's not what you want.

> option DDB
>
>
> Now it can't even boot properly. It stops when it tries to configure
> networking:
> uma_zalloc_arg: zone "256" with the following non-sleepable locks held:
> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
> /usr/src/sys/net/if.c:414

a "bt" would help in this case to see where the bad alloc is.

> show allchains
> <no result>
>
> show alllocks
> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff80e31b20) locked @
> /usr/src/sys/net/if.c:414
> exclusive sx ifnet_sx (ifnet_sx) r = 0 (0xffffffff80e31b40) locked @
> /usr/src/sys/net/if.c:414
>
> ps
> <returns a lot of stuff. tell me to search something in particular>
>
> call doadump
> Cannot dump. Device not defined or unavailable

define "dumpdev" in rc.conf to a swap partition with enough space or call
dumpon(8).

Thanks,
Max

------------------------------

Message: 29
Date: Thu, 18 Mar 2010 15:18:31 +0100
From: "pawe...@gmail.com" <pawe...@gmail.com>
Subject: Synproxy state - advertising 0 window size
To: freeb...@freebsd.org
Message-ID:
<c6b9a7811003180718t190...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I have small network like this: [Internet] --- rl0(FreeBSD -
router)rl1 --- [Lan]

I wanted to make whole outgoing packets from the Lan look the same. It
means that every SYN packet has the same TCP/IP stack. So I thought
about PF's synproxy state. I know synproxy was made for other puprose
but I tried to do something like this (this is piece of my PF
firewall):

ext_if="rl0"
int_if="rl1"
set skip on lo
scrub on $int_if min-ttl 129
nat on $ext_if from !($ext_if) to any -> ($ext_if)
pass in on $int_if proto tcp from any to any port {443, 8074} flags
S/SA synproxy state (ports are only examples)

Everything on this configuration works well but let's see listing from tcpdump:
### NATed synproxy packet###
# tcpdump -i rl0 -n -vvv 'tcp[13] & 2 != 0'
tcpdump: listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes
15:09:14.680832 IP (tos 0x10, ttl 128, id 35567, offset 0, flags [DF],
proto TCP (6), length 44)
10.0.0.101.51220 > 91.111.111.12.443: Flags [S], cksum 0xf73f
(correct), seq 2917250499, win 0, options [mss 1460], length 0

15:09:14.714002 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto
TCP (6), length 44)
91.111.111.12.443 > 10.0.0.101.51220: Flags [S.], cksum 0x819e
(correct), seq 1940581141, ack 2917250500, win 5840, options [mss
1460], length 0

###System SYN####
15:11:05.876433 IP (tos 0x0, ttl 128, id 35741, offset 0, flags [DF],
proto TCP (6), length 48)
10.0.0.101.55040 > 94.23.95.22.80: Flags [S], cksum 0x7741
(correct), seq 414405961, win 65535, options [mss 1460,sackOK,eol],
length 0

15:11:05.920871 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto
TCP (6), length 44)
94.23.95.22.80 > 10.0.0.101.55040: Flags [S.], cksum 0xcccf
(correct), seq 106340672, ack 414405962, win 5840, options [mss 1460],
length 0

1. In first SYN packet (from PF's synproxy) we can see that it doesnt
have any options (why?) and it advertises 0 windows size why?
2. In second SYN which comes from FreeBSD (time stamps are disabled
and ttl is changed) there are options and window size. Why do these
both packets are different? Is it normal that synproxy sends SYNs with
0 window size?

------------------------------

Message: 30
Date: Thu, 18 Mar 2010 17:39:29 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: Re: PF + BRIDGE + PFSYNC causes system freezing
To: Max Laier <m...@love2party.net>
Cc: freeb...@freebsd.org, Greg Hennessy <Greg.H...@nviz.net>,
freeb...@freebsd.org
Message-ID: <4BA25741...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 18.03.2010 15:26, Max Laier wrote:

Ok, it's happened again...
and once the system freezes try to enter the debugger and get ps and
>>>>> locks information.
>>>>>
>>>>> show allchains
>>>>>

No result

>>>>> show alllocks
>>>>>

Process 4483 (sshd) thread 0xffffff0002ded3a0 (100159)
exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff0002c79b98) locked @
/usr/src/sys/kern/uipc_sockbuf.c:148
Process 12 (intr) thread 0xffffff000242b3a0 (100028)
exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xffffff000282d018)
locked @ /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2162
Process 12 (intr) thread 0xffffff00023d3ae0 (100021)
exclusive slepp mutex Giant (Giant) r = 1 (0xffffffff80c6f660) locked @
/usr/src/sys/dev/usb/usb_transfer.c:3009
Process 12 (intr) thread 0xffffff00022603a0 (1000007)
exclusive sleep mutex carp_if (carp_if) r = 0 (0xffffff0002730360)
locked @ /usr/src/sys/netinet/ip_carp.c:881

>>>>> ps
>>>>>
>>>>>

This yields a lot of lines, tell me if you want me to report something
special

> a "bt" would help in this case to see where the bad alloc is.
>
>

Tracing pid 12 tid 100021 td 0xffffff00023d3ae0
kdb_enter() at kdb_enter+0x3d
...

Thank for your interest.

------------------------------

End of freebsd-pf Digest, Vol 278, Issue 1
******************************************

0 new messages