From owner-freebsd-current@FreeBSD.ORG Wed Apr 18 18:18:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED29816A408 for ; Wed, 18 Apr 2007 18:18:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8304A13C46A for ; Wed, 18 Apr 2007 18:18:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.6.214] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HeEjl1yJA-0000iI; Wed, 18 Apr 2007 20:18:38 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Wed, 18 Apr 2007 20:18:27 +0200 User-Agent: KMail/1.9.5 References: <20070417153357.GA1335@seekingfire.com> <20070418084345.H2913@fledge.watson.org> <20070418154950.GM1225@seekingfire.com> In-Reply-To: <20070418154950.GM1225@seekingfire.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2830636.rBnoFHnBoV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704182018.35054.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18nHtNolaxX1RLevyDAQ7//tAGZLPJZ2r1bMn4 nSl9CptQJPZ9sDnSsW4dLZ3jif/1sV8GLOsN+Ihb38UV+Xs0rS pVvMH25YfauDnssoHmJtQ== Cc: Tillman Hodgson Subject: Re: Panic on boot with April 16 src (lengthy info attached) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 18:18:45 -0000 --nextPart2830636.rBnoFHnBoV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 18 April 2007 17:49, Tillman Hodgson wrote: > On Wed, Apr 18, 2007 at 08:54:00AM +0100, Robert Watson wrote: > > Things get sticky deep in the firewall code because our firewalls > > include credential-aware rules, which essentially "peek up the stack" > > in order to decide what user is associated with a packet before > > delivery to the connection is done. The firewall rule lock is held > > over this lookup and inspection of TCP-layer state. In the out-bound > > path, we pass down the TCP state reference (PCB pointer) and > > guarantee the lock is already held. However, in the in-bound > > direction, the firewall has to do the full lookup and lock > > acquisition. Which reverses the lock order, and can lead to > > deadlocks. > > Thanks for the explanation :-) > > Previously you pointed out the ipfw man page which seems to be say the > same thing (albeit with much less detail): > > gid group > Matches all TCP or UDP packets sent by or received for a group. > A group may be specified by name or number. This option should > be used only if debug.mpsafenet=3D0 to avoid possible deadlocks due > to layering violations in its implementation. > > Setting debug.mpsafenet=3D0 worked for me until the TCP timer change. Is > the LOR situation always true for every inbound packet, or only with > certain firewall rules in place? > > That question has me wondering if I can avoid the issue by avoiding > certain PF features. My current ruleset is pretty simple. If I drop the > variables definitions and comments, the whole thing is 13 lines: > > nat on $ext_if from $internal_net to any -> ($ext_if) > rdr on $int_if proto tcp from $internal_net to any port ftp -> > 127.0.0.1 port 8021 block log all > pass quick on lo0 all > pass quick on $int_if proto ospf all > pass in on $ext_if inet proto tcp from any to ($ext_if) port > $tcp_services flags S/SA keep state pass in on $ext_if inet proto udp > from any to ($ext_if) port $udp_services keep state pass in on $ext_if > inet proto icmp all icmp-type $icmp_types keep state pass in on $ext_if > inet proto tcp from any to $ext_if user proxy keep state pass in on > $int_if from $metanetwork to any > pass out on $int_if from any to $metanetwork > pass out on $ext_if proto tcp all modulate state flags S/SA > pass out on $ext_if proto { udp, icmp } all keep state Running Current you can try to include "options PF_MPSAFE_UGID". This is=20 a hack that allows the use of user/group rules in a debug.mpsafe=3D1=20 environment. Unfortunately, I never got any feedback on this albeit=20 throwing it after everybody with these symptoms. Please report back! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2830636.rBnoFHnBoV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGJmD7XyyEoT62BG0RAnMEAJsFQPkFLjnSF/OaGvt66Vy9LpZhgACfW1mf 8OOQLxNfV8XuxPS02O77KAY= =ieQT -----END PGP SIGNATURE----- --nextPart2830636.rBnoFHnBoV--