From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 17:56:45 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B197B16A420 for ; Sun, 5 Jun 2005 17:56:45 +0000 (GMT) (envelope-from taglio@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9C9E43D1F for ; Sun, 5 Jun 2005 17:56:44 +0000 (GMT) (envelope-from taglio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so946884wra for ; Sun, 05 Jun 2005 10:56:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pIKZRTaetjlC+PjXqZ+wp7uIbtEUij10zHzxqFmvf8+rHYIbTwpltjBt6ANtMLB5So+p0mC4e8G1VmufVtAZrhx0zS7lzYUhei04sZhJNWyLGEnqgXgg2BdWCInN42ohM2CTOB8UYMtM7XsANAyCbXwVnkdOdbIP7/RzszTiCbY= Received: by 10.54.115.3 with SMTP id n3mr2695288wrc; Sun, 05 Jun 2005 10:56:44 -0700 (PDT) Received: by 10.54.38.41 with HTTP; Sun, 5 Jun 2005 10:56:44 -0700 (PDT) Message-ID: <31fbaca905060510563c64eb49@mail.gmail.com> Date: Sun, 5 Jun 2005 19:56:44 +0200 From: Riccardo Giuntoli To: freebsd-questions@freebsd.org, freebsd-pf@freebsd.org, freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: limit number of tcp connection for a GID X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Riccardo Giuntoli List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 17:56:45 -0000 Hi folks, Do you have any idea for limiting the number of tcp ESTABLISHED connections for a GID? Shall i use a special rule in my pf.conf or shall i use a kernel limit or any other rule in the system? Best Regards --=20 Name: Riccardo Giuntoli Email: taglio@gmail.com Homepage: http://www.luxoro.org/ Location: Genova, Italy 6BONE Handle: RG581-6BONE PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842F AB54=20 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 18:13:25 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D8D616A41C for ; Sun, 5 Jun 2005 18:13:25 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47F6C43D49 for ; Sun, 5 Jun 2005 18:13:24 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 19913 invoked by uid 207); 5 Jun 2005 18:13:24 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.189):. Processed in 0.320411 secs); 05 Jun 2005 18:13:24 -0000 Received: from dialup189.ach.sch.gr (HELO gothmog.gr) ([81.186.70.189]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Jun 2005 18:13:23 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j55IDHRY055609; Sun, 5 Jun 2005 21:13:17 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j55IDG7p055604; Sun, 5 Jun 2005 21:13:16 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 5 Jun 2005 21:13:15 +0300 From: Giorgos Keramidas To: Riccardo Giuntoli Message-ID: <20050605181315.GE16327@gothmog.gr> References: <31fbaca905060510563c64eb49@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31fbaca905060510563c64eb49@mail.gmail.com> Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: limit number of tcp connection for a GID X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 18:13:25 -0000 On 2005-06-05 19:56, Riccardo Giuntoli wrote: > Hi folks, > Do you have any idea for limiting the number of tcp ESTABLISHED > connections for a GID? ipfw can match connections per uid/gid and it also has limiting capabilities. When combined with dummynet, it can also enforce bandwidth limits. See the ipfw(8) manpage for details. I'm not sure if pf does this already. Even if it doesn't though, it may be possible to write a transparent proxy that limits the connections per uid/gid. The support for transparent proxies in pf is awesome :-) From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 18:15:55 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E2B216A41C for ; Sun, 5 Jun 2005 18:15:55 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-03-eri0.ohiordc.rr.com (ms-smtp-03-smtplb.ohiordc.rr.com [65.24.5.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 223ED43D1D for ; Sun, 5 Jun 2005 18:15:54 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-65-31-41-46.woh.res.rr.com [65.31.41.46]) by ms-smtp-03-eri0.ohiordc.rr.com (8.12.10/8.12.7) with SMTP id j55IFpYF015248 for ; Sun, 5 Jun 2005 14:15:52 -0400 (EDT) Message-ID: <000501c569fa$9b6d28d0$0200a8c0@satellite> From: "dave" To: Date: Sun, 5 Jun 2005 14:15:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: ftp-proxy timeout errors, block all policy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dave List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 18:15:55 -0000 Hello, I'm trying to get ftp working for clients behind a pf firewall running on 5.3. Both active and passive ftp connections work from the firewall itself but neither work from any clients behind the firewall. I'm using a default block all policy and from the tcpdumps i'm doing it looks like source ports are being blocked when they go to the lan interface to be transfered to the ftp-proxy. Here are my ftp rules: EXT = "ep0" LAN = "ed0" LAN_CLIENTS = "192.168.0.0/24" LAN_SERVER = "192.168.0.78" set block-policy drop scrub on $EXT reassemble tcp random-id nat on $EXT from $LAN_CLIENTS to any -> ($EXT) # redirect lan client active FTP requests (to an FTP server's control port 21) # to the ftp-proxy running on the firewall host (via inetd on port 8021) rdr on $LAN proto tcp from any to any port 21 -> 127.0.0.1 port 8021 # deny by default block log all # Allow remote FTP servers (on data port 20) to respond to the proxy's # active FTP requests by contacting it on the port range specified in inetd.conf pass in on $EXT \ inet proto tcp \ from any port 20 \ to $EXT port 55000 >< 57000 \ user proxy \ flags S/SA keep state # allow ftp active requests out pass out on $EXT \ inet proto tcp \ from $EXT to any \ port 20 \ flags S/SA keep state # allow firewall to contact ftp server on behalf of passive ftp client # on control port 21 pass out on $EXT \ inet proto tcp \ from $EXT to any \ port 21 \ flags S/SA keep state # allow firewall to contact ftp server on behalf of passive ftp client # on standard unprivileged port range ( > 1024 ) pass out on $EXT \ inet proto tcp \ from $EXT to any \ port > 1024 \ flags S/SA keep state My ftp-proxy line in inetd.conf uses the -u proxy, -n, -m 55550, -M 55600 and -t 180 options. Help appreciated. Thanks. Dave. From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 18:36:13 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3E8516A41C for ; Sun, 5 Jun 2005 18:36:12 +0000 (GMT) (envelope-from taglio@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B31DC43D58 for ; Sun, 5 Jun 2005 18:36:11 +0000 (GMT) (envelope-from taglio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so954625wra for ; Sun, 05 Jun 2005 11:36:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m4gCPTgcUE9xQaaBCc+hZlRDrpagwuYJoMry410O/iY0YY8FoqoMX32AwNU4cbJMI2HLa9O6SSkcM1Mn51XiqSGt+RiDvKp9iM4AiVKqvRY8Q9EGyIHZhdc0SU0jbBtAjLFrYhrwa2t+n6zmCUFaOD5Fr03ZloSGt9uywVyAHmo= Received: by 10.54.123.10 with SMTP id v10mr541708wrc; Sun, 05 Jun 2005 11:36:11 -0700 (PDT) Received: by 10.54.38.41 with HTTP; Sun, 5 Jun 2005 11:36:11 -0700 (PDT) Message-ID: <31fbaca905060511367d24e3ec@mail.gmail.com> Date: Sun, 5 Jun 2005 20:36:11 +0200 From: Riccardo Giuntoli To: Giorgos Keramidas In-Reply-To: <20050605181315.GE16327@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <31fbaca905060510563c64eb49@mail.gmail.com> <20050605181315.GE16327@gothmog.gr> Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: limit number of tcp connection for a GID X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Riccardo Giuntoli List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 18:36:13 -0000 On 6/5/05, Giorgos Keramidas wrote: ... > I'm not sure if pf does this already. Even if it doesn't though, > it may be possible to write a transparent proxy that limits the > connections per uid/gid. The support for transparent proxies in > pf is awesome :-) I've found this on pf.conf(5) manpage: STATEFUL TRACKING OPTIONS All three of keep state, modulate state and synproxy state support the following options: max _number_ =09 Limits the number of concurrent states the rule may create.=09When =09 this limit is reached, further packets matching the rule that would =09 create state are dropped, until existing states time out. Thank you Giorgios Bye --=20 Name: Riccardo Giuntoli Email: taglio@gmail.com Homepage: http://www.luxoro.org/ Location: Genova, Italy 6BONE Handle: RG581-6BONE PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842F AB54=20 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 19:12:45 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79C5B16A41C for ; Sun, 5 Jun 2005 19:12:45 +0000 (GMT) (envelope-from taglio@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20C0543D1D for ; Sun, 5 Jun 2005 19:12:44 +0000 (GMT) (envelope-from taglio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so961554wra for ; Sun, 05 Jun 2005 12:12:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RU2vK2kctRTh4FynqyqDnJ/nAgog8UGEqzhzl9b1a7w6Pm5p+7Vii1TRPOyhVgM+8CbG5s+E0dkjZKKeNUGlVkfft27SIvtZ+xbRiAmHA9h9i5ldwfNlwV95J2XGaZZz0nZFKGc5cHprEVklvw9EkiYm6EQGPCe7ZzpVH1TvBPY= Received: by 10.54.15.75 with SMTP id 75mr1526709wro; Sun, 05 Jun 2005 12:12:44 -0700 (PDT) Received: by 10.54.38.41 with HTTP; Sun, 5 Jun 2005 12:12:44 -0700 (PDT) Message-ID: <31fbaca90506051212134e383e@mail.gmail.com> Date: Sun, 5 Jun 2005 21:12:44 +0200 From: Riccardo Giuntoli To: Giorgos Keramidas In-Reply-To: <20050605184032.GA66090@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <31fbaca905060510563c64eb49@mail.gmail.com> <20050605181315.GE16327@gothmog.gr> <31fbaca905060511367d24e3ec@mail.gmail.com> <20050605184032.GA66090@gothmog.gr> Cc: freebsd-pf@freebsd.org Subject: Re: limit number of tcp connection for a GID X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Riccardo Giuntoli List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 19:12:45 -0000 On 6/5/05, Giorgos Keramidas wrote: ... > No trace of uid or gid matching though. I thought it was specifically > uid/gid matching that you were after. Here you are the complete fantastic rule: pass out quick proto tcp from $irc_subnet to any port {4004, 5555, 5667, 6660, 6661, 6662, 6663, 6664,\ 6665, 6666, 6667, 6668, 6669, 7000} user >=3D 1009 modulate state (max 3)= =20 I've got a /23 subnet and i want that user UID > 1009 use only two connections to ircd. The rule is correct all go in the right way :) Regards --=20 Name: Riccardo Giuntoli Email: taglio@gmail.com Homepage: http://www.luxoro.org/ Location: Genova, Italy 6BONE Handle: RG581-6BONE PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842F AB54=20 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 19:23:53 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6201116A41C for ; Sun, 5 Jun 2005 19:23:53 +0000 (GMT) (envelope-from danger@rulez.sk) Received: from mail.rulez.sk (DaEmoN.RuLeZ.sK [84.16.32.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0032643D4C for ; Sun, 5 Jun 2005 19:23:52 +0000 (GMT) (envelope-from danger@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 4AA9D1CC31; Sun, 5 Jun 2005 21:23:51 +0200 (CEST) Received: from danger.mcrn.sk (danger.mcrn.sk [84.16.37.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rulez.sk (Postfix) with ESMTP id 280D61CC23; Sun, 5 Jun 2005 21:23:45 +0200 (CEST) Date: Sun, 5 Jun 2005 21:20:41 +0200 From: Daniel Gerzo X-Priority: 3 (Normal) Message-ID: <172915679.20050605212041@rulez.sk> To: Riccardo Giuntoli In-Reply-To: <31fbaca90506051212134e383e@mail.gmail.com> References: <31fbaca905060510563c64eb49@mail.gmail.com> <20050605181315.GE16327@gothmog.gr> <31fbaca905060511367d24e3ec@mail.gmail.com> <20050605184032.GA66090@gothmog.gr> <31fbaca90506051212134e383e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mail.rulez.sk X-Spam-Status: No, hits=-2.81 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-3.3, AWL=1.992, BAYES_00=-2.599, PRIORITY_NO_NAME=1.097] X-Spam-Level: Cc: Giorgos Keramidas , freebsd-pf@freebsd.org Subject: Re[2]: limit number of tcp connection for a GID X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 19:23:53 -0000 Hi Riccardo, Sunday, June 5, 2005, 9:12:44 PM, you wrote: > On 6/5/05, Giorgos Keramidas wrote: > ... >> No trace of uid or gid matching though. I thought it was specifically >> uid/gid matching that you were after. > Here you are the complete fantastic rule: > pass out quick proto tcp from $irc_subnet to any port {4004, 5555, > 5667, 6660, 6661, 6662, 6663, 6664,\ > 6665, 6666, 6667, 6668, 6669, 7000} user >= 1009 modulate state (max 3) > I've got a /23 subnet and i want that user UID > 1009 use only two > connections to ircd. > The rule is correct all go in the right way :) > Regards (31 Oct 2004) When the user/group rule clauses in pf(4) and ipfw(4) are used, the loader tunable debug.mpsafenet must be set to 0 (this is 1 by default). For example, the following rules are affected: for ipfw(4): count ip from any to 192.168.2.1 uid root for pf(4): block log quick proto { tcp, udp } all user root To set debug.mpsafenet to 0 on every boot, add the following line into /boot/loader.conf: debug.mpsafenet=0 More specifically, the group and user filter parameters in pf(4), and the gid, jail, and uid rule options in ipfw(4) are affected. If debug.mpsafenet is set to 1, the system can hang when the rule is evaluated due to a lock order reversal with the socket layer. More details can be found in the ipfw(8) and pf.conf(5) manual pages. -- Best regards DanGer, ICQ: 261701668 | e-mail protecting at: http://www.2pu.net/ http://danger.rulez.sk | proxy list at: http://www.proxy-web.com/ | FreeBSD - The Power to Serve! [ "640K should be enough memory for anyone." - Bill Gates ] From owner-freebsd-pf@FreeBSD.ORG Mon Jun 6 13:43:38 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 701B716A41C for ; Mon, 6 Jun 2005 13:43:38 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26CC143D5F for ; Mon, 6 Jun 2005 13:43:37 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so2277320nzk for ; Mon, 06 Jun 2005 06:43:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=f55bQPPTsmNg1S8HuApUWvfzK2gjUGdvyNOeiW0KLy4qpsqzRO9uay/Ff9PcjQiY6arGWX3Bi4icbQqLVGBYm55/vFchdUj6yIm1Lx5NA/ZffIAkzWP8izusOHNemohw2aytdTS95DyvbGQVrgKFANGJR56etvmOTHP1Cx5Jzy8= Received: by 10.36.101.12 with SMTP id y12mr515406nzb; Mon, 06 Jun 2005 06:43:37 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Mon, 6 Jun 2005 06:43:37 -0700 (PDT) Message-ID: <79722fad05060606437390adf2@mail.gmail.com> Date: Mon, 6 Jun 2005 16:43:37 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Large scale ALTQ deployment question X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 13:43:38 -0000 Does anyone have a success story involving ALTQ and huge number of classes (32k-64k) using CBQ, or better, HFSC ? --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 14:17:16 2005 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C90FF16A41C; Wed, 8 Jun 2005 14:17:16 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id C39A743D1F; Wed, 8 Jun 2005 14:17:15 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C0E3.dip.t-dialin.net [84.163.192.227] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwtQ-1Dg1Mm03Ps-0004iG; Wed, 08 Jun 2005 16:17:12 +0200 From: Max Laier To: Matthew Grooms Date: Wed, 8 Jun 2005 16:16:56 +0200 User-Agent: KMail/1.8 References: <28FCC7CB4CF6EA43AF83BCA2096E97D013E555@AUSEX2VS1.seton.org> <42A62F52.10705@seton.org> In-Reply-To: <42A62F52.10705@seton.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1125684.lrgfy40mCT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506081617.05938.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: pf@freebsd.org, glebius@freebsd.org, freebsd-stable@freebsd.org, Palle Girgensohn , Kris Kennaway Subject: Re: 5.4-RELEASE lockups on amd64 SMP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 14:17:16 -0000 --nextPart1125684.lrgfy40mCT Content-Type: multipart/mixed; boundary="Boundary-01=_c3vpCai3WMMzsSJ" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_c3vpCai3WMMzsSJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Matthew, can you try the attached diff. Available for 5 and CURRENT. I recall that= =20 this problem was seen before, strange that I didn't see the problem. Sound= s=20 familiar to you? Please try the patch and let me know if that helps. Than= ks=20 a lot. On Wednesday 08 June 2005 01:35, Matthew Grooms wrote: > Once again, here are the backtraces for the panic and lor ... > > Tracing id 110 tid 100089 td 0xffffff012f3f0c80 > kdb_enter() at kdb_enter+0x2f > panic() at panic+0x249 > uma_dbg_free() at uma_dbg_free+0x188 > uma_zfree_arg() at uma_zfree_arg+0x1b0 > pf_purge_expired_states() at pf_purge_expired_states+0x41 > pfsync_input at pfsync_input+xb35 > pf_input() at ip_input+0x10f > netisr_processqueue() at netisr_processqueue+0x17 > swi_net() at swi_net+0xa8 > ithread_loop() at ithread_loop+0xd9 > fork_exit() at fork_exit+0xc3 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffffffb44f9d00, rbp =3D 0 --- > db> continue > boot() called on cpu#0 > Uptime: 13h42m43s > Dumping 4864 MB > 16 32 ... > > lock order reversal =2E.. > alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5 > pf_state_tree_lan_ext_RB_REMOVE() at pf_state_tree_lan_ext_RB_REMOVE+0x10c This LOR is a consequence of the fault, so it can be disregarded. =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 --Boundary-01=_c3vpCai3WMMzsSJ Content-Type: text/x-diff; charset="iso-8859-1"; name="if_pfsync.senddef6.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="if_pfsync.senddef6.diff" Index: if_pfsync.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v retrieving revision 1.15 diff -u -r1.15 if_pfsync.c =2D-- if_pfsync.c 3 May 2005 16:43:32 -0000 1.15 +++ if_pfsync.c 8 Jun 2005 14:04:44 -0000 @@ -132,6 +132,7 @@ =20 static void pfsync_clone_destroy(struct ifnet *); static int pfsync_clone_create(struct if_clone *, int); +static void pfsync_senddef(void *); #else void pfsyncattach(int); #endif @@ -174,6 +175,8 @@ callout_stop(&sc->sc_bulk_tmo); callout_stop(&sc->sc_bulkfail_tmo); =20 + callout_stop(&sc->sc_send_tmo); + #if NBPFILTER > 0 bpfdetach(ifp); #endif @@ -220,6 +223,7 @@ callout_init(&sc->sc_tmo, 0); callout_init(&sc->sc_bulk_tmo, 0); callout_init(&sc->sc_bulkfail_tmo, 0); + callout_init(&sc->sc_send_tmo, 0); if_attach(ifp); =20 LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); @@ -1033,6 +1037,7 @@ if (pfsyncr.pfsyncr_maxupdates > 255) return (EINVAL); #ifdef __FreeBSD__ + callout_drain(&sc->sc_send_tmo); PF_LOCK(); #endif sc->sc_maxupdates =3D pfsyncr.pfsyncr_maxupdates; @@ -1789,15 +1794,14 @@ #endif =20 pfsyncstats.pfsyncs_opackets++; =2D #ifdef __FreeBSD__ =2D PF_UNLOCK(); =2D#endif + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) + pfsyncstats.pfsyncs_oerrors++; + else + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); +#else if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) pfsyncstats.pfsyncs_oerrors++; =2D =2D#ifdef __FreeBSD__ =2D PF_LOCK(); #endif } else m_freem(m); @@ -1807,6 +1811,22 @@ =20 =20 #ifdef __FreeBSD__ +static void +pfsync_senddef(void *arg) +{ + struct pfsync_softc *sc =3D (struct pfsync_softc *)arg; + struct mbuf *m; + + for(;;) { + IF_DEQUEUE(&sc->sc_ifq, m); + if (m =3D=3D NULL) + break; + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) + pfsyncstats.pfsyncs_oerrors++; + } +} + + static int pfsync_modevent(module_t mod, int type, void *data) { Index: if_pfsync.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v retrieving revision 1.5 diff -u -r1.5 if_pfsync.h =2D-- if_pfsync.h 3 May 2005 16:43:32 -0000 1.5 +++ if_pfsync.h 8 Jun 2005 14:06:03 -0000 @@ -164,6 +164,10 @@ struct in_addr sc_sendaddr; struct mbuf *sc_mbuf; /* current cumulative mbuf */ struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ +#ifdef __FreeBSD__ + struct ifqueue sc_ifq; + struct callout sc_send_tmo; +#endif union sc_statep sc_statep; union sc_statep sc_statep_net; u_int32_t sc_ureq_received; --Boundary-01=_c3vpCai3WMMzsSJ Content-Type: text/x-diff; charset="iso-8859-1"; name="if_pfsync.senddef5.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="if_pfsync.senddef5.diff" Index: if_pfsync.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v retrieving revision 1.11.2.2 diff -u -r1.11.2.2 if_pfsync.c =2D-- if_pfsync.c 19 May 2005 10:59:22 -0000 1.11.2.2 +++ if_pfsync.c 8 Jun 2005 14:07:17 -0000 @@ -130,6 +130,7 @@ =20 static void pfsync_clone_destroy(struct ifnet *); static int pfsync_clone_create(struct if_clone *, int); +static void pfsync_senddef(void *); #else void pfsyncattach(int); #endif @@ -170,6 +171,8 @@ callout_stop(&sc->sc_bulk_tmo); callout_stop(&sc->sc_bulkfail_tmo); =20 + callout_stop(&sc->sc_send_tmo); + #if NBPFILTER > 0 bpfdetach(ifp); #endif @@ -216,6 +219,7 @@ callout_init(&sc->sc_tmo, 0); callout_init(&sc->sc_bulk_tmo, 0); callout_init(&sc->sc_bulkfail_tmo, 0); + callout_init(&sc->sc_send_tmo, 0); if_attach(&sc->sc_if); =20 LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); @@ -913,6 +917,7 @@ if (pfsyncr.pfsyncr_maxupdates > 255) return (EINVAL); #ifdef __FreeBSD__ + callout_drain(&sc->sc_send_tmo); PF_LOCK(); #endif sc->sc_maxupdates =3D pfsyncr.pfsyncr_maxupdates; @@ -1634,15 +1639,14 @@ #endif =20 pfsyncstats.pfsyncs_opackets++; =2D #ifdef __FreeBSD__ =2D PF_UNLOCK(); =2D#endif + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) + pfsyncstats.pfsyncs_oerrors++; + else + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); +#else if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) pfsyncstats.pfsyncs_oerrors++; =2D =2D#ifdef __FreeBSD__ =2D PF_LOCK(); #endif } else m_freem(m); @@ -1652,6 +1656,22 @@ =20 =20 #ifdef __FreeBSD__ +static void +pfsync_senddef(void *arg) +{ + struct pfsync_softc *sc =3D (struct pfsync_softc *)arg; + struct mbuf *m; + + for(;;) { + IF_DEQUEUE(&sc->sc_ifq, m); + if (m =3D=3D NULL) + break; + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) + pfsyncstats.pfsyncs_oerrors++; + } +} + + static int pfsync_modevent(module_t mod, int type, void *data) { Index: if_pfsync.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v retrieving revision 1.4 diff -u -r1.4 if_pfsync.h =2D-- if_pfsync.h 16 Jun 2004 23:24:00 -0000 1.4 +++ if_pfsync.h 8 Jun 2005 14:07:48 -0000 @@ -158,8 +158,12 @@ struct timeout sc_bulkfail_tmo; #endif struct in_addr sc_sendaddr; =2D struct mbuf *sc_mbuf; /* current cummulative mbuf */ =2D struct mbuf *sc_mbuf_net; /* current cummulative mbuf */ + struct mbuf *sc_mbuf; /* current cumulative mbuf */ + struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ +#ifdef __FreeBSD__ + struct ifqueue sc_ifq; + struct callout sc_send_tmo; +#endif union sc_statep sc_statep; union sc_statep sc_statep_net; u_int32_t sc_ureq_received; --Boundary-01=_c3vpCai3WMMzsSJ-- --nextPart1125684.lrgfy40mCT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCpv3hXyyEoT62BG0RAjkbAJ9Q/uCUL4sZrVOaTgWe4qA2/3qEowCeIeji J/uis8u+MOLegOc8UWoaRb0= =SF3/ -----END PGP SIGNATURE----- --nextPart1125684.lrgfy40mCT-- From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 21:18:20 2005 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F72816A41C for ; Wed, 8 Jun 2005 21:18:20 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (zixvpm01.seton.org [207.193.126.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FBF243D1D for ; Wed, 8 Jun 2005 21:18:19 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (ZixVPM [127.0.0.1]) by Outbound.seton.org (Proprietary) with ESMTP id 20DEF3600CD for ; Wed, 8 Jun 2005 16:18:18 -0500 (CDT) Received: from mx1-out.seton.org (unknown [10.21.254.249]) by zixvpm01.seton.org (Proprietary) with ESMTP id B161033015A; Wed, 8 Jun 2005 15:27:57 -0500 (CDT) Received: from localhost (unknown [127.0.0.1]) by mx1-out.seton.org (Postfix) with ESMTP id 9DD028014E29; Wed, 8 Jun 2005 15:27:57 -0500 (CDT) Received: from mx1-out.seton.org ([10.21.254.249]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 21015-09; Wed, 8 Jun 2005 15:27:57 -0500 (CDT) Received: from ausexfe01.seton.org (ausexfe01.seton.org [10.20.10.211]) by mx1-out.seton.org (Postfix) with ESMTP id 837678014E25; Wed, 8 Jun 2005 15:27:57 -0500 (CDT) Received: from [10.20.160.190] ([10.20.160.190]) by ausexfe01.seton.org with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 15:26:35 -0500 Message-ID: <42A755A1.6030104@seton.org> Date: Wed, 08 Jun 2005 15:31:29 -0500 From: Matthew Grooms Organization: Seton Healthcare Network User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <28FCC7CB4CF6EA43AF83BCA2096E97D013E555@AUSEX2VS1.seton.org> <42A62F52.10705@seton.org> <200506081617.05938.max@love2party.net> In-Reply-To: <200506081617.05938.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2005 20:26:35.0843 (UTC) FILETIME=[5DF17130:01C56C68] X-Virus-Scanned: by amavisd-new at seton.org Cc: pf@freebsd.org, glebius@freebsd.org, freebsd-stable@freebsd.org, Palle Girgensohn , Kris Kennaway Subject: Re: 5.4-RELEASE lockups on amd64 SMP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 21:18:20 -0000 BTW : Had you tested pfsync between two SMP systems with decent traffic flow? It usually took about 3 days to hit the LOR but the panic shows up in about 10-20 minutes. Matthew Grooms Network Engineer Seton Healthcare Network http://www.seton.net/ mgrooms@seton.org (512) 324 9913 Max Laier wrote: > Matthew, > > can you try the attached diff. Available for 5 and CURRENT. I recall that > this problem was seen before, strange that I didn't see the problem. Sounds > familiar to you? Please try the patch and let me know if that helps. Thanks > a lot. > > On Wednesday 08 June 2005 01:35, Matthew Grooms wrote: > >>Once again, here are the backtraces for the panic and lor ... >> >>Tracing id 110 tid 100089 td 0xffffff012f3f0c80 >>kdb_enter() at kdb_enter+0x2f >>panic() at panic+0x249 >>uma_dbg_free() at uma_dbg_free+0x188 >>uma_zfree_arg() at uma_zfree_arg+0x1b0 >>pf_purge_expired_states() at pf_purge_expired_states+0x41 >>pfsync_input at pfsync_input+xb35 >>pf_input() at ip_input+0x10f >>netisr_processqueue() at netisr_processqueue+0x17 >>swi_net() at swi_net+0xa8 >>ithread_loop() at ithread_loop+0xd9 >>fork_exit() at fork_exit+0xc3 >>fork_trampoline() at fork_trampoline+0xe >>--- trap 0, rip = 0, rsp = 0xffffffffb44f9d00, rbp = 0 --- >>db> continue >>boot() called on cpu#0 >>Uptime: 13h42m43s >>Dumping 4864 MB >> 16 32 ... >> >>lock order reversal > > ... > >>alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5 >>pf_state_tree_lan_ext_RB_REMOVE() at pf_state_tree_lan_ext_RB_REMOVE+0x10c > > > This LOR is a consequence of the fault, so it can be disregarded. > > > > ------------------------------------------------------------------------ > > Index: if_pfsync.c > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v > retrieving revision 1.15 > diff -u -r1.15 if_pfsync.c > --- if_pfsync.c 3 May 2005 16:43:32 -0000 1.15 > +++ if_pfsync.c 8 Jun 2005 14:04:44 -0000 > @@ -132,6 +132,7 @@ > > static void pfsync_clone_destroy(struct ifnet *); > static int pfsync_clone_create(struct if_clone *, int); > +static void pfsync_senddef(void *); > #else > void pfsyncattach(int); > #endif > @@ -174,6 +175,8 @@ > callout_stop(&sc->sc_bulk_tmo); > callout_stop(&sc->sc_bulkfail_tmo); > > + callout_stop(&sc->sc_send_tmo); > + > #if NBPFILTER > 0 > bpfdetach(ifp); > #endif > @@ -220,6 +223,7 @@ > callout_init(&sc->sc_tmo, 0); > callout_init(&sc->sc_bulk_tmo, 0); > callout_init(&sc->sc_bulkfail_tmo, 0); > + callout_init(&sc->sc_send_tmo, 0); > if_attach(ifp); > > LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); > @@ -1033,6 +1037,7 @@ > if (pfsyncr.pfsyncr_maxupdates > 255) > return (EINVAL); > #ifdef __FreeBSD__ > + callout_drain(&sc->sc_send_tmo); > PF_LOCK(); > #endif > sc->sc_maxupdates = pfsyncr.pfsyncr_maxupdates; > @@ -1789,15 +1794,14 @@ > #endif > > pfsyncstats.pfsyncs_opackets++; > - > #ifdef __FreeBSD__ > - PF_UNLOCK(); > -#endif > + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + else > + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); > +#else > if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > pfsyncstats.pfsyncs_oerrors++; > - > -#ifdef __FreeBSD__ > - PF_LOCK(); > #endif > } else > m_freem(m); > @@ -1807,6 +1811,22 @@ > > > #ifdef __FreeBSD__ > +static void > +pfsync_senddef(void *arg) > +{ > + struct pfsync_softc *sc = (struct pfsync_softc *)arg; > + struct mbuf *m; > + > + for(;;) { > + IF_DEQUEUE(&sc->sc_ifq, m); > + if (m == NULL) > + break; > + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + } > +} > + > + > static int > pfsync_modevent(module_t mod, int type, void *data) > { > Index: if_pfsync.h > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v > retrieving revision 1.5 > diff -u -r1.5 if_pfsync.h > --- if_pfsync.h 3 May 2005 16:43:32 -0000 1.5 > +++ if_pfsync.h 8 Jun 2005 14:06:03 -0000 > @@ -164,6 +164,10 @@ > struct in_addr sc_sendaddr; > struct mbuf *sc_mbuf; /* current cumulative mbuf */ > struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ > +#ifdef __FreeBSD__ > + struct ifqueue sc_ifq; > + struct callout sc_send_tmo; > +#endif > union sc_statep sc_statep; > union sc_statep sc_statep_net; > u_int32_t sc_ureq_received; > > > ------------------------------------------------------------------------ > > Index: if_pfsync.c > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v > retrieving revision 1.11.2.2 > diff -u -r1.11.2.2 if_pfsync.c > --- if_pfsync.c 19 May 2005 10:59:22 -0000 1.11.2.2 > +++ if_pfsync.c 8 Jun 2005 14:07:17 -0000 > @@ -130,6 +130,7 @@ > > static void pfsync_clone_destroy(struct ifnet *); > static int pfsync_clone_create(struct if_clone *, int); > +static void pfsync_senddef(void *); > #else > void pfsyncattach(int); > #endif > @@ -170,6 +171,8 @@ > callout_stop(&sc->sc_bulk_tmo); > callout_stop(&sc->sc_bulkfail_tmo); > > + callout_stop(&sc->sc_send_tmo); > + > #if NBPFILTER > 0 > bpfdetach(ifp); > #endif > @@ -216,6 +219,7 @@ > callout_init(&sc->sc_tmo, 0); > callout_init(&sc->sc_bulk_tmo, 0); > callout_init(&sc->sc_bulkfail_tmo, 0); > + callout_init(&sc->sc_send_tmo, 0); > if_attach(&sc->sc_if); > > LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); > @@ -913,6 +917,7 @@ > if (pfsyncr.pfsyncr_maxupdates > 255) > return (EINVAL); > #ifdef __FreeBSD__ > + callout_drain(&sc->sc_send_tmo); > PF_LOCK(); > #endif > sc->sc_maxupdates = pfsyncr.pfsyncr_maxupdates; > @@ -1634,15 +1639,14 @@ > #endif > > pfsyncstats.pfsyncs_opackets++; > - > #ifdef __FreeBSD__ > - PF_UNLOCK(); > -#endif > + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + else > + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); > +#else > if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > pfsyncstats.pfsyncs_oerrors++; > - > -#ifdef __FreeBSD__ > - PF_LOCK(); > #endif > } else > m_freem(m); > @@ -1652,6 +1656,22 @@ > > > #ifdef __FreeBSD__ > +static void > +pfsync_senddef(void *arg) > +{ > + struct pfsync_softc *sc = (struct pfsync_softc *)arg; > + struct mbuf *m; > + > + for(;;) { > + IF_DEQUEUE(&sc->sc_ifq, m); > + if (m == NULL) > + break; > + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + } > +} > + > + > static int > pfsync_modevent(module_t mod, int type, void *data) > { > Index: if_pfsync.h > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v > retrieving revision 1.4 > diff -u -r1.4 if_pfsync.h > --- if_pfsync.h 16 Jun 2004 23:24:00 -0000 1.4 > +++ if_pfsync.h 8 Jun 2005 14:07:48 -0000 > @@ -158,8 +158,12 @@ > struct timeout sc_bulkfail_tmo; > #endif > struct in_addr sc_sendaddr; > - struct mbuf *sc_mbuf; /* current cummulative mbuf */ > - struct mbuf *sc_mbuf_net; /* current cummulative mbuf */ > + struct mbuf *sc_mbuf; /* current cumulative mbuf */ > + struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ > +#ifdef __FreeBSD__ > + struct ifqueue sc_ifq; > + struct callout sc_send_tmo; > +#endif > union sc_statep sc_statep; > union sc_statep sc_statep_net; > u_int32_t sc_ureq_received; From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 21:42:12 2005 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C69A16A41C for ; Wed, 8 Jun 2005 21:42:12 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (zixvpm01.seton.org [207.193.126.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 877EE43D48 for ; Wed, 8 Jun 2005 21:42:11 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (ZixVPM [127.0.0.1]) by Outbound.seton.org (Proprietary) with ESMTP id 1ED193600D7 for ; Wed, 8 Jun 2005 16:42:11 -0500 (CDT) Received: from mx1-out.seton.org (unknown [10.21.254.249]) by zixvpm01.seton.org (Proprietary) with ESMTP id 7DEA633017C; Wed, 8 Jun 2005 15:46:34 -0500 (CDT) Received: from localhost (unknown [127.0.0.1]) by mx1-out.seton.org (Postfix) with ESMTP id 71CF18014E25; Wed, 8 Jun 2005 15:46:34 -0500 (CDT) Received: from mx1-out.seton.org ([10.21.254.249]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 20889-32; Wed, 8 Jun 2005 15:46:34 -0500 (CDT) Received: from ausexfe01.seton.org (ausexfe01.seton.org [10.20.10.211]) by mx1-out.seton.org (Postfix) with ESMTP id DD7AE8014E24; Wed, 8 Jun 2005 15:46:33 -0500 (CDT) Received: from [10.20.160.190] ([10.20.160.190]) by ausexfe01.seton.org with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 15:46:33 -0500 Message-ID: <42A75A4E.2050402@seton.org> Date: Wed, 08 Jun 2005 15:51:26 -0500 From: Matthew Grooms Organization: Seton Healthcare Network User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <28FCC7CB4CF6EA43AF83BCA2096E97D013E555@AUSEX2VS1.seton.org> <42A62F52.10705@seton.org> <200506081617.05938.max@love2party.net> In-Reply-To: <200506081617.05938.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2005 20:46:33.0283 (UTC) FILETIME=[27AC4930:01C56C6B] X-Virus-Scanned: by amavisd-new at seton.org Cc: pf@freebsd.org, glebius@freebsd.org, freebsd-stable@freebsd.org, Palle Girgensohn , Kris Kennaway Subject: Re: 5.4-RELEASE lockups on amd64 SMP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 21:42:12 -0000 Are these available for download somewhere? I am getting rejected chunks and I suspect it may be the mail client I am using. This does apply cleanly to 5.4-RELEASE correct? Matthew Grooms Network Engineer Seton Healthcare Network http://www.seton.net/ mgrooms@seton.org (512) 324 9913 Max Laier wrote: > Matthew, > > can you try the attached diff. Available for 5 and CURRENT. I recall that > this problem was seen before, strange that I didn't see the problem. Sounds > familiar to you? Please try the patch and let me know if that helps. Thanks > a lot. > > On Wednesday 08 June 2005 01:35, Matthew Grooms wrote: > >>Once again, here are the backtraces for the panic and lor ... >> >>Tracing id 110 tid 100089 td 0xffffff012f3f0c80 >>kdb_enter() at kdb_enter+0x2f >>panic() at panic+0x249 >>uma_dbg_free() at uma_dbg_free+0x188 >>uma_zfree_arg() at uma_zfree_arg+0x1b0 >>pf_purge_expired_states() at pf_purge_expired_states+0x41 >>pfsync_input at pfsync_input+xb35 >>pf_input() at ip_input+0x10f >>netisr_processqueue() at netisr_processqueue+0x17 >>swi_net() at swi_net+0xa8 >>ithread_loop() at ithread_loop+0xd9 >>fork_exit() at fork_exit+0xc3 >>fork_trampoline() at fork_trampoline+0xe >>--- trap 0, rip = 0, rsp = 0xffffffffb44f9d00, rbp = 0 --- >>db> continue >>boot() called on cpu#0 >>Uptime: 13h42m43s >>Dumping 4864 MB >> 16 32 ... >> >>lock order reversal > > ... > >>alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5 >>pf_state_tree_lan_ext_RB_REMOVE() at pf_state_tree_lan_ext_RB_REMOVE+0x10c > > > This LOR is a consequence of the fault, so it can be disregarded. > > > > ------------------------------------------------------------------------ > > Index: if_pfsync.c > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v > retrieving revision 1.15 > diff -u -r1.15 if_pfsync.c > --- if_pfsync.c 3 May 2005 16:43:32 -0000 1.15 > +++ if_pfsync.c 8 Jun 2005 14:04:44 -0000 > @@ -132,6 +132,7 @@ > > static void pfsync_clone_destroy(struct ifnet *); > static int pfsync_clone_create(struct if_clone *, int); > +static void pfsync_senddef(void *); > #else > void pfsyncattach(int); > #endif > @@ -174,6 +175,8 @@ > callout_stop(&sc->sc_bulk_tmo); > callout_stop(&sc->sc_bulkfail_tmo); > > + callout_stop(&sc->sc_send_tmo); > + > #if NBPFILTER > 0 > bpfdetach(ifp); > #endif > @@ -220,6 +223,7 @@ > callout_init(&sc->sc_tmo, 0); > callout_init(&sc->sc_bulk_tmo, 0); > callout_init(&sc->sc_bulkfail_tmo, 0); > + callout_init(&sc->sc_send_tmo, 0); > if_attach(ifp); > > LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); > @@ -1033,6 +1037,7 @@ > if (pfsyncr.pfsyncr_maxupdates > 255) > return (EINVAL); > #ifdef __FreeBSD__ > + callout_drain(&sc->sc_send_tmo); > PF_LOCK(); > #endif > sc->sc_maxupdates = pfsyncr.pfsyncr_maxupdates; > @@ -1789,15 +1794,14 @@ > #endif > > pfsyncstats.pfsyncs_opackets++; > - > #ifdef __FreeBSD__ > - PF_UNLOCK(); > -#endif > + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + else > + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); > +#else > if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > pfsyncstats.pfsyncs_oerrors++; > - > -#ifdef __FreeBSD__ > - PF_LOCK(); > #endif > } else > m_freem(m); > @@ -1807,6 +1811,22 @@ > > > #ifdef __FreeBSD__ > +static void > +pfsync_senddef(void *arg) > +{ > + struct pfsync_softc *sc = (struct pfsync_softc *)arg; > + struct mbuf *m; > + > + for(;;) { > + IF_DEQUEUE(&sc->sc_ifq, m); > + if (m == NULL) > + break; > + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + } > +} > + > + > static int > pfsync_modevent(module_t mod, int type, void *data) > { > Index: if_pfsync.h > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v > retrieving revision 1.5 > diff -u -r1.5 if_pfsync.h > --- if_pfsync.h 3 May 2005 16:43:32 -0000 1.5 > +++ if_pfsync.h 8 Jun 2005 14:06:03 -0000 > @@ -164,6 +164,10 @@ > struct in_addr sc_sendaddr; > struct mbuf *sc_mbuf; /* current cumulative mbuf */ > struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ > +#ifdef __FreeBSD__ > + struct ifqueue sc_ifq; > + struct callout sc_send_tmo; > +#endif > union sc_statep sc_statep; > union sc_statep sc_statep_net; > u_int32_t sc_ureq_received; > > > ------------------------------------------------------------------------ > > Index: if_pfsync.c > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v > retrieving revision 1.11.2.2 > diff -u -r1.11.2.2 if_pfsync.c > --- if_pfsync.c 19 May 2005 10:59:22 -0000 1.11.2.2 > +++ if_pfsync.c 8 Jun 2005 14:07:17 -0000 > @@ -130,6 +130,7 @@ > > static void pfsync_clone_destroy(struct ifnet *); > static int pfsync_clone_create(struct if_clone *, int); > +static void pfsync_senddef(void *); > #else > void pfsyncattach(int); > #endif > @@ -170,6 +171,8 @@ > callout_stop(&sc->sc_bulk_tmo); > callout_stop(&sc->sc_bulkfail_tmo); > > + callout_stop(&sc->sc_send_tmo); > + > #if NBPFILTER > 0 > bpfdetach(ifp); > #endif > @@ -216,6 +219,7 @@ > callout_init(&sc->sc_tmo, 0); > callout_init(&sc->sc_bulk_tmo, 0); > callout_init(&sc->sc_bulkfail_tmo, 0); > + callout_init(&sc->sc_send_tmo, 0); > if_attach(&sc->sc_if); > > LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); > @@ -913,6 +917,7 @@ > if (pfsyncr.pfsyncr_maxupdates > 255) > return (EINVAL); > #ifdef __FreeBSD__ > + callout_drain(&sc->sc_send_tmo); > PF_LOCK(); > #endif > sc->sc_maxupdates = pfsyncr.pfsyncr_maxupdates; > @@ -1634,15 +1639,14 @@ > #endif > > pfsyncstats.pfsyncs_opackets++; > - > #ifdef __FreeBSD__ > - PF_UNLOCK(); > -#endif > + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + else > + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); > +#else > if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > pfsyncstats.pfsyncs_oerrors++; > - > -#ifdef __FreeBSD__ > - PF_LOCK(); > #endif > } else > m_freem(m); > @@ -1652,6 +1656,22 @@ > > > #ifdef __FreeBSD__ > +static void > +pfsync_senddef(void *arg) > +{ > + struct pfsync_softc *sc = (struct pfsync_softc *)arg; > + struct mbuf *m; > + > + for(;;) { > + IF_DEQUEUE(&sc->sc_ifq, m); > + if (m == NULL) > + break; > + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + } > +} > + > + > static int > pfsync_modevent(module_t mod, int type, void *data) > { > Index: if_pfsync.h > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v > retrieving revision 1.4 > diff -u -r1.4 if_pfsync.h > --- if_pfsync.h 16 Jun 2004 23:24:00 -0000 1.4 > +++ if_pfsync.h 8 Jun 2005 14:07:48 -0000 > @@ -158,8 +158,12 @@ > struct timeout sc_bulkfail_tmo; > #endif > struct in_addr sc_sendaddr; > - struct mbuf *sc_mbuf; /* current cummulative mbuf */ > - struct mbuf *sc_mbuf_net; /* current cummulative mbuf */ > + struct mbuf *sc_mbuf; /* current cumulative mbuf */ > + struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ > +#ifdef __FreeBSD__ > + struct ifqueue sc_ifq; > + struct callout sc_send_tmo; > +#endif > union sc_statep sc_statep; > union sc_statep sc_statep_net; > u_int32_t sc_ureq_received; From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 23:22:52 2005 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BBAA16A41C for ; Wed, 8 Jun 2005 23:22:52 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (zixvpm01.seton.org [207.193.126.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD3343D53 for ; Wed, 8 Jun 2005 23:22:50 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (ZixVPM [127.0.0.1]) by Outbound.seton.org (Proprietary) with ESMTP id 65FA33600CD for ; Wed, 8 Jun 2005 18:22:50 -0500 (CDT) Received: from mx2-out.seton.org (unknown [10.21.254.241]) by zixvpm01.seton.org (Proprietary) with ESMTP id F1B2D33005A; Wed, 8 Jun 2005 18:22:48 -0500 (CDT) Received: from localhost (unknown [127.0.0.1]) by mx2-out.seton.org (Postfix) with ESMTP id E4BD2866; Wed, 8 Jun 2005 18:22:48 -0500 (CDT) Received: from mx2-out.seton.org ([10.21.254.241]) by localhost (mx2 [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 30302-47; Wed, 8 Jun 2005 18:22:48 -0500 (CDT) Received: from ausexfe02.seton.org (unknown [10.20.10.186]) by mx2-out.seton.org (Postfix) with ESMTP id 982B27C5; Wed, 8 Jun 2005 18:22:48 -0500 (CDT) Received: from AUSEX2VS1.seton.org ([10.20.10.74]) by ausexfe02.seton.org with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 18:22:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Jun 2005 18:22:48 -0500 Message-ID: <28FCC7CB4CF6EA43AF83BCA2096E97D013E562@AUSEX2VS1.seton.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.4-RELEASE lockups on amd64 SMP Thread-Index: AcVsNMiyFNlXC+NBTTGZHcmjZddM7wASRnT9 From: "Grooms, Matthew" To: "Max Laier" X-OriginalArrivalTime: 08 Jun 2005 23:22:48.0775 (UTC) FILETIME=[FBE6D570:01C56C80] X-Virus-Scanned: by amavisd-new at seton.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pf@freebsd.org, glebius@freebsd.org, freebsd-stable@freebsd.org, Palle Girgensohn , Kris Kennaway Subject: RE: 5.4-RELEASE lockups on amd64 SMP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 23:22:52 -0000 Matthew, can you try the attached diff. Available for 5 and CURRENT. I recall = that=20 this problem was seen before, strange that I didn't see the problem. = Sounds=20 familiar to you? Please try the patch and let me know if that helps. = Thanks=20 a lot. On Wednesday 08 June 2005 01:35, Matthew Grooms wrote: > Once again, here are the backtraces for the panic and lor ... > > Tracing id 110 tid 100089 td 0xffffff012f3f0c80 > kdb_enter() at kdb_enter+0x2f > panic() at panic+0x249 > uma_dbg_free() at uma_dbg_free+0x188 > uma_zfree_arg() at uma_zfree_arg+0x1b0 > pf_purge_expired_states() at pf_purge_expired_states+0x41 > pfsync_input at pfsync_input+xb35 > pf_input() at ip_input+0x10f > netisr_processqueue() at netisr_processqueue+0x17 > swi_net() at swi_net+0xa8 > ithread_loop() at ithread_loop+0xd9 > fork_exit() at fork_exit+0xc3 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffffffb44f9d00, rbp =3D 0 --- > db> continue > boot() called on cpu#0 > Uptime: 13h42m43s > Dumping 4864 MB > 16 32 ... > > lock order reversal ... > alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5 > pf_state_tree_lan_ext_RB_REMOVE() at = pf_state_tree_lan_ext_RB_REMOVE+0x10c This LOR is a consequence of the fault, so it can be disregarded. --=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 From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 23:23:44 2005 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3941716A41F for ; Wed, 8 Jun 2005 23:23:44 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (zixvpm01.seton.org [207.193.126.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62ACC43D48 for ; Wed, 8 Jun 2005 23:23:42 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (ZixVPM [127.0.0.1]) by Outbound.seton.org (Proprietary) with ESMTP id 0D5EB3600C1 for ; Wed, 8 Jun 2005 18:23:42 -0500 (CDT) Received: from mx1-out.seton.org (unknown [10.21.254.249]) by zixvpm01.seton.org (Proprietary) with ESMTP id A89AC33005A; Wed, 8 Jun 2005 18:23:41 -0500 (CDT) Received: from localhost (unknown [127.0.0.1]) by mx1-out.seton.org (Postfix) with ESMTP id 9B4F58014E25; Wed, 8 Jun 2005 18:23:41 -0500 (CDT) Received: from mx1-out.seton.org ([10.21.254.249]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 21531-33; Wed, 8 Jun 2005 18:23:41 -0500 (CDT) Received: from ausexfe01.seton.org (ausexfe01.seton.org [10.20.10.211]) by mx1-out.seton.org (Postfix) with ESMTP id 513A78014E24; Wed, 8 Jun 2005 18:23:41 -0500 (CDT) Received: from AUSEX2VS1.seton.org ([10.20.10.74]) by ausexfe01.seton.org with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 18:23:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Jun 2005 18:23:15 -0500 Message-ID: <28FCC7CB4CF6EA43AF83BCA2096E97D013E563@AUSEX2VS1.seton.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.4-RELEASE lockups on amd64 SMP Thread-Index: AcVsNMiyFNlXC+NBTTGZHcmjZddM7wASRnT9AADKZIg= From: "Grooms, Matthew" To: "Grooms, Matthew" , "Max Laier" X-OriginalArrivalTime: 08 Jun 2005 23:23:40.0014 (UTC) FILETIME=[1A7148E0:01C56C81] X-Virus-Scanned: by amavisd-new at seton.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pf@freebsd.org, glebius@freebsd.org, freebsd-stable@freebsd.org, Palle Girgensohn , Kris Kennaway Subject: RE: 5.4-RELEASE lockups on amd64 SMP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 23:23:44 -0000 Max, With your patch applied, I get a panic very quickly during the boot = cycle with output that looks like this ... net.inet.carp.preempt: 0 -> 1 Setting hostname: ---. em: Link is up 100 Mbps Full Duplex panic: mtx_lock() of spin mutex (null) @ ../../../net/if.c:1983 cpuid =3D 1 KDB: enter: panic [thread pid 282 tid 100157 ] Stopped at kdb_enter+0x2f: nop db> trace Tracing pid 282 tid 100157 td 0xffffff000af78280 kdb_enter() at kdb_enter+0x2f panic() at panic+0x249 _mtx_lock_flags() at _mtx_lock_flags+0xd6 if_handoff() at if_handoff+0x49 pfsync_sendout() at pfsync_sendout+0x268 pfsyncioctl() at pfsyncioctl+0x497 in_control() at in_control+0x8cb ifioctl() at ifioctl+0x178 sooo_ioctl() at soo_ioctl+0x2d6 ioctl() at ioctl+0xfc syscall() at syscall+0x4ab Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x800793340, rsp =3D = 0x7fffffffeca8, rbp =3D 0x7fffffffef8b --- db> show locks eclusive sleep mutex pf task mtx r =3D 0 (0xffffffff80752f60) locked @ = contrib/pf/net/if_pfsync.c:973 Rebooting the machine with the same kernel produces an identical panic. = Let me know what else I can do to help. Right now I have just been = rebooting back to a UP kernel which has never shown any sign of = problems. Matthew Grooms -----Original Message----- From: Grooms, Matthew Sent: Wed 6/8/2005 6:22 PM To: Max Laier Cc: Palle Girgensohn; Kris Kennaway; freebsd-stable@freebsd.org; = glebius@freebsd.org; pf@freebsd.org Subject: RE: 5.4-RELEASE lockups on amd64 SMP =20 Matthew, can you try the attached diff. Available for 5 and CURRENT. I recall = that=20 this problem was seen before, strange that I didn't see the problem. = Sounds=20 familiar to you? Please try the patch and let me know if that helps. = Thanks=20 a lot. On Wednesday 08 June 2005 01:35, Matthew Grooms wrote: > Once again, here are the backtraces for the panic and lor ... > > Tracing id 110 tid 100089 td 0xffffff012f3f0c80 > kdb_enter() at kdb_enter+0x2f > panic() at panic+0x249 > uma_dbg_free() at uma_dbg_free+0x188 > uma_zfree_arg() at uma_zfree_arg+0x1b0 > pf_purge_expired_states() at pf_purge_expired_states+0x41 > pfsync_input at pfsync_input+xb35 > pf_input() at ip_input+0x10f > netisr_processqueue() at netisr_processqueue+0x17 > swi_net() at swi_net+0xa8 > ithread_loop() at ithread_loop+0xd9 > fork_exit() at fork_exit+0xc3 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffffffb44f9d00, rbp =3D 0 --- > db> continue > boot() called on cpu#0 > Uptime: 13h42m43s > Dumping 4864 MB > 16 32 ... > > lock order reversal ... > alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5 > pf_state_tree_lan_ext_RB_REMOVE() at = pf_state_tree_lan_ext_RB_REMOVE+0x10c This LOR is a consequence of the fault, so it can be disregarded. --=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 From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 23:45:07 2005 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C7A616A41C; Wed, 8 Jun 2005 23:45:07 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBDD243D4C; Wed, 8 Jun 2005 23:45:06 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3B6F5.dip.t-dialin.net [84.163.182.245] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML29c-1DgAEH0Vl6-0002pi; Thu, 09 Jun 2005 01:45:01 +0200 From: Max Laier To: "Grooms, Matthew" Date: Thu, 9 Jun 2005 01:44:51 +0200 User-Agent: KMail/1.8 References: <28FCC7CB4CF6EA43AF83BCA2096E97D013E563@AUSEX2VS1.seton.org> In-Reply-To: <28FCC7CB4CF6EA43AF83BCA2096E97D013E563@AUSEX2VS1.seton.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1672662.2lLyzc9e6N"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506090145.00312.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: pf@freebsd.org, glebius@freebsd.org, freebsd-stable@freebsd.org, Palle Girgensohn , Kris Kennaway Subject: Re: 5.4-RELEASE lockups on amd64 SMP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 23:45:07 -0000 --nextPart1672662.2lLyzc9e6N Content-Type: multipart/mixed; boundary="Boundary-01=_3L4pC7cVZTD1gQi" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_3L4pC7cVZTD1gQi Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 09 June 2005 01:23, Grooms, Matthew wrote: > Max, > > With your patch applied, I get a panic very quickly during the boot > cycle with output that looks like this ... My bad, missed the mtx_init() ...=20 | @@ -216,6 +219,9 @@ | callout_init(&sc->sc_tmo, 0); | callout_init(&sc->sc_bulk_tmo, 0); | callout_init(&sc->sc_bulkfail_tmo, 0); | + callout_init(&sc->sc_send_tmo, 0); | + mtx_init(&sc->sc_ifq.ifq_mtx, ifp->if_xname, "pfsync send queue", | + MTX_DEF); | if_attach(&sc->sc_if); | =20 | LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); Complete updated patch attached and uploaded to: http://people.freebsd.org/~mlaier/if_pfsync.senddef5.diff Sorry. > net.inet.carp.preempt: 0 -> 1 > Setting hostname: ---. > em: Link is up 100 Mbps Full Duplex > panic: mtx_lock() of spin mutex (null) @ ../../../net/if.c:1983 > cpuid =3D 1 > KDB: enter: panic > [thread pid 282 tid 100157 ] > Stopped at kdb_enter+0x2f: nop > db> trace > Tracing pid 282 tid 100157 td 0xffffff000af78280 > kdb_enter() at kdb_enter+0x2f > panic() at panic+0x249 > _mtx_lock_flags() at _mtx_lock_flags+0xd6 > if_handoff() at if_handoff+0x49 > pfsync_sendout() at pfsync_sendout+0x268 > pfsyncioctl() at pfsyncioctl+0x497 > in_control() at in_control+0x8cb > ifioctl() at ifioctl+0x178 > sooo_ioctl() at soo_ioctl+0x2d6 > ioctl() at ioctl+0xfc > syscall() at syscall+0x4ab > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x800793340, rsp =3D > 0x7fffffffeca8, rbp =3D 0x7fffffffef8b --- db> show locks > eclusive sleep mutex pf task mtx r =3D 0 (0xffffffff80752f60) locked @ > contrib/pf/net/if_pfsync.c:973 > > Rebooting the machine with the same kernel produces an identical panic. L= et > me know what else I can do to help. Right now I have just been rebooting > back to a UP kernel which has never shown any sign of problems. > > Matthew Grooms > > -----Original Message----- > From: Grooms, Matthew > Sent: Wed 6/8/2005 6:22 PM > To: Max Laier > Cc: Palle Girgensohn; Kris Kennaway; freebsd-stable@freebsd.org; > glebius@freebsd.org; pf@freebsd.org Subject: RE: 5.4-RELEASE lockups on > amd64 SMP > > Matthew, > > can you try the attached diff. Available for 5 and CURRENT. I recall th= at > this problem was seen before, strange that I didn't see the problem.=20 > Sounds familiar to you? Please try the patch and let me know if that > helps. Thanks a lot. > > On Wednesday 08 June 2005 01:35, Matthew Grooms wrote: > > Once again, here are the backtraces for the panic and lor ... > > > > Tracing id 110 tid 100089 td 0xffffff012f3f0c80 > > kdb_enter() at kdb_enter+0x2f > > panic() at panic+0x249 > > uma_dbg_free() at uma_dbg_free+0x188 > > uma_zfree_arg() at uma_zfree_arg+0x1b0 > > pf_purge_expired_states() at pf_purge_expired_states+0x41 > > pfsync_input at pfsync_input+xb35 > > pf_input() at ip_input+0x10f > > netisr_processqueue() at netisr_processqueue+0x17 > > swi_net() at swi_net+0xa8 > > ithread_loop() at ithread_loop+0xd9 > > fork_exit() at fork_exit+0xc3 > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip =3D 0, rsp =3D 0xffffffffb44f9d00, rbp =3D 0 --- > > db> continue > > boot() called on cpu#0 > > Uptime: 13h42m43s > > Dumping 4864 MB > > 16 32 ... > > > > lock order reversal > > ... > > > alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5 > > pf_state_tree_lan_ext_RB_REMOVE() at > > pf_state_tree_lan_ext_RB_REMOVE+0x10c > > This LOR is a consequence of the fault, so it can be disregarded. =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 --Boundary-01=_3L4pC7cVZTD1gQi Content-Type: text/x-diff; charset="iso-8859-6"; name="if_pfsync.senddef5.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="if_pfsync.senddef5.diff" Index: if_pfsync.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v retrieving revision 1.11.2.2 diff -u -r1.11.2.2 if_pfsync.c =2D-- if_pfsync.c 19 May 2005 10:59:22 -0000 1.11.2.2 +++ if_pfsync.c 8 Jun 2005 23:42:45 -0000 @@ -130,6 +130,7 @@ =20 static void pfsync_clone_destroy(struct ifnet *); static int pfsync_clone_create(struct if_clone *, int); +static void pfsync_senddef(void *); #else void pfsyncattach(int); #endif @@ -170,6 +171,8 @@ callout_stop(&sc->sc_bulk_tmo); callout_stop(&sc->sc_bulkfail_tmo); =20 + callout_stop(&sc->sc_send_tmo); + #if NBPFILTER > 0 bpfdetach(ifp); #endif @@ -216,6 +219,9 @@ callout_init(&sc->sc_tmo, 0); callout_init(&sc->sc_bulk_tmo, 0); callout_init(&sc->sc_bulkfail_tmo, 0); + callout_init(&sc->sc_send_tmo, 0); + mtx_init(&sc->sc_ifq.ifq_mtx, ifp->if_xname, "pfsync send queue", + MTX_DEF); if_attach(&sc->sc_if); =20 LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); @@ -913,6 +919,7 @@ if (pfsyncr.pfsyncr_maxupdates > 255) return (EINVAL); #ifdef __FreeBSD__ + callout_drain(&sc->sc_send_tmo); PF_LOCK(); #endif sc->sc_maxupdates =3D pfsyncr.pfsyncr_maxupdates; @@ -1634,15 +1641,14 @@ #endif =20 pfsyncstats.pfsyncs_opackets++; =2D #ifdef __FreeBSD__ =2D PF_UNLOCK(); =2D#endif + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) + pfsyncstats.pfsyncs_oerrors++; + else + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); +#else if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) pfsyncstats.pfsyncs_oerrors++; =2D =2D#ifdef __FreeBSD__ =2D PF_LOCK(); #endif } else m_freem(m); @@ -1652,6 +1658,22 @@ =20 =20 #ifdef __FreeBSD__ +static void +pfsync_senddef(void *arg) +{ + struct pfsync_softc *sc =3D (struct pfsync_softc *)arg; + struct mbuf *m; + + for(;;) { + IF_DEQUEUE(&sc->sc_ifq, m); + if (m =3D=3D NULL) + break; + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) + pfsyncstats.pfsyncs_oerrors++; + } +} + + static int pfsync_modevent(module_t mod, int type, void *data) { Index: if_pfsync.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v retrieving revision 1.4 diff -u -r1.4 if_pfsync.h =2D-- if_pfsync.h 16 Jun 2004 23:24:00 -0000 1.4 +++ if_pfsync.h 8 Jun 2005 23:42:59 -0000 @@ -158,8 +158,12 @@ struct timeout sc_bulkfail_tmo; #endif struct in_addr sc_sendaddr; =2D struct mbuf *sc_mbuf; /* current cummulative mbuf */ =2D struct mbuf *sc_mbuf_net; /* current cummulative mbuf */ + struct mbuf *sc_mbuf; /* current cumulative mbuf */ + struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ +#ifdef __FreeBSD__ + struct ifqueue sc_ifq; + struct callout sc_send_tmo; +#endif union sc_statep sc_statep; union sc_statep sc_statep_net; u_int32_t sc_ureq_received; --Boundary-01=_3L4pC7cVZTD1gQi-- --nextPart1672662.2lLyzc9e6N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCp4L8XyyEoT62BG0RAnthAJ9AmLndEOMBEkELsSzdDeFL0/2HPwCfVPy5 BibjHx55kNPwyxCAAXAQZTc= =HmTx -----END PGP SIGNATURE----- --nextPart1672662.2lLyzc9e6N-- From owner-freebsd-pf@FreeBSD.ORG Thu Jun 9 13:47:18 2005 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D01D16A41C for ; Thu, 9 Jun 2005 13:47:18 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (zixvpm01.seton.org [207.193.126.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B07043D1F for ; Thu, 9 Jun 2005 13:47:16 +0000 (GMT) (envelope-from mgrooms@seton.org) Received: from zixvpm01.seton.org (ZixVPM [127.0.0.1]) by Outbound.seton.org (Proprietary) with ESMTP id 2682E3600E4 for ; Thu, 9 Jun 2005 08:47:16 -0500 (CDT) Received: from mx1-out.seton.org (unknown [10.21.254.249]) by zixvpm01.seton.org (Proprietary) with ESMTP id BD86A330059; Thu, 9 Jun 2005 08:47:15 -0500 (CDT) Received: from localhost (unknown [127.0.0.1]) by mx1-out.seton.org (Postfix) with ESMTP id B24388014E25; Thu, 9 Jun 2005 08:47:15 -0500 (CDT) Received: from mx1-out.seton.org ([10.21.254.249]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 27008-21; Thu, 9 Jun 2005 08:47:15 -0500 (CDT) Received: from ausexfe01.seton.org (ausexfe01.seton.org [10.20.10.211]) by mx1-out.seton.org (Postfix) with ESMTP id 9858E8014E24; Thu, 9 Jun 2005 08:47:15 -0500 (CDT) Received: from [10.20.160.190] ([10.20.160.190]) by ausexfe01.seton.org with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 08:47:15 -0500 Message-ID: <42A84988.5030608@seton.org> Date: Thu, 09 Jun 2005 08:52:08 -0500 From: Matthew Grooms Organization: Seton Healthcare Network User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <28FCC7CB4CF6EA43AF83BCA2096E97D013E563@AUSEX2VS1.seton.org> <200506090145.00312.max@love2party.net> In-Reply-To: <200506090145.00312.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2005 13:47:15.0515 (UTC) FILETIME=[BEE348B0:01C56CF9] X-Virus-Scanned: by amavisd-new at seton.org Cc: pf@freebsd.org, glebius@freebsd.org, freebsd-stable@freebsd.org, Palle Girgensohn , Kris Kennaway Subject: Re: 5.4-RELEASE lockups on amd64 SMP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 13:47:18 -0000 Max, Not a problem. Looks good so far. Its been up for an hour or a half with all the debug options turned on. I will let it cook in my production environment over the weekend and update you on Monday. Thanks for your help. Matthew Grooms Max Laier wrote: > On Thursday 09 June 2005 01:23, Grooms, Matthew wrote: > >>Max, >> >> With your patch applied, I get a panic very quickly during the boot >>cycle with output that looks like this ... > > > My bad, missed the mtx_init() ... > | @@ -216,6 +219,9 @@ > | callout_init(&sc->sc_tmo, 0); > | callout_init(&sc->sc_bulk_tmo, 0); > | callout_init(&sc->sc_bulkfail_tmo, 0); > | + callout_init(&sc->sc_send_tmo, 0); > | + mtx_init(&sc->sc_ifq.ifq_mtx, ifp->if_xname, "pfsync send queue", > | + MTX_DEF); > | if_attach(&sc->sc_if); > | > | LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); > > Complete updated patch attached and uploaded to: > http://people.freebsd.org/~mlaier/if_pfsync.senddef5.diff > > Sorry. > > >>net.inet.carp.preempt: 0 -> 1 >>Setting hostname: ---. >>em: Link is up 100 Mbps Full Duplex >>panic: mtx_lock() of spin mutex (null) @ ../../../net/if.c:1983 >>cpuid = 1 >>KDB: enter: panic >>[thread pid 282 tid 100157 ] >>Stopped at kdb_enter+0x2f: nop >>db> trace >>Tracing pid 282 tid 100157 td 0xffffff000af78280 >>kdb_enter() at kdb_enter+0x2f >>panic() at panic+0x249 >>_mtx_lock_flags() at _mtx_lock_flags+0xd6 >>if_handoff() at if_handoff+0x49 >>pfsync_sendout() at pfsync_sendout+0x268 >>pfsyncioctl() at pfsyncioctl+0x497 >>in_control() at in_control+0x8cb >>ifioctl() at ifioctl+0x178 >>sooo_ioctl() at soo_ioctl+0x2d6 >>ioctl() at ioctl+0xfc >>syscall() at syscall+0x4ab >>Xfast_syscall() at Xfast_syscall+0xa8 >>--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800793340, rsp = >>0x7fffffffeca8, rbp = 0x7fffffffef8b --- db> show locks >>eclusive sleep mutex pf task mtx r = 0 (0xffffffff80752f60) locked @ >>contrib/pf/net/if_pfsync.c:973 >> >>Rebooting the machine with the same kernel produces an identical panic. Let >>me know what else I can do to help. Right now I have just been rebooting >>back to a UP kernel which has never shown any sign of problems. >> >>Matthew Grooms >> >>-----Original Message----- >>From: Grooms, Matthew >>Sent: Wed 6/8/2005 6:22 PM >>To: Max Laier >>Cc: Palle Girgensohn; Kris Kennaway; freebsd-stable@freebsd.org; >>glebius@freebsd.org; pf@freebsd.org Subject: RE: 5.4-RELEASE lockups on >>amd64 SMP >> >>Matthew, >> >>can you try the attached diff. Available for 5 and CURRENT. I recall that >>this problem was seen before, strange that I didn't see the problem. >>Sounds familiar to you? Please try the patch and let me know if that >>helps. Thanks a lot. >> >>On Wednesday 08 June 2005 01:35, Matthew Grooms wrote: >> >>>Once again, here are the backtraces for the panic and lor ... >>> >>>Tracing id 110 tid 100089 td 0xffffff012f3f0c80 >>>kdb_enter() at kdb_enter+0x2f >>>panic() at panic+0x249 >>>uma_dbg_free() at uma_dbg_free+0x188 >>>uma_zfree_arg() at uma_zfree_arg+0x1b0 >>>pf_purge_expired_states() at pf_purge_expired_states+0x41 >>>pfsync_input at pfsync_input+xb35 >>>pf_input() at ip_input+0x10f >>>netisr_processqueue() at netisr_processqueue+0x17 >>>swi_net() at swi_net+0xa8 >>>ithread_loop() at ithread_loop+0xd9 >>>fork_exit() at fork_exit+0xc3 >>>fork_trampoline() at fork_trampoline+0xe >>>--- trap 0, rip = 0, rsp = 0xffffffffb44f9d00, rbp = 0 --- >>>db> continue >>>boot() called on cpu#0 >>>Uptime: 13h42m43s >>>Dumping 4864 MB >>> 16 32 ... >>> >>>lock order reversal >> >>... >> >> >>>alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5 >>>pf_state_tree_lan_ext_RB_REMOVE() at >>>pf_state_tree_lan_ext_RB_REMOVE+0x10c >> >>This LOR is a consequence of the fault, so it can be disregarded. > > > > ------------------------------------------------------------------------ > > Index: if_pfsync.c > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v > retrieving revision 1.11.2.2 > diff -u -r1.11.2.2 if_pfsync.c > --- if_pfsync.c 19 May 2005 10:59:22 -0000 1.11.2.2 > +++ if_pfsync.c 8 Jun 2005 23:42:45 -0000 > @@ -130,6 +130,7 @@ > > static void pfsync_clone_destroy(struct ifnet *); > static int pfsync_clone_create(struct if_clone *, int); > +static void pfsync_senddef(void *); > #else > void pfsyncattach(int); > #endif > @@ -170,6 +171,8 @@ > callout_stop(&sc->sc_bulk_tmo); > callout_stop(&sc->sc_bulkfail_tmo); > > + callout_stop(&sc->sc_send_tmo); > + > #if NBPFILTER > 0 > bpfdetach(ifp); > #endif > @@ -216,6 +219,9 @@ > callout_init(&sc->sc_tmo, 0); > callout_init(&sc->sc_bulk_tmo, 0); > callout_init(&sc->sc_bulkfail_tmo, 0); > + callout_init(&sc->sc_send_tmo, 0); > + mtx_init(&sc->sc_ifq.ifq_mtx, ifp->if_xname, "pfsync send queue", > + MTX_DEF); > if_attach(&sc->sc_if); > > LIST_INSERT_HEAD(&pfsync_list, sc, sc_next); > @@ -913,6 +919,7 @@ > if (pfsyncr.pfsyncr_maxupdates > 255) > return (EINVAL); > #ifdef __FreeBSD__ > + callout_drain(&sc->sc_send_tmo); > PF_LOCK(); > #endif > sc->sc_maxupdates = pfsyncr.pfsyncr_maxupdates; > @@ -1634,15 +1641,14 @@ > #endif > > pfsyncstats.pfsyncs_opackets++; > - > #ifdef __FreeBSD__ > - PF_UNLOCK(); > -#endif > + if (IF_HANDOFF(&sc->sc_ifq, m, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + else > + callout_reset(&sc->sc_send_tmo, 1, pfsync_senddef, sc); > +#else > if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > pfsyncstats.pfsyncs_oerrors++; > - > -#ifdef __FreeBSD__ > - PF_LOCK(); > #endif > } else > m_freem(m); > @@ -1652,6 +1658,22 @@ > > > #ifdef __FreeBSD__ > +static void > +pfsync_senddef(void *arg) > +{ > + struct pfsync_softc *sc = (struct pfsync_softc *)arg; > + struct mbuf *m; > + > + for(;;) { > + IF_DEQUEUE(&sc->sc_ifq, m); > + if (m == NULL) > + break; > + if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)) > + pfsyncstats.pfsyncs_oerrors++; > + } > +} > + > + > static int > pfsync_modevent(module_t mod, int type, void *data) > { > Index: if_pfsync.h > =================================================================== > RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.h,v > retrieving revision 1.4 > diff -u -r1.4 if_pfsync.h > --- if_pfsync.h 16 Jun 2004 23:24:00 -0000 1.4 > +++ if_pfsync.h 8 Jun 2005 23:42:59 -0000 > @@ -158,8 +158,12 @@ > struct timeout sc_bulkfail_tmo; > #endif > struct in_addr sc_sendaddr; > - struct mbuf *sc_mbuf; /* current cummulative mbuf */ > - struct mbuf *sc_mbuf_net; /* current cummulative mbuf */ > + struct mbuf *sc_mbuf; /* current cumulative mbuf */ > + struct mbuf *sc_mbuf_net; /* current cumulative mbuf */ > +#ifdef __FreeBSD__ > + struct ifqueue sc_ifq; > + struct callout sc_send_tmo; > +#endif > union sc_statep sc_statep; > union sc_statep sc_statep_net; > u_int32_t sc_ureq_received; From owner-freebsd-pf@FreeBSD.ORG Thu Jun 9 21:12:08 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DD5516A41C for ; Thu, 9 Jun 2005 21:12:08 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F3243D1F for ; Thu, 9 Jun 2005 21:12:08 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so391453nzp for ; Thu, 09 Jun 2005 14:12:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VHtMo43vBv1nj3+g8m0LWox1A7DlsKJ4vAMBffmc11TrA/xT1LN96GL/2xoMYxBrWBrJggmR8mZR+3hYrms40Lykd1kwp97PzvYrrNA9FWBW98xgAaoLLzbSbP/QTLNhfjO6Fb3yfp4GqsJ7VwIglBWlDeGx5TU0qmS5e3PDfSg= Received: by 10.36.46.20 with SMTP id t20mr662385nzt; Thu, 09 Jun 2005 14:12:07 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Thu, 9 Jun 2005 14:12:07 -0700 (PDT) Message-ID: <79722fad05060914123edd1004@mail.gmail.com> Date: Fri, 10 Jun 2005 00:12:07 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Please review & test this X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 21:12:08 -0000 As you may all know, the packet classifier in ALTQ is very slow on large numbers of classes, because it stores them linearly, in an array. I rewrote the way classes are stored, replacing the array with a hash table. I tested [1] on a system with about 8000 classes and noticed a remarkable performance difference (the system went from almost unusable to nice & smooth). It breaks the ABI by adding an extra TAILQ_ENTRY member to the HFSC class structure, though. If anyone reviews and tests it, I would be grateful. [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff P.S. please keep in mind that I'm not exactly a black belt in kernel programming, so glitches might exist. I would be most happy to hear some suggestions. --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 9 22:10:13 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 058DC16A41F for ; Thu, 9 Jun 2005 22:10:13 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3EA43D49 for ; Thu, 9 Jun 2005 22:10:12 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so419105nzp for ; Thu, 09 Jun 2005 15:10:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mr6oUfqzLFEeY/3sv9sHSjTTPiOhzpJvzY2AmbYNbxMITig0JmQVIBB28T2K5diClY4AayAP2UOD07ZHqRatY93Tfd3JWfqf6bsVou9Tyo96jxJdConTOq000WQLk/smZ73Sbf0Y/NwcrTmhNZgKbyYOd+O95f2hyjeqGgC3qN8= Received: by 10.36.34.2 with SMTP id h2mr710951nzh; Thu, 09 Jun 2005 15:10:11 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Thu, 9 Jun 2005 15:10:11 -0700 (PDT) Message-ID: <79722fad050609151068c71c91@mail.gmail.com> Date: Fri, 10 Jun 2005 01:10:11 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <79722fad05060914123edd1004@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad05060914123edd1004@mail.gmail.com> Cc: Subject: Re: Please review & test this X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 22:10:13 -0000 On 6/10/05, Vlad GALU wrote: > As you may all know, the packet classifier in ALTQ is very > slow on large numbers of classes, because it stores them linearly, in > an array. I rewrote the way classes are stored, replacing the array > with a hash table. I tested [1] on a system with about 8000 classes > and noticed a remarkable performance difference (the system went from > almost unusable to nice & smooth). It breaks the ABI by adding an > extra TAILQ_ENTRY member to the HFSC class structure, though.=20 And also replaces the class array in struct hfsc_if with the hash table. > If anyone reviews and tests it, I would be grateful. >=20 > [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff >=20 > P.S. please keep in mind that I'm not exactly a black belt in kernel > programming, so glitches might exist. I would be most happy to hear > some suggestions. >=20 > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-pf@FreeBSD.ORG Fri Jun 10 03:06:34 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73E1C16A41C for ; Fri, 10 Jun 2005 03:06:34 +0000 (GMT) (envelope-from crumb@msnomer.com) Received: from mx01.ca.mci.com (mx01.ca.mci.com [142.77.2.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30F2E43D49 for ; Fri, 10 Jun 2005 03:06:34 +0000 (GMT) (envelope-from crumb@msnomer.com) Received: from effector (unknown [66.48.11.93]) by mx01.ca.mci.com (Postfix) with ESMTP id 15A8210659 for ; Thu, 9 Jun 2005 23:06:33 -0400 (EDT) From: "Tony Martino" To: Date: Thu, 9 Jun 2005 23:07:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVtaX/x4frmcBaiSMiV/xjzqmQKeg== Message-Id: <20050610030633.15A8210659@mx01.ca.mci.com> Subject: PF with routable internal addresses X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 03:06:34 -0000 Hi, My internal network is 209.167.184.32/27, connected to the firewall on fxp0. The firewall machine is connected to the Internet through a PPPOE connection on fxp1/tun0, at 66.48.11.93. There are no NAT rules configured. This is on a 5.4-release system. I noticed a lot of bittorrent traffic getting blocked by the default deny rule, rather than getting passed by rules set up to let it through: pass in on $ext_if inet proto tcp from any to $azureus_users port 6882 pass in on $ext_if inet proto udp from any to $azureus_users port 6882 Then I noticed the IP that the bittorrent peers were trying to connect to was the tun0's address, rather than the address of the windows box the bittorrent client is running on. From this output, it appears that something is rewriting the source address on outgoing packets: carriertone# tcpdump -i tun0 | grep whatis tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes 16:25:27.006924 IP 209.167.184.39.4029 > mail.whatismyip.com.http: P 4256462602:4256463003(401) ack 2685840180 win 65535 16:25:27.070236 IP mail.whatismyip.com.http > 209.167.184.39.4029: . 1:1293(1292) ack 401 win 64000 16:25:27.070568 IP mail.whatismyip.com > 209.167.184.39: tcp 16:25:27.073661 IP mail.whatismyip.com.http > 209.167.184.39.4029: P 1441:2739(1298) ack 401 win 64000 16:25:27.074116 IP 209.167.184.39.4029 > mail.whatismyip.com.http: . ack 2739 win 65535 16:25:27.194978 IP mail.whatismyip.com.http > 209.167.184.39.4029: . ack 401 win 64000 carriertone# tcpdump -i fxp1 | grep whatis tcpdump: WARNING: fxp1: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on fxp1, link-type EN10MB (Ethernet), capture size 96 bytes 16:25:27.007091 PPPoE [ses 0x1a7b] IP 66.48.11.93.4029 > mail.whatismyip.com.http: P 4256462602:4256463003(401) ack 2685840180 win 65535 16:25:27.070045 PPPoE [ses 0x1a7b] IP mail.whatismyip.com.http > 66.48.11.93.4029: . 1:1293(1292) ack 401 win 64000 16:25:27.070446 PPPoE [ses 0x1a7b] IP mail.whatismyip.com > 66.48.11.93: tcp 16:25:27.073515 PPPoE [ses 0x1a7b] IP mail.whatismyip.com.http > 66.48.11.93.4029: P 1441:2739(1298) ack 401 win 64000 16:25:27.074262 PPPoE [ses 0x1a7b] IP 66.48.11.93.4029 > mail.whatismyip.com.http: . ack 2739 win 65535 16:25:27.194848 PPPoE [ses 0x1a7b] IP mail.whatismyip.com.http > 66.48.11.93.4029: . ack 401 win 64000 Isn't this NAT? Why is this happening when there is no NAT configured anywhere on this system? Thanks, Tony From owner-freebsd-pf@FreeBSD.ORG Fri Jun 10 14:59:36 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F330F16A41C for ; Fri, 10 Jun 2005 14:59:35 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EEEA43D48 for ; Fri, 10 Jun 2005 14:59:33 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j5AExUpC068325; Fri, 10 Jun 2005 18:59:30 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j5AExTDr068324; Fri, 10 Jun 2005 18:59:29 +0400 (MSD) (envelope-from yar) Date: Fri, 10 Jun 2005 18:59:29 +0400 From: Yar Tikhiy To: Greg Hennessy Message-ID: <20050610145929.GB65307@comp.chem.msu.su> References: <20050603115843.GA15561@comp.chem.msu.su> <20050603130741.D427416@gw2.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050603130741.D427416@gw2.local.net> User-Agent: Mutt/1.5.9i Cc: freebsd-pf@freebsd.org Subject: Re: pfsync and asymmetric paths X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 14:59:36 -0000 Excuse me for a late reply, I missed your mail. On Fri, Jun 03, 2005 at 02:07:41PM +0100, Greg Hennessy wrote: > > > Is it by design? I'd like to make the asymmetric > > configuration functional if possible at all, but I've been > > unable to find any background information on the issue, such > > as mailing list discussions or whatever. > > Silly question, why are you not using CARP and using the virtual IP as the > egress/ingress next hop on both sides ? Alas, CARP is not applicable in every case, sometimes one have to run OSPF etc. And what I'd like to have functional looks like a simple yet reasonable generalization from just a set of interchangeable PF boxes to an actually distributed stateful packet filter that won't care about which of its nodes sees an IP packet. P.S. In OSPF, one can assign different costs to the paths, but that would break nice symmetry of the network configuration I considered. -- Yar From owner-freebsd-pf@FreeBSD.ORG Fri Jun 10 16:00:33 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C371D16A41F for ; Fri, 10 Jun 2005 16:00:33 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A8AD43D1F for ; Fri, 10 Jun 2005 16:00:33 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so768985wri for ; Fri, 10 Jun 2005 09:00:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mvVhETEiTR+1IgEmzf3MVqh0Ena5MIhhPFD5yKWeyPv/4yHgCH0DB+KnWgaVNhjClHxUO0g6lrRviuP4KpoAc3bkDflQkEVeBvpL4GFbLhmiP7Ea7Me/FX50/TLdmFGhyqmlBDzNCoN6I5wDfgf2px3WqE15eiIOszddaRbBPlA= Received: by 10.54.33.53 with SMTP id g53mr1045620wrg; Fri, 10 Jun 2005 09:00:32 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Fri, 10 Jun 2005 09:00:32 -0700 (PDT) Message-ID: <7c8f2792050610090049064e11@mail.gmail.com> Date: Fri, 10 Jun 2005 12:00:32 -0400 From: Josh Kayse To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Carp Suppression X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gtg062h@mail.gatech.edu List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 16:00:33 -0000 I am cross-posting this to -net and -pf because I am not sure where it goes= . I am running 2 carp interfaces on a pair of transparent firewalls running FreeBSD 5.4. One of the interfaces is a xl interface and the other is a plip interface. I am having trouble in that the carp interfaces are not failing over between the 2 machines. When I check net.inet.carp.suppress_preempt it returns 1 and I do not understand why that is. Can anyone shed some light on this? If you need any more information, just let me know. Thanks Josh --=20 Joshua Kayse Computer Engineering From owner-freebsd-pf@FreeBSD.ORG Fri Jun 10 16:11:00 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E833816A422 for ; Fri, 10 Jun 2005 16:11:00 +0000 (GMT) (envelope-from taglio@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68EB343D53 for ; Fri, 10 Jun 2005 16:11:00 +0000 (GMT) (envelope-from taglio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so410603wra for ; Fri, 10 Jun 2005 09:10:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=g9oyd4NmTqhDLfyikKk9MGaztzdUNI60F2oaGbyNd5SIth7x/8haKzJylnQu9/fMm/rMqE1gsCOYGYFwwxyoOcrpLBUeMTnq3c0mE/jji/mICL73YYCHFsiwc1o8BTFNMkOMoQfHbMc/VEEFlxlNv84kCPRt+0Cf7ByxoxN4BhE= Received: by 10.54.116.2 with SMTP id o2mr1042582wrc; Fri, 10 Jun 2005 09:10:59 -0700 (PDT) Received: by 10.54.38.41 with HTTP; Fri, 10 Jun 2005 09:10:59 -0700 (PDT) Message-ID: <31fbaca905061009107e7df9cf@mail.gmail.com> Date: Fri, 10 Jun 2005 18:10:59 +0200 From: Riccardo Giuntoli To: freebsd-pf@freebsd.org, freebsd-questions@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: very heavy load avarage X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Riccardo Giuntoli List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 16:11:01 -0000 Hi folks, i've got a server with FreeBSD 5.4-STABLE and pf with a gigabit ethernet interface directly on internet. Two C class are routed over it, and i sell shell account for irc processes. As you know on irc many times the server is under DDOS attack many time up to 100 mb/s. But with one gigabit connection the problem isn't the band of the attack, my server's cpu load avarage goes extremly high, you can verify here: http://www.6shells.net/graphs/graph_14.html What can i do for decrease it? Please help, Regards Name: Riccardo Giuntoli Email: taglio@gmail.com Homepage: http://www.luxoro.org/ Location: Genova, Italy 6BONE Handle: RG581-6BONE PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842F AB54=20 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net From owner-freebsd-pf@FreeBSD.ORG Fri Jun 10 17:06:16 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7286316A41C; Fri, 10 Jun 2005 17:06:16 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2104E43D1D; Fri, 10 Jun 2005 17:06:16 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id E0796BC1D8; Fri, 10 Jun 2005 20:06:14 +0300 (EEST) Received: from R3B (unknown [62.38.169.49])by smtp.freemail.gr (Postfix) with ESMTP id 65A89BC0A6; Fri, 10 Jun 2005 20:06:12 +0300 (EEST) Message-ID: <002b01c56dde$ae305ea0$0100000a@R3B> From: "Chris Dionissopoulos" To: "Riccardo Giuntoli" , , References: <31fbaca905061009107e7df9cf@mail.gmail.com> Date: Fri, 10 Jun 2005 20:05:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: Subject: Re: very heavy load avarage X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris Dionissopoulos List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 17:06:16 -0000 >But with one gigabit connection the problem isn't the band of the >attack, my server's cpu load avarage goes extremly high, you can >verify here: > >http://www.6shells.net/graphs/graph_14.html > >What can i do for decrease it? Try to create a new kernel with timing at 1000hz and if your hardware (nic) is supported enable device polling (polling(4)). Chris. ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-pf@FreeBSD.ORG Fri Jun 10 17:34:30 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D87F716A41C; Fri, 10 Jun 2005 17:34:30 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BF8643D5F; Fri, 10 Jun 2005 17:34:28 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C1C0.dip.t-dialin.net [84.163.193.192] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1DgnOk3nje-00068a; Fri, 10 Jun 2005 19:34:26 +0200 From: Max Laier To: freebsd-pf@freebsd.org, Riccardo Giuntoli Date: Fri, 10 Jun 2005 19:34:17 +0200 User-Agent: KMail/1.8 References: <31fbaca905061009107e7df9cf@mail.gmail.com> In-Reply-To: <31fbaca905061009107e7df9cf@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2224196.I7V43yhbIm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506101934.24910.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-questions@freebsd.org Subject: Re: very heavy load avarage X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 17:34:31 -0000 --nextPart2224196.I7V43yhbIm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 10 June 2005 18:10, Riccardo Giuntoli wrote: > Hi folks, > i've got a server with FreeBSD 5.4-STABLE and pf with a gigabit > ethernet interface directly on internet. Two C class are routed over > it, and i sell shell account for irc processes. As you know on irc > many times the server is under DDOS attack many time up to 100 mb/s. > But with one gigabit connection the problem isn't the band of the > attack, my server's cpu load avarage goes extremly high, you can > verify here: > > http://www.6shells.net/graphs/graph_14.html > > What can i do for decrease it? If I am reading the graph right, this is load (i.e. number of processes abl= e=20 to run, but waiting for a CPU). High values of that usually suggest the=20 problem is a local user fork-bombing your system or some other daemon/servi= ce=20 gone wild. Try to cut down the number of processes a (shell-)user may have= =20 via login.conf and see if that helps. If it is not on of the (ab)users, tr= y=20 to nail down the daemon that does it and figure out why. I don't think pf will be a lot of help against this type of attack - unless= =20 this is your IRCd forking. In that case you could try to limit the states = a=20 single IP can create (see "max-src-states" in pf.conf) or rate-limit the=20 connections with CURRENT's "max-src-conn-rate". =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 --nextPart2224196.I7V43yhbIm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCqc8gXyyEoT62BG0RAtUiAJ4lyoXMtAPYQCtmfd/pHCrdZQHmhgCfc3j3 DjyEm8drz8eoQ6n9SOp2Pmo= =S5bQ -----END PGP SIGNATURE----- --nextPart2224196.I7V43yhbIm-- From owner-freebsd-pf@FreeBSD.ORG Sat Jun 11 06:16:52 2005 Return-Path: X-Original-To: pf@hub.freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F379F16A41C; Sat, 11 Jun 2005 06:16:51 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8027443D49; Sat, 11 Jun 2005 06:16:51 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (mlaier@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5B6GpRR094614; Sat, 11 Jun 2005 06:16:51 GMT (envelope-from mlaier@freefall.freebsd.org) Received: (from mlaier@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5B6GpCU094610; Sat, 11 Jun 2005 06:16:51 GMT (envelope-from mlaier) Date: Sat, 11 Jun 2005 06:16:51 GMT From: Max Laier Message-Id: <200506110616.j5B6GpCU094610@freefall.freebsd.org> To: dreams@gmail.com, mlaier@FreeBSD.org, mlaier@FreeBSD.org, pf@FreeBSD.org Cc: Subject: Re: kern/77308: ALTQ doesn't seem to be working on tun0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 06:16:52 -0000 Synopsis: ALTQ doesn't seem to be working on tun0 State-Changed-From-To: open->feedback State-Changed-By: mlaier State-Changed-When: Sat Jun 11 06:14:18 GMT 2005 State-Changed-Why: Too few details on the actual ruleset and configuration. Responsible-Changed-From-To: mlaier->pf Responsible-Changed-By: mlaier Responsible-Changed-When: Sat Jun 11 06:14:18 GMT 2005 Responsible-Changed-Why: Over to freebsd-pf@ for more exposure and helping hands/eyes. Does anyone have comments on this? I can only say: Works for me. http://www.freebsd.org/cgi/query-pr.cgi?pr=77308 From owner-freebsd-pf@FreeBSD.ORG Sat Jun 11 09:28:07 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB09D16A41C for ; Sat, 11 Jun 2005 09:28:07 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E9EF43D49 for ; Sat, 11 Jun 2005 09:28:07 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so1213365nzp for ; Sat, 11 Jun 2005 02:28:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ob5jeVavrwnpLKmiW0zugJaINgYVBV/zHwKTtEN4v9OdIzwUw4stKnotxHej6fw0gc83Xlw1mWh1lzTNF5XznCbaDizpBdFQS9LPQ/2AlFa3UBe46GeXF0NSImlFKyH6yNQF+hR0/7jAij7nbl4t1/9+x531Mqk6+2bfzbe3qPI= Received: by 10.36.106.20 with SMTP id e20mr1703304nzc; Sat, 11 Jun 2005 02:28:06 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Sat, 11 Jun 2005 02:28:06 -0700 (PDT) Message-ID: <79722fad0506110228538ee434@mail.gmail.com> Date: Sat, 11 Jun 2005 12:28:06 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <79722fad050609151068c71c91@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad05060914123edd1004@mail.gmail.com> <79722fad050609151068c71c91@mail.gmail.com> Cc: Subject: Re: Please review & test this X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 09:28:08 -0000 On 6/10/05, Vlad GALU wrote: > On 6/10/05, Vlad GALU wrote: > > As you may all know, the packet classifier in ALTQ is very > > slow on large numbers of classes, because it stores them linearly, in > > an array. I rewrote the way classes are stored, replacing the array > > with a hash table. I tested [1] on a system with about 8000 classes > > and noticed a remarkable performance difference (the system went from > > almost unusable to nice & smooth). It breaks the ABI by adding an > > extra TAILQ_ENTRY member to the HFSC class structure, though. >=20 > And also replaces the class array in struct hfsc_if with the hash table= . Bummer. Increasing the number of classes led to locking the machine up. Something slipped my eye: the filters are also linearly searched for. I'll try to do something about them as well and come back with something. >=20 > > If anyone reviews and tests it, I would be grateful. > > > > [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff > > > > P.S. please keep in mind that I'm not exactly a black belt in kernel > > programming, so glitches might exist. I would be most happy to hear > > some suggestions. > > > > -- > > If it's there, and you can see it, it's real. > > If it's not there, and you can see it, it's virtual. > > If it's there, and you can't see it, it's transparent. > > If it's not there, and you can't see it, you erased it. > > >=20 >=20 > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-pf@FreeBSD.ORG Sat Jun 11 20:07:22 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CB1516A41F for ; Sat, 11 Jun 2005 20:07:22 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4733643D4C for ; Sat, 11 Jun 2005 20:07:22 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so1143639nzo for ; Sat, 11 Jun 2005 13:07:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qeT43F/MNyo/BJ1Gwq0EsjxSDOV81CqPF0aElAgOUSrUd6efLXrvtdKtungb3/I0ZT/rd++aKK/KGYZdeLw323Trxs/2mWowA31hBHC8Xx8QRs1RalOZv9d7JWa6FaPtZNLqKOVGSTqNuIiQ0GJiZEPu7YCoFJciGrAJeWUjm1I= Received: by 10.36.115.1 with SMTP id n1mr1934741nzc; Sat, 11 Jun 2005 13:07:21 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Sat, 11 Jun 2005 13:07:21 -0700 (PDT) Message-ID: <79722fad050611130734c36979@mail.gmail.com> Date: Sat, 11 Jun 2005 23:07:21 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <79722fad0506110228538ee434@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad05060914123edd1004@mail.gmail.com> <79722fad050609151068c71c91@mail.gmail.com> <79722fad0506110228538ee434@mail.gmail.com> Cc: Subject: Re: Please review & test this X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 20:07:22 -0000 On 6/11/05, Vlad GALU wrote: > On 6/10/05, Vlad GALU wrote: > > On 6/10/05, Vlad GALU wrote: > > > As you may all know, the packet classifier in ALTQ is very > > > slow on large numbers of classes, because it stores them linearly, in > > > an array. I rewrote the way classes are stored, replacing the array > > > with a hash table. I tested [1] on a system with about 8000 classes > > > and noticed a remarkable performance difference (the system went from > > > almost unusable to nice & smooth). It breaks the ABI by adding an > > > extra TAILQ_ENTRY member to the HFSC class structure, though. > > > > And also replaces the class array in struct hfsc_if with the hash tab= le. >=20 > Bummer. Increasing the number of classes led to locking the machine > up. Something slipped my eye: the filters are also linearly searched > for. I'll try to do something about them as well and come back with > something. >=20 Duhhh, I need more coffee. I didn't notice the ALTQ3_COMPAT ifdef in the source. Luckily, the patch in my first mail deals with it as well. The classifying is entirely done by pf, so I guess it only depends on how (un)optimized your ruleset is. > > > > > If anyone reviews and tests it, I would be grateful. > > > > > > [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff > > > > > > P.S. please keep in mind that I'm not exactly a black belt in kernel > > > programming, so glitches might exist. I would be most happy to hear > > > some suggestions. > > > > > > -- > > > If it's there, and you can see it, it's real. > > > If it's not there, and you can see it, it's virtual. > > > If it's there, and you can't see it, it's transparent. > > > If it's not there, and you can't see it, you erased it. > > > > > > > > > -- > > If it's there, and you can see it, it's real. > > If it's not there, and you can see it, it's virtual. > > If it's there, and you can't see it, it's transparent. > > If it's not there, and you can't see it, you erased it. > > >=20 >=20 > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-pf@FreeBSD.ORG Sat Jun 11 23:02:16 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9333216A41C for ; Sat, 11 Jun 2005 23:02:16 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1989443D4C for ; Sat, 11 Jun 2005 23:02:13 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so634449wra for ; Sat, 11 Jun 2005 16:02:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AHYOpTqFzDdtVqjmxK8qMcFY6e3W2RxJ98z0tRa6pbxS3WM186lPvxbpYXDmXVZRlxVhAQ1duhILIyfROtqisMakB28G6AmlRcLtfDq5rmO508UUirHe/UrendyLm7HIvLjVk1j7Z6TWYG3nuTNkZhGPjjypb4/YOfLECn8AHSw= Received: by 10.54.116.2 with SMTP id o2mr1682681wrc; Sat, 11 Jun 2005 16:02:13 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Sat, 11 Jun 2005 16:02:13 -0700 (PDT) Message-ID: <7c8f279205061116021f55e8da@mail.gmail.com> Date: Sat, 11 Jun 2005 19:02:13 -0400 From: Josh Kayse To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org In-Reply-To: <7c8f2792050610090049064e11@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7c8f2792050610090049064e11@mail.gmail.com> Cc: Subject: Re: Carp Suppression X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gtg062h@mail.gatech.edu List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 23:02:16 -0000 I think I've narrowed it down to the plip interface, but I'm not completely sure. Has anyone gotten carp running over a plip interface? On 6/10/05, Josh Kayse wrote: > I am cross-posting this to -net and -pf because I am not sure where it go= es. >=20 > I am running 2 carp interfaces on a pair of transparent firewalls > running FreeBSD 5.4. >=20 > One of the interfaces is a xl interface and the other is a plip interface= . >=20 > I am having trouble in that the carp interfaces are not failing over > between the 2 machines. >=20 > When I check net.inet.carp.suppress_preempt it returns 1 and I do not > understand why that is. >=20 > Can anyone shed some light on this? >=20 > If you need any more information, just let me know. >=20 > Thanks >=20 > Josh > -- > Joshua Kayse > Computer Engineering >=20 --=20 Joshua Kayse Computer Engineering