From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 11:04:19 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 F33BB16A41C for ; Mon, 13 Jun 2005 11:04:18 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1409443DA0 for ; Mon, 13 Jun 2005 11:04:04 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5DB42EP047834 for ; Mon, 13 Jun 2005 11:04:02 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5DB42Fp047828 for pf@freebsd.org; Mon, 13 Jun 2005 11:04:02 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Jun 2005 11:04:02 GMT Message-Id: <200506131104.j5DB42Fp047828@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: pf@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 13 Jun 2005 11:04:19 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2005/02/09] kern/77308 pf ALTQ doesn't seem to be working on tun0 1 problem total. From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 14:10:58 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 8558016A41C for ; Mon, 13 Jun 2005 14:10:58 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19EF543D5C for ; Mon, 13 Jun 2005 14:10:56 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1014467wra for ; Mon, 13 Jun 2005 07:10:56 -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=F3BLe6qIOdXnd7sgROp7qM7BZKqdZ6f26iqoScdbe4EBxl+aB283woww3X92OrcsY7n2qJAL+BH1C/Lj915WPvvD3w48sNAbghxlecaZp9T8AJQWz66KDRSdlqud9HAnOl6xQzLocqv6kerJ4lQJG9gxOk8raiD2YhQnMaxlGAU= Received: by 10.54.116.2 with SMTP id o2mr2549398wrc; Mon, 13 Jun 2005 07:10:55 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Mon, 13 Jun 2005 07:10:54 -0700 (PDT) Message-ID: <7c8f279205061307103b1782f4@mail.gmail.com> Date: Mon, 13 Jun 2005 10:10:54 -0400 From: Josh Kayse To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org In-Reply-To: <7c8f279205061116021f55e8da@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> <7c8f279205061116021f55e8da@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: Mon, 13 Jun 2005 14:10:58 -0000 One last comment, I managed to fix it so that carp runs on the plip interface by adding: ifp->if_flags =3D LINK_STATE_UP; Here is the diff: diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c /usr/src/sys/dev/ppbus/if_p= lip.c --- /usr.orig/src/sys/dev/ppbus/if_plip.c Wed Sep 15 11:14:18 2004 +++ /usr/src/sys/dev/ppbus/if_plip.c Mon Jun 13 10:05:56 2005 @@ -359,6 +359,7 @@ ppb_wctr(ppbus, IRQENABLE); ifp->if_flags |=3D IFF_RUNNING; + ifp->if_flags =3D LINK_STATE_UP; } break; On 6/11/05, Josh Kayse wrote: > 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? >=20 > On 6/10/05, Josh Kayse wrote: > > 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 interfa= ce. > > > > 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 > > -- > > Joshua Kayse > > Computer Engineering > > >=20 >=20 > -- > Joshua Kayse > Computer Engineering >=20 --=20 Joshua Kayse Computer Engineering From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 14:22:39 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 40DBA16A41C; Mon, 13 Jun 2005 14:22:39 +0000 (GMT) (envelope-from mlsmith@mitre.org) Received: from smtp-bedford-dr.mitre.org (smtp-bedford-dr-x.mitre.org [192.160.51.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB1A43D49; Mon, 13 Jun 2005 14:22:38 +0000 (GMT) (envelope-from mlsmith@mitre.org) Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j5DEMSx30795; Mon, 13 Jun 2005 10:22:28 -0400 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 9843D4F8DB; Mon, 13 Jun 2005 10:22:28 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j5DEMSV30726; Mon, 13 Jun 2005 10:22:28 -0400 Received: from mm112487-2k.mitre.org (128.29.50.27) by mailhub1.mitre.org with SMTP id 18416013; Mon, 13 Jun 2005 10:22:24 -0400 Message-ID: <05e001c57023$5189d180$1b321d80@MITRE.ORG> From: "PSI, Mike Smith" To: , , References: <7c8f2792050610090049064e11@mail.gmail.com> <7c8f279205061116021f55e8da@mail.gmail.com> <7c8f279205061307103b1782f4@mail.gmail.com> Date: Mon, 13 Jun 2005 10:22:24 -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 Cc: Subject: Re: Carp Suppression 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: Mon, 13 Jun 2005 14:22:39 -0000 Hey all, Honestly I have no idea what this is all about, but saw something in the change adding "ipf->if_flags=LINK_STATE_UP;" that just seemed really strange from a programming standpoint. Doesn't this statement "undo" the effects of the line just before it (ipf->if_flags |= IFF_RUNNING). Again I have no idea what this is about so it is possible that IFF_RUNNING bit(s) is part of LINK_STATE_UP bit(s). Just seemed strange and if this is a problem, catching it early is better than late. If it is correct as stands, I apologize for questioning it. Mike Smith >----- Original Message ----- >From: "Josh Kayse" > > One last comment, > > I managed to fix it so that carp runs on the plip interface by adding: > ifp->if_flags = LINK_STATE_UP; > Here is the diff: > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c /usr/src/sys/dev/ppbus/if_plip.c > --- /usr.orig/src/sys/dev/ppbus/if_plip.c Wed Sep 15 11:14:18 2004 > +++ /usr/src/sys/dev/ppbus/if_plip.c Mon Jun 13 10:05:56 2005 > @@ -359,6 +359,7 @@ > > ppb_wctr(ppbus, IRQENABLE); > ifp->if_flags |= IFF_RUNNING; > + ifp->if_flags = LINK_STATE_UP; > } > break; From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 15:35:59 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 51CF816A41C; Mon, 13 Jun 2005 15:35:59 +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 3925643D1D; Mon, 13 Jun 2005 15:35:56 +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 j5DFZpWU055649; Mon, 13 Jun 2005 19:35:51 +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 j5DFZprB055648; Mon, 13 Jun 2005 19:35:51 +0400 (MSD) (envelope-from yar) Date: Mon, 13 Jun 2005 19:35:50 +0400 From: Yar Tikhiy To: Josh Kayse Message-ID: <20050613153550.GA54388@comp.chem.msu.su> References: <7c8f2792050610090049064e11@mail.gmail.com> <7c8f279205061116021f55e8da@mail.gmail.com> <7c8f279205061307103b1782f4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c8f279205061307103b1782f4@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Carp Suppression 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: Mon, 13 Jun 2005 15:35:59 -0000 On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote: > One last comment, > > I managed to fix it so that carp runs on the plip interface by adding: > ifp->if_flags = LINK_STATE_UP; > > Here is the diff: > > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c /usr/src/sys/dev/ppbus/if_plip.c > --- /usr.orig/src/sys/dev/ppbus/if_plip.c Wed Sep 15 11:14:18 2004 > +++ /usr/src/sys/dev/ppbus/if_plip.c Mon Jun 13 10:05:56 2005 > @@ -359,6 +359,7 @@ > > ppb_wctr(ppbus, IRQENABLE); > ifp->if_flags |= IFF_RUNNING; > + ifp->if_flags = LINK_STATE_UP; > } > break; I'm afraid you're totally wrong here. First, I can't see how CARP is supposed to work on a PLIP interface or any point-to-point interface at all. CARP is for broadcast interfaces, such as Ethernet or FDDI, which do ARP. You seem to miss the point. Second, you can't store an arbitrary value into a variable or field and expect the things to work right. LINK_STATE_UP simply is not for ifp->if_flags. Please make yourself familiar with the basics of computer programming before offering your patches to the community. -- Yar From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 16:00: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 3F02B16A41C for ; Mon, 13 Jun 2005 16:00:38 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D176F43D55 for ; Mon, 13 Jun 2005 16:00:37 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2151796wra for ; Mon, 13 Jun 2005 09:00: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kXIEaF9emsp4M4eo0uf3kFWonVbmEBUTKjlS9U9X/Dvo6VxTfzt6UnWMj1leOd1jctvx5fdQfXsZIWkySzkHrk2WqbvdYqvf7JrMVRMSLf0mwiA42HCwsJRK0ilJcNM9vTp9hLPdlv0D5ujXkQDOkJxlRT/MpgQRS0wQTy1Ytvg= Received: by 10.54.144.9 with SMTP id r9mr2606833wrd; Mon, 13 Jun 2005 09:00:36 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Mon, 13 Jun 2005 09:00:36 -0700 (PDT) Message-ID: <7c8f2792050613090040c924c3@mail.gmail.com> Date: Mon, 13 Jun 2005 12:00:36 -0400 From: Josh Kayse To: Yar Tikhiy In-Reply-To: <20050613153550.GA54388@comp.chem.msu.su> 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> <7c8f279205061116021f55e8da@mail.gmail.com> <7c8f279205061307103b1782f4@mail.gmail.com> <20050613153550.GA54388@comp.chem.msu.su> Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org 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: Mon, 13 Jun 2005 16:00:38 -0000 Definitely a typo on my part. It should be ifp->if_link_state =3D LINK_STATE_UP The reason we are using CARP on a PLIP interface is to allow us to have redundant connections between 2 transparent bridging firewalls.=20 Instead of sending packets over our network, we isolate them onto a PLIP interface and crossover interface. We then use ifstaded to monitor the carp interfaces and shut down bridging on one of the machines. I will refrain from submitting any code to the community in the future. On 6/13/05, Yar Tikhiy wrote: > On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote: > > One last comment, > > > > I managed to fix it so that carp runs on the plip interface by adding: > > ifp->if_flags =3D LINK_STATE_UP; > > > > Here is the diff: > > > > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c /usr/src/sys/dev/ppbus/= if_plip.c > > --- /usr.orig/src/sys/dev/ppbus/if_plip.c Wed Sep 15 11:14:18 200= 4 > > +++ /usr/src/sys/dev/ppbus/if_plip.c Mon Jun 13 10:05:56 2005 > > @@ -359,6 +359,7 @@ > > > > ppb_wctr(ppbus, IRQENABLE); > > ifp->if_flags |=3D IFF_RUNNING; > > + ifp->if_flags =3D LINK_STATE_UP; > > } > > break; >=20 > I'm afraid you're totally wrong here. >=20 > First, I can't see how CARP is supposed to work on a PLIP interface > or any point-to-point interface at all. CARP is for broadcast > interfaces, such as Ethernet or FDDI, which do ARP. You seem to miss > the point. >=20 > Second, you can't store an arbitrary value into a variable or field > and expect the things to work right. LINK_STATE_UP simply is not for > ifp->if_flags. Please make yourself familiar with the basics of > computer programming before offering your patches to the community. >=20 > -- > Yar >=20 --=20 Joshua Kayse Computer Engineering From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 16:51: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 C20FC16A481; Mon, 13 Jun 2005 16:51:36 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 764C143D48; Mon, 13 Jun 2005 16:51:36 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id 1128C252625; Mon, 13 Jun 2005 17:51:32 +0100 (BST) From: "Greg Hennessy" Date: Mon, 13 Jun 2005 17:52:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVwNYZgvIjqXNn4Sf6OufHbb/Qv9wAAc+WA In-Reply-To: <7c8f2792050613090040c924c3@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Message-Id: <20050613165202.51063DA@gw2.local.net> Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: RE: Carp Suppression 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: Mon, 13 Jun 2005 16:51:38 -0000 > The reason we are using CARP on a PLIP interface is to allow > us to have redundant connections between 2 transparent > bridging firewalls. CARP is not going to work with a layer 2 firewall. > Instead of sending packets over our network, we isolate them > onto a PLIP interface and crossover interface. That not going to work on a point to point connection, the other party cannot see the carp traffic. never mind the overhead that running plip puts on a system, a length of baling twine would make for a better physical transport. > We then use > ifstaded to monitor the carp interfaces and shut down > bridging on one of the machines. Spanning tree is a no brainer for such a setup, pfsync takes care of the rest. http://www.seattlecentral.edu/~dmartin/docs/bridge.html Greg > > I will refrain from submitting any code to the community in > the future. > > On 6/13/05, Yar Tikhiy wrote: > > On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote: > > > One last comment, > > > > > > I managed to fix it so that carp runs on the plip > interface by adding: > > > ifp->if_flags = LINK_STATE_UP; > > > > > > Here is the diff: > > > > > > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c > /usr/src/sys/dev/ppbus/if_plip.c > > > --- /usr.orig/src/sys/dev/ppbus/if_plip.c Wed Sep > 15 11:14:18 2004 > > > +++ /usr/src/sys/dev/ppbus/if_plip.c Mon Jun 13 10:05:56 2005 > > > @@ -359,6 +359,7 @@ > > > > > > ppb_wctr(ppbus, IRQENABLE); > > > ifp->if_flags |= IFF_RUNNING; > > > + ifp->if_flags = LINK_STATE_UP; > > > } > > > break; > > > > I'm afraid you're totally wrong here. > > > > First, I can't see how CARP is supposed to work on a PLIP > interface or > > any point-to-point interface at all. CARP is for broadcast > > interfaces, such as Ethernet or FDDI, which do ARP. You > seem to miss > > the point. > > > > Second, you can't store an arbitrary value into a variable or field > > and expect the things to work right. LINK_STATE_UP simply > is not for > > ifp->if_flags. Please make yourself familiar with the basics of > > computer programming before offering your patches to the community. > > > > -- > > Yar > > > > > -- > Joshua Kayse > Computer Engineering > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > > From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 17:35:14 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 B863016A41C for ; Mon, 13 Jun 2005 17:35:14 +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 B934643D58 for ; Mon, 13 Jun 2005 17:35:13 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1081485wra for ; Mon, 13 Jun 2005 10:35:12 -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=uh2zQ/B7hcgUt6DFMuOGKBwCg+eX4wWN6CmVJlCgzly0RyU6FxG9g6EkBxnNpCX1I5BClqYDF3K99KJjEnITtuwCZz1gEqPm25bjw7CsI3xp17Lc24VTYGrgUSNo74QOEqZRTwcQY/RhHklizO8iHRrnByFC4N3BjOyP92ARi6U= Received: by 10.54.30.40 with SMTP id d40mr2672843wrd; Mon, 13 Jun 2005 10:35:12 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Mon, 13 Jun 2005 10:35:12 -0700 (PDT) Message-ID: <7c8f27920506131035841d5d0@mail.gmail.com> Date: Mon, 13 Jun 2005 13:35:12 -0400 From: Josh Kayse To: Greg Hennessy In-Reply-To: <20050613165202.51063DA@gw2.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7c8f2792050613090040c924c3@mail.gmail.com> <20050613165202.51063DA@gw2.local.net> Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org 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: Mon, 13 Jun 2005 17:35:14 -0000 On 6/13/05, Greg Hennessy wrote: >=20 > > The reason we are using CARP on a PLIP interface is to allow > > us to have redundant connections between 2 transparent > > bridging firewalls. >=20 > CARP is not going to work with a layer 2 firewall. It's running over the PLIP interface and the crossover cable.=20 ifstated will change the advskew of the carp interfaces if one of the bridging interfaces goes down. >=20 > > Instead of sending packets over our network, we isolate them > > onto a PLIP interface and crossover interface. >=20 > That not going to work on a point to point connection, the other party > cannot see the carp traffic. > never mind the overhead that running plip puts on a system, a length of > baling twine would make for a better physical transport. Both firewalls can see the carp information over the PLIP connection, so I assume it works. And it wasn't my choice to use the plip interface. >=20 > > We then use > > ifstaded to monitor the carp interfaces and shut down > > bridging on one of the machines. >=20 > Spanning tree is a no brainer for such a setup, pfsync takes care of the > rest. >=20 We did not want to go with STP because it would not be a self contained solution. Now we can use these firewalls anywhere without having to modify any routers, just plug them in inline and it is set.=20 We also wanted to stick with FreeBSD because we have a knowledgebase already set up for it and we know how to use it. Unfortunately, there is no support for STP in freebsd bridging. Yes, I had already looked into using pfsync and STP, we also considered just using scripts. Anyway, I don't want to try and defend myself on our setup. We have everything working now and I just wanted to let others know how they could use carp over PLIP if they so needed to. > http://www.seattlecentral.edu/~dmartin/docs/bridge.html >=20 >=20 >=20 > Greg >=20 >=20 > > > > I will refrain from submitting any code to the community in > > the future. > > > > On 6/13/05, Yar Tikhiy wrote: > > > On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote: > > > > One last comment, > > > > > > > > I managed to fix it so that carp runs on the plip > > interface by adding: > > > > ifp->if_flags =3D LINK_STATE_UP; > > > > > > > > Here is the diff: > > > > > > > > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c > > /usr/src/sys/dev/ppbus/if_plip.c > > > > --- /usr.orig/src/sys/dev/ppbus/if_plip.c Wed Sep > > 15 11:14:18 2004 > > > > +++ /usr/src/sys/dev/ppbus/if_plip.c Mon Jun 13 10:05:56 2005 > > > > @@ -359,6 +359,7 @@ > > > > > > > > ppb_wctr(ppbus, IRQENABLE); > > > > ifp->if_flags |=3D IFF_RUNNING; > > > > + ifp->if_flags =3D LINK_STATE_UP; > > > > } > > > > break; > > > > > > I'm afraid you're totally wrong here. > > > > > > First, I can't see how CARP is supposed to work on a PLIP > > interface or > > > any point-to-point interface at all. CARP is for broadcast > > > interfaces, such as Ethernet or FDDI, which do ARP. You > > seem to miss > > > the point. > > > > > > Second, you can't store an arbitrary value into a variable or field > > > and expect the things to work right. LINK_STATE_UP simply > > is not for > > > ifp->if_flags. Please make yourself familiar with the basics of > > > computer programming before offering your patches to the community. > > > > > > -- > > > Yar > > > > > > > > > -- > > Joshua Kayse > > Computer Engineering > > _______________________________________________ > > freebsd-pf@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > > > > >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 --=20 Joshua Kayse Computer Engineering From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 17:40:23 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 34E2916A427; Mon, 13 Jun 2005 17:40:23 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC7D043D48; Mon, 13 Jun 2005 17:40:22 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5DHeMbW001229; Mon, 13 Jun 2005 10:40:22 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5DHeM3r001228; Mon, 13 Jun 2005 10:40:22 -0700 Date: Mon, 13 Jun 2005 10:40:22 -0700 From: Brooks Davis To: gtg062h@mail.gatech.edu Message-ID: <20050613174022.GA988@odin.ac.hmc.edu> References: <7c8f2792050613090040c924c3@mail.gmail.com> <20050613165202.51063DA@gw2.local.net> <7c8f27920506131035841d5d0@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <7c8f27920506131035841d5d0@mail.gmail.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org, Greg Hennessy , freebsd-pf@freebsd.org Subject: Re: Carp Suppression 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: Mon, 13 Jun 2005 17:40:23 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2005 at 01:35:12PM -0400, Josh Kayse wrote: > On 6/13/05, Greg Hennessy wrote: > > > We then use > > > ifstaded to monitor the carp interfaces and shut down > > > bridging on one of the machines. > >=20 > > Spanning tree is a no brainer for such a setup, pfsync takes care of the > > rest. > >=20 > We did not want to go with STP because it would not be a self > contained solution. Now we can use these firewalls anywhere without > having to modify any routers, just plug them in inline and it is set.=20 > We also wanted to stick with FreeBSD because we have a knowledgebase > already set up for it and we know how to use it. Unfortunately, there > is no support for STP in freebsd bridging. Yes, I had already looked > into using pfsync and STP, we also considered just using scripts. FYI, we have STP via if_bridge in 6.x. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCrcUFXY6L6fI4GtQRAjX0AKCLj6msFZs4G4rly1LOn2BbElTfMACaAj2Y 4uClrUNSqmQwh9S6yFqD4As= =6XH+ -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-pf@FreeBSD.ORG Mon Jun 13 21:23:50 2005 Return-Path: X-Original-To: freebsd-pf@hub.freebsd.org Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C168516A41C; Mon, 13 Jun 2005 21:23:50 +0000 (GMT) (envelope-from marcel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 817E743D48; Mon, 13 Jun 2005 21:23:50 +0000 (GMT) (envelope-from marcel@FreeBSD.org) Received: from freefall.freebsd.org (marcel@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5DLNosh069259; Mon, 13 Jun 2005 21:23:50 GMT (envelope-from marcel@freefall.freebsd.org) Received: (from marcel@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5DLNove069255; Mon, 13 Jun 2005 21:23:50 GMT (envelope-from marcel) Date: Mon, 13 Jun 2005 21:23:50 GMT From: Marcel Moolenaar Message-Id: <200506132123.j5DLNove069255@freefall.freebsd.org> To: marcel@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-pf@FreeBSD.org Cc: Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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: Mon, 13 Jun 2005 21:23:50 -0000 Synopsis: Unaligned Reference with pf on 5.4/IA64 Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: marcel Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005 Responsible-Changed-Why: Move to a more pf-focussed responsible party. http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 From owner-freebsd-pf@FreeBSD.ORG Tue Jun 14 10:16:10 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 BAC6016A41C; Tue, 14 Jun 2005 10:16:10 +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 1FD5C43D48; Tue, 14 Jun 2005 10:16:09 +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 j5EAG7Qd003141; Tue, 14 Jun 2005 14:16:07 +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 j5EAG6mU003136; Tue, 14 Jun 2005 14:16:06 +0400 (MSD) (envelope-from yar) Date: Tue, 14 Jun 2005 14:16:05 +0400 From: Yar Tikhiy To: Josh Kayse Message-ID: <20050614101605.GB470@comp.chem.msu.su> References: <7c8f2792050610090049064e11@mail.gmail.com> <7c8f279205061116021f55e8da@mail.gmail.com> <7c8f279205061307103b1782f4@mail.gmail.com> <20050613153550.GA54388@comp.chem.msu.su> <7c8f2792050613090040c924c3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c8f2792050613090040c924c3@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Carp Suppression 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: Tue, 14 Jun 2005 10:16:10 -0000 On Mon, Jun 13, 2005 at 12:00:36PM -0400, Josh Kayse wrote: > Definitely a typo on my part. It should be > ifp->if_link_state = LINK_STATE_UP > > The reason we are using CARP on a PLIP interface is to allow us to > have redundant connections between 2 transparent bridging firewalls. > Instead of sending packets over our network, we isolate them onto a > PLIP interface and crossover interface. We then use ifstaded to > monitor the carp interfaces and shut down bridging on one of the > machines. This point alone is interesting. FreeBSD doesn't seem to track link state on most non-MII interfaces yet, including SLIP, PPP, and PLIP. Doing so on interfaces that support a sort of keep-alives would be easy though. In theory, were real link state support available on such interfaces, you would be able to run ifstated on them directly. However, the whole design of your network looks like a hack to me. Why not to use conventional IP routing together with pfsync and CARP on the main network segments? > I will refrain from submitting any code to the community in the future. IMHO refraining from the submission of _untested_ code would suffice ;-) -- Yar From owner-freebsd-pf@FreeBSD.ORG Tue Jun 14 14:41: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 87D0E16A41F for ; Tue, 14 Jun 2005 14:41:07 +0000 (GMT) (envelope-from taglio@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CE2143D53 for ; Tue, 14 Jun 2005 14:41:06 +0000 (GMT) (envelope-from taglio@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so1816772wri for ; Tue, 14 Jun 2005 07:41: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mOIYbjk9bINSxPkkpU3qOh4ivLxil6xKLw2ztZxAMbAythO7bCNQwJruf3DxeRD1Mi6wQUv2n06bwtnBz/pLgJSPQdMkVxapsVOT9LcjUEVd9RyzpBhSXzemP+mb+hrN2b+CohhGai3lK7pkJr1bzIdFW2bG/JimfkjsGoDKsWc= Received: by 10.54.33.53 with SMTP id g53mr3254488wrg; Tue, 14 Jun 2005 07:41:06 -0700 (PDT) Received: by 10.54.38.41 with HTTP; Tue, 14 Jun 2005 07:41:06 -0700 (PDT) Message-ID: <31fbaca9050614074110bdf2cd@mail.gmail.com> Date: Tue, 14 Jun 2005 16:41:06 +0200 From: Riccardo Giuntoli To: Chris Dionissopoulos In-Reply-To: <002b01c56dde$ae305ea0$0100000a@R3B> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <31fbaca905061009107e7df9cf@mail.gmail.com> <002b01c56dde$ae305ea0$0100000a@R3B> Cc: freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: 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: Tue, 14 Jun 2005 14:41:07 -0000 On 6/10/05, Chris Dionissopoulos wrote: ... > Try to create a new kernel with timing at 1000hz and if > your hardware (nic) is supported enable device polling > (polling(4)). ... Hi Chris, i've put polling up in my kernel with timing at 2000hz and kern.polling.burst_max=3D400, that are the parameters that the polling's writer says to put fot a gigabit nic in an old thread: http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002719.html But now, without no load no band saturate nothing, the system connections from process in user space collapse after 5 Mbit/s ddos!!!!! Please help i'm completly confused --=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 Tue Jun 14 16:58:45 2005 Return-Path: X-Original-To: freebsd-pf@hub.freebsd.org Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DBF816A41C; Tue, 14 Jun 2005 16:58:45 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8A6943D55; Tue, 14 Jun 2005 16:58:44 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5EGwihe065812; Tue, 14 Jun 2005 16:58:44 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5EGwin3065808; Tue, 14 Jun 2005 16:58:44 GMT (envelope-from arved) Date: Tue, 14 Jun 2005 16:58:44 GMT From: Tilman Linneweh Message-Id: <200506141658.j5EGwin3065808@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org Cc: Subject: Re: conf/81042: /etc/pf.os doesn't match FreeBSD 5.3->5.4 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: Tue, 14 Jun 2005 16:58:45 -0000 Synopsis: /etc/pf.os doesn't match FreeBSD 5.3->5.4 Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: arved Responsible-Changed-When: Tue Jun 14 16:58:22 GMT 2005 Responsible-Changed-Why: Over to FreeBSD pf Maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=81042 From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 06:33: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 75C8916A41C for ; Wed, 15 Jun 2005 06:33:55 +0000 (GMT) (envelope-from art@okunev.com) Received: from server7.vnpages.net (server7.vnpages.net [216.152.251.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 518DA43D1F for ; Wed, 15 Jun 2005 06:33:55 +0000 (GMT) (envelope-from art@okunev.com) Received: from [203.84.225.2] (helo=dell4150.hostway.net.au) by server7.vnpages.net with esmtpa (Exim 4.50) id 1DiRTT-00032V-HR for freebsd-pf@freebsd.org; Tue, 14 Jun 2005 23:34:08 -0700 Date: Wed, 15 Jun 2005 16:33:49 +1000 From: Art Okunev X-Mailer: The Bat! (v3.5) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <105247053.20050615163349@okunev.com> To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------7B10F1639BE0CF7" X-PopBeforeSMTPSenders: art@okunev.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server7.vnpages.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - okunev.com X-Source: X-Source-Args: X-Source-Dir: Subject: FTP reverse proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Art Okunev 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, 15 Jun 2005 06:33:55 -0000 ------------7B10F1639BE0CF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 SGVsbG8gZnJlZWJzZC1wZiwNCg0KICBJJ20gaW4gdGhlIHByb2Nlc3Mgb2YgbWlncmF0aW5n IExpbnV4IGJhc2VkIGZpcmV3YWxsL3JvdXRlciB0bw0KICBGcmVlQlNEIChQRikuDQoNCiAg RmlyZXdhbGwgc3VwcG9zZWQgdG8gYmUgd29ya2luZyBpbiBhIGhvc3RpbmcgZW52aXJvbm1l bnQgc28gYWN0dWFsbHkNCiAgZXh0ZXJuYWwgaW50ZXJmYWNlIGlzIGNvbm5lY3RlZCB0byB1 cGxpbmsgcm91dGVyOyBiZWhpbmQgZmlyZXdhbGwNCiAgYXJlICBjb3VwbGUgb2YgY2xhc3Mg QyBuZXR3b3JrcyB3aXRoIGJ1bmNoIG9mIHdlYiBhbmQgRlRQIHNlcnZlcnMuDQoNCiAgVGhl ICBvbmx5ICB0aGluZyAgSSBhbSBtaXNzaW5nIGZyb20gTGludXggaXMgaXBfY29ubnRyYWNr X2Z0cCBrZXJuZWwNCiAgbW9kdWxlICB3aGljaCAgbW9uaXRvcnMgdGhlIHRyYWZmaWMgb24g cG9ydCAyMSBhbmQgZHluYW1pY2FsbHkgb3BlbnMNCiAgdGhlIGhpZ2hlciBubyAoZGF0YSkg cG9ydHMgdGhhdCB0aGUgY29udHJvbCBvbiBwb3J0IDIxIGFza3MgZm9yLg0KDQogIE1heWJl ICBJJ20gIHdyb25nICBidXQgIGl0ICBzZWVtcyAgdGhhdCBmdHAtcHJveHkgb25seSB3b3Jr cyBmb3IgZnRwDQogIGNsaWVudHMgYmVoaW5kIGZ0cC1wcm94eS4NCg0KICBBbm90aGVyICBi YWQgdGhpbmcgYWJvdXQgdGhpcyBzZXR1cCBpcyB0aGF0IG5ldHdvcmtzIGJlaGluZCBmaXJl d2FsbA0KICBtYW5hZ2VkIGJ5IG91ciBjbGllbnRzIHNvIGl0IGlzIG5vdCBwb3NzaWJsZSB0 byBrbm93IElQIGFkZHJlc3NlcyBvZg0KICBGVFAgc2VydmVycyBhbmQgZXBoZW1lcmFsIHBv cnQgcmFuZ2VzIHRoZXkgYXJlIHVzaW5nLg0KDQogIFNvIGZhciBJIGhhdmUgdG8gcHV0IHNv bWV0aGluZyBsaWtlOg0KDQogIHBhc3MgYWxsIHByb3RvIHRjcCBmcm9tIGFueSBwb3J0IDEw MjQ6NjU1MzUgdG8gYW55IHBvcnQgMTAyNDo2NTUzNQ0KDQogIGluIG9yZGVyIHRvIGFsbG93 IHBhc3NpdmUgRlRQIChJIGhhdGUgdGhpcyBpZGVhISkuDQoNCiAgSXMgdGhlcmUgYW55ICJj b3JyZWN0IiB3YXkgdG8gY29uZmlndXJlIFBGIHRvIGFsbG93IHBhc3NpdmUgbW9kZSBmdHAN CiAgY29ubmVjdGlvbiAgdG8gIEZUUCAgc2VydmVycyAgYmVoaW5kIGZpcmV3YWxsIHdpdGhv dXQgaGF2aW5nIHRvIG9wZW4NCiAgaGlnaGVyIHBvcnRzIGZvciBhbGwgbmV0d29yayByYW5n ZT8NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQogQXJ0ICAgICAgICAgICAgICAgICAgICAgICAg ICBtYWlsdG86YXJ0QG9rdW5ldi5jb20NCg== ------------7B10F1639BE0CF7 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCr8vN9Cyfi5N8P54RAo41AJkBwWCgzFvkmTEKBygoDOiV1RUDbQCffz58 K5jeQPzeFhxpt9ftwomQhdQ= =+yAX -----END PGP MESSAGE----- ------------7B10F1639BE0CF7-- From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 11:37:17 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 EAED516A41C for ; Wed, 15 Jun 2005 11:37:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E62E43D55 for ; Wed, 15 Jun 2005 11:37:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E34D.dip.t-dialin.net [84.163.227.77] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML25U-1DiWCp1KyG-0001IK; Wed, 15 Jun 2005 13:37:15 +0200 From: Max Laier To: freebsd-pf@freebsd.org, Art Okunev Date: Wed, 15 Jun 2005 13:37:04 +0200 User-Agent: KMail/1.8 References: <105247053.20050615163349@okunev.com> In-Reply-To: <105247053.20050615163349@okunev.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4721502.WL7hUlFlmH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506151337.13051.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: FTP reverse proxy 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, 15 Jun 2005 11:37:18 -0000 --nextPart4721502.WL7hUlFlmH Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 15 June 2005 08:33, Art Okunev wrote: > Hello freebsd-pf, > > I'm in the process of migrating Linux based firewall/router to > FreeBSD (PF). > > Firewall supposed to be working in a hosting environment so actually > external interface is connected to uplink router; behind firewall > are couple of class C networks with bunch of web and FTP servers. > > The only thing I am missing from Linux is ip_conntrack_ftp kernel > module which monitors the traffic on port 21 and dynamically opens > the higher no (data) ports that the control on port 21 asks for. > > Maybe I'm wrong but it seems that ftp-proxy only works for ftp > clients behind ftp-proxy. > > Another bad thing about this setup is that networks behind firewall > managed by our clients so it is not possible to know IP addresses of > FTP servers and ephemeral port ranges they are using. > > So far I have to put something like: > > pass all proto tcp from any port 1024:65535 to any port 1024:65535 > > in order to allow passive FTP (I hate this idea!). > > Is there any "correct" way to configure PF to allow passive mode ftp > connection to FTP servers behind firewall without having to open > higher ports for all network range? Did you see: http://www.sentia.org/projects/ftpsesame/ ? =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 --nextPart4721502.WL7hUlFlmH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCsBLoXyyEoT62BG0RAjf0AJ9y7pGaAvgAlpMuzz2oaW28AzzjjACePLNB ouU1ejy6EKWyMDKMt40TGxo= =82Fh -----END PGP SIGNATURE----- --nextPart4721502.WL7hUlFlmH-- From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 14:39: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 53D3016A41C; Wed, 15 Jun 2005 14:39:34 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7ABF43D4C; Wed, 15 Jun 2005 14:39:33 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j5FEdLYZ091353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2005 18:39:22 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j5FEdKTG008740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 18:39:21 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5FEdKe0008739; Wed, 15 Jun 2005 18:39:20 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Jun 2005 18:39:19 +0400 From: Gleb Smirnoff To: gtg062h@mail.gatech.edu Message-ID: <20050615143919.GE8060@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , gtg062h@mail.gatech.edu, Yar Tikhiy , freebsd-net@freebsd.org, freebsd-pf@freebsd.org References: <7c8f2792050610090049064e11@mail.gmail.com> <7c8f279205061116021f55e8da@mail.gmail.com> <7c8f279205061307103b1782f4@mail.gmail.com> <20050613153550.GA54388@comp.chem.msu.su> <7c8f2792050613090040c924c3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <7c8f2792050613090040c924c3@mail.gmail.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean Cc: freebsd-pf@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Carp Suppression 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, 15 Jun 2005 14:39:34 -0000 On Mon, Jun 13, 2005 at 12:00:36PM -0400, Josh Kayse wrote: J> The reason we are using CARP on a PLIP interface is to allow us to J> have redundant connections between 2 transparent bridging firewalls. J> Instead of sending packets over our network, we isolate them onto a J> PLIP interface and crossover interface. We then use ifstaded to J> monitor the carp interfaces and shut down bridging on one of the J> machines. AFAIU, you use PLIP line as some flag that triggers suppression. If slave "sees" master via PLIP, it keeps itself in slave mode. May be I don't understand you right. Although the idea is not officially supported, it is interesting. Can you please draw your setup, since I don't understand it clearly? Bringing link state support for p2p interfaces is a TODO, although CARP is not going to be supported on p2p interfaces officially. J> I will refrain from submitting any code to the community in the future. Why? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 18:32:20 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 E47D816A41C for ; Wed, 15 Jun 2005 18:32:20 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 950DC43D1D for ; Wed, 15 Jun 2005 18:32:20 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1860388wra for ; Wed, 15 Jun 2005 11:32:19 -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=LzzoEhFQavuGtifZvCEWZuL+0xDy2RskM8qoeZ5ixOmBdFn57GM1ip5p335Kcn7wf4hRS0t5pGKCODkOan2D392rP5zt2UaRe/PCXje+8qjqASpL12bYE+MXwF3IqKDdx1T+RgytK1TmjsKn84UG9gzHJCNOeLUp2/9bq5mG2cU= Received: by 10.54.101.10 with SMTP id y10mr28149wrb; Wed, 15 Jun 2005 11:32:19 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Wed, 15 Jun 2005 11:32:19 -0700 (PDT) Message-ID: <7c8f27920506151132670c035@mail.gmail.com> Date: Wed, 15 Jun 2005 14:32:19 -0400 From: Josh Kayse To: Gleb Smirnoff , Yar Tikhiy , freebsd-net@freebsd.org, freebsd-pf@freebsd.org In-Reply-To: <20050615143919.GE8060@cell.sick.ru> 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> <7c8f279205061116021f55e8da@mail.gmail.com> <7c8f279205061307103b1782f4@mail.gmail.com> <20050613153550.GA54388@comp.chem.msu.su> <7c8f2792050613090040c924c3@mail.gmail.com> <20050615143919.GE8060@cell.sick.ru> 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: Wed, 15 Jun 2005 18:32:21 -0000 On 6/15/05, Gleb Smirnoff wrote: =20 > AFAIU, you use PLIP line as some flag that triggers suppression. If > slave "sees" master via PLIP, it keeps itself in slave mode. May be > I don't understand you right. >=20 > Although the idea is not officially supported, it is interesting. Can you > please draw your setup, since I don't understand it clearly? >=20 __________ em0 | |em1 ------------| FW1 |----------- |_________| xl0(carp0)| | plip0(carp1) ___|___|___ em0 | | em1 -----------| FW2 |---------- |__________| Bridging is done through em0/em1 which are both monitored by ifstated for link state only (backported patch from HEAD). When one of the bridging ports is disconnected, ifstaded changes the advskew of carp0 and carp1 to 254 so that the carp interfaces failover. When ifstated see the carp interfaces as BOTH master, the slave firewall takes over bridging. This gives us redundant firewalls, with redundant heartbeat connections. > Bringing link state support for p2p interfaces is a TODO, although > CARP is not going to be supported on p2p interfaces officially. >=20 > J> I will refrain from submitting any code to the community in the future= . >=20 > Why? I was just grumpy, we had just expanded server room and everything broke, etc etc. Don't mind me at all. If you have any other questions, just let me know. PS. I stink at ascii drawings. --=20 Joshua Kayse Computer Engineering From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 20:42:32 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 23F8116A41C; Wed, 15 Jun 2005 20:42:32 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89B4543D49; Wed, 15 Jun 2005 20:42:31 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.3/8.12.11) with ESMTP id j5FKgWOm009630 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 22:42:32 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id j5FKgWNA032731; Wed, 15 Jun 2005 22:42:32 +0200 (MEST) Date: Wed, 15 Jun 2005 22:42:32 +0200 From: Daniel Hartmeier To: Marcel Moolenaar Message-ID: <20050615204232.GX8526@insomnia.benzedrine.cx> References: <200506132123.j5DLNove069255@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506132123.j5DLNove069255@freefall.freebsd.org> User-Agent: Mutt/1.5.6i Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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, 15 Jun 2005 20:42:32 -0000 On Mon, Jun 13, 2005 at 09:23:50PM +0000, Marcel Moolenaar wrote: > Synopsis: Unaligned Reference with pf on 5.4/IA64 > > Responsible-Changed-From-To: freebsd-net->freebsd-pf > Responsible-Changed-By: marcel > Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005 > Responsible-Changed-Why: > Move to a more pf-focussed responsible party. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 If I understand the problem correctly, there is an underlying network-generic question I'd like to ask here. When a function in the kernel gets passed a struct ip pointer, can it assume that the struct ip object pointed to is properly aligned? Or should it assume that this is not the case, and extract members more carefully? We can fix the access in pf of course, but if other functions rightfully count on struct ip objects being properly aligned, this might simply crash outside of pf, too. In short, is the problem that bridge doesn't properly align the struct ip object (which I can try to fix, too), or that pf assumes that such objects should be aligned? On OpenBSD's 64-bit architectures with varying alignment rules, this has never occured, I think because the struct ip objects (and, hence, their ip_src/dst members) are kept aligned. If I'm way off, and proper alignment of struct ip objects does not guarantee proper alignment of the ip_src/dst members as 32-bit unsigneds, please explain. If ia64 is different from other 64-bit architectures (of which I only know amd64, sparc64 and alpha), please explain what alignment rules there are for u_int32_t. Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 21:23:49 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 D979916A41C; Wed, 15 Jun 2005 21:23:49 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F9D43D48; Wed, 15 Jun 2005 21:23:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j5FLNRvj008982; Wed, 15 Jun 2005 14:23:28 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050615204232.GX8526@insomnia.benzedrine.cx> References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 15 Jun 2005 14:23:24 -0700 To: Daniel Hartmeier X-Mailer: Apple Mail (2.622) Cc: freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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, 15 Jun 2005 21:23:50 -0000 On Jun 15, 2005, at 1:42 PM, Daniel Hartmeier wrote: > On Mon, Jun 13, 2005 at 09:23:50PM +0000, Marcel Moolenaar wrote: > >> Synopsis: Unaligned Reference with pf on 5.4/IA64 >> >> Responsible-Changed-From-To: freebsd-net->freebsd-pf >> Responsible-Changed-By: marcel >> Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005 >> Responsible-Changed-Why: >> Move to a more pf-focussed responsible party. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 > > If I understand the problem correctly, there is an underlying > network-generic question I'd like to ask here. > > When a function in the kernel gets passed a struct ip pointer, can it > assume that the struct ip object pointed to is properly aligned? Or > should it assume that this is not the case, and extract members more > carefully? That entirely depends. If a struct ip pointer is constructed without any form of casting, then one can assume that alignment is guaranteed. The compiler guarantees to do so, except of course in this case: the structure is defined as a packed structure. We, as the developers, have told the compiler to *NOT* guarantee alignment of fields. We're on our own and we miserably fail being on our own. > We can fix the access in pf of course, but if other functions > rightfully > count on struct ip objects being properly aligned, this might simply > crash outside of pf, too. True. But since struct ip is defined as packed, nobody can assume proper alignment of multi-byte fields and all code needs to be fixed if such assumptions are being made. > In short, is the problem that bridge doesn't properly align the struct > ip object (which I can try to fix, too), or that pf assumes that such > objects should be aligned? pf(4) falsely assumes alignment. > If I'm way off, and proper alignment of struct ip objects does not > guarantee proper alignment of the ip_src/dst members as 32-bit > unsigneds, please explain. You're not way off. It's just that we tried to outsmart ourselves by telling the compiler that it should not enforce proper alignment of fields in struct ip. > If ia64 is different from other 64-bit > architectures (of which I only know amd64, sparc64 and alpha), please > explain what alignment rules there are for u_int32_t. ia64 is not different in this respect. That's why the bug is not specific to ia64. Note that amd64 may not be a perfect reference in this case because it's too much like i386, which does unaligned loads and stores. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 22:35: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 116AE16A41C; Wed, 15 Jun 2005 22:35:00 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 678A843D4C; Wed, 15 Jun 2005 22:34:59 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.3/8.12.11) with ESMTP id j5FMYtgj006623 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2005 00:34:55 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id j5FMYod1011692; Thu, 16 Jun 2005 00:34:50 +0200 (MEST) Date: Thu, 16 Jun 2005 00:34:50 +0200 From: Daniel Hartmeier To: Marcel Moolenaar Message-ID: <20050615223450.GY8526@insomnia.benzedrine.cx> References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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, 15 Jun 2005 22:35:00 -0000 On Wed, Jun 15, 2005 at 02:23:24PM -0700, Marcel Moolenaar wrote: > That entirely depends. If a struct ip pointer is constructed without > any form of casting, then one can assume that alignment is guaranteed. > The compiler guarantees to do so, except of course in this case: > the structure is defined as a packed structure. We, as the developers, > have told the compiler to *NOT* guarantee alignment of fields. We're > on our own and we miserably fail being on our own. 'packed', as I understand it, prohibits the compiler from inserting any padding anywhere in the struct. That is, it guarantees that the total size of a struct object equals the sum of the sizes of its members. As a consequence, individual members can't be aligned properly if that would require padding in front of them. The compiler can (and must?) still align the first member, i.e. the beginning of the struct object, though, no? The IP header and the struct that represents it are defined very carefully. It's no coincidence that ip_src/dst are placed where they are: struct ip { u_int ip_hl:4, /* header length */ ip_v:4; /* version */ u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset field */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src,ip_dst; /* source and dest address */ } __packed; This guarantees that struct ip h; &h.ip_src == (char *)&h + 12 &h.ip_dst == (char *)&h + 16 i.e. they are both on 32-bit aligned if h itself is 32-bit aligned. If you look at any example in sys/netinet where struct ip members are accessed, you see direct access to both u_short and uint32_t members. Nowhere does anyone memcpy, bcopy or char-wise-copy ip_src/dst, for instance. The issue also involves how the IP header is aligned within mbufs. Functions usually get passed an mbuf pointer, and do struct mbuf *m; struct ip *ip = mtod(m, struct ip *); and then happily access ip_src/dst without further alignment checks. So, are you really sure we should do differently in pf, instead of looking for a bridge problem, where bridge constructs an mbuf with the IP header not properly aligned? I.e. if the IP header is properly aligned within the mbuf (on 32-bit boundaries, I presume), wouldn't ip_src/dst have to be properly aligned as well, even though __packed is used, because the layout of struct ip is chosen like that? Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 22:57:37 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 5479516A41C; Wed, 15 Jun 2005 22:57:37 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0970F43D4C; Wed, 15 Jun 2005 22:57:36 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j5FMvNCc009334; Wed, 15 Jun 2005 15:57:23 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050615223450.GY8526@insomnia.benzedrine.cx> References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> <20050615223450.GY8526@insomnia.benzedrine.cx> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 15 Jun 2005 15:57:20 -0700 To: Daniel Hartmeier X-Mailer: Apple Mail (2.622) Cc: freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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, 15 Jun 2005 22:57:37 -0000 On Jun 15, 2005, at 3:34 PM, Daniel Hartmeier wrote: > On Wed, Jun 15, 2005 at 02:23:24PM -0700, Marcel Moolenaar wrote: > >> That entirely depends. If a struct ip pointer is constructed without >> any form of casting, then one can assume that alignment is guaranteed. >> The compiler guarantees to do so, except of course in this case: >> the structure is defined as a packed structure. We, as the developers, >> have told the compiler to *NOT* guarantee alignment of fields. We're >> on our own and we miserably fail being on our own. > > 'packed', as I understand it, prohibits the compiler from inserting any > padding anywhere in the struct. That is, it guarantees that the total > size of a struct object equals the sum of the sizes of its members. > > As a consequence, individual members can't be aligned properly if that > would require padding in front of them. The compiler can (and must?) > still align the first member, i.e. the beginning of the struct object, > though, no? No, it can't guarantee alignment of the first field and consequently will not bother trying. The best way to picture this is with an array. Alignment guarantees has to come from the implementation, the compiler will not guarantee alignment. > So, are you really sure we should do differently in pf, instead of > looking for a bridge problem, where bridge constructs an mbuf with the > IP header not properly aligned? I've not been sure to begin with. I forwarded this PR because I have no clue as to where the root problem is. If you say that pf(4) is not at fault and it's the bridge code then fine, fix the bridge code. All I see is an unaligned memory access and plenty of yellow flags in the source code. > I.e. if the IP header is properly aligned within the mbuf (on 32-bit > boundaries, I presume), wouldn't ip_src/dst have to be properly aligned > as well, even though __packed is used, because the layout of struct ip > is chosen like that? Yes. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 23:15:05 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 5DE1916A41C for ; Wed, 15 Jun 2005 23:15:05 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: from home.quip.cz (r3ar5.chello.upc.cz [213.220.235.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F3F43D49 for ; Wed, 15 Jun 2005 23:15:02 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: from [192.168.1.2] (qwork.quip.test [192.168.1.2]) by home.quip.cz (Postfix) with ESMTP id 49B077CFE for ; Thu, 16 Jun 2005 01:15:00 +0200 (CEST) Message-ID: <42B0B674.1010403@quip.cz> Date: Thu, 16 Jun 2005 01:15:00 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: cs, cz, en, en-us MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <105247053.20050615163349@okunev.com> <200506151337.13051.max@love2party.net> In-Reply-To: <200506151337.13051.max@love2party.net> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FTP reverse proxy 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, 15 Jun 2005 23:15:05 -0000 Is ftpsesame working on FreeBSD 5.4? I found ftpsesame webpage a few days ago, but available downloads is marked as Download ftpsesame-0.91 for OpenBSD 3.4 and 3.5. Download ftpsesame-0.95 for OpenBSD 3.6. Max Laier wrote: > On Wednesday 15 June 2005 08:33, Art Okunev wrote: > >>Hello freebsd-pf, >> >> I'm in the process of migrating Linux based firewall/router to >> FreeBSD (PF). >> >> Firewall supposed to be working in a hosting environment so actually >> external interface is connected to uplink router; behind firewall >> are couple of class C networks with bunch of web and FTP servers. >> >> The only thing I am missing from Linux is ip_conntrack_ftp kernel >> module which monitors the traffic on port 21 and dynamically opens >> the higher no (data) ports that the control on port 21 asks for. >> >> Maybe I'm wrong but it seems that ftp-proxy only works for ftp >> clients behind ftp-proxy. >> >> Another bad thing about this setup is that networks behind firewall >> managed by our clients so it is not possible to know IP addresses of >> FTP servers and ephemeral port ranges they are using. >> >> So far I have to put something like: >> >> pass all proto tcp from any port 1024:65535 to any port 1024:65535 >> >> in order to allow passive FTP (I hate this idea!). >> >> Is there any "correct" way to configure PF to allow passive mode ftp >> connection to FTP servers behind firewall without having to open >> higher ports for all network range? > > > Did you see: > http://www.sentia.org/projects/ftpsesame/ ? > -- Miroslav Lachman Webapplication Developer From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 23:52:04 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 996EC16A420 for ; Wed, 15 Jun 2005 23:52:04 +0000 (GMT) (envelope-from art@okunev.com) Received: from server7.vnpages.net (server7.vnpages.net [216.152.251.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D61F43D55 for ; Wed, 15 Jun 2005 23:52:04 +0000 (GMT) (envelope-from art@okunev.com) Received: from [203.84.225.2] (helo=dell4150.hostway.net.au) by server7.vnpages.net with esmtpa (Exim 4.50) id 1Dihg3-0004T0-Kg; Wed, 15 Jun 2005 16:52:11 -0700 Date: Thu, 16 Jun 2005 09:51:58 +1000 From: Art Okunev X-Mailer: The Bat! (v3.5) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <137200685.20050616095158@okunev.com> To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <42B0B674.1010403@quip.cz> References: <105247053.20050615163349@okunev.com> <200506151337.13051.max@love2party.net> <42B0B674.1010403@quip.cz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------12221627BB051D" X-PopBeforeSMTPSenders: art@okunev.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server7.vnpages.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - okunev.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-pf@freebsd.org Subject: Re[2]: FTP reverse proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Art Okunev 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, 15 Jun 2005 23:52:04 -0000 ------------12221627BB051D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 SGVsbG8gTWlyb3NsYXYsDQoNClRodXJzZGF5LCBKdW5lIDE2LCAyMDA1LCA5OjE1OjAwIEFN LCB5b3Ugd3JvdGU6DQoNCj4gSXMgZnRwc2VzYW1lIHdvcmtpbmcgb24gRnJlZUJTRCA1LjQ/ IEkgZm91bmQgZnRwc2VzYW1lIHdlYnBhZ2UgYSBmZXcNCj4gZGF5cyBhZ28sIGJ1dCBhdmFp bGFibGUgZG93bmxvYWRzIGlzIG1hcmtlZCBhcw0KPiBEb3dubG9hZCBmdHBzZXNhbWUtMC45 MSBmb3IgT3BlbkJTRCAzLjQgYW5kIDMuNS4NCj4gRG93bmxvYWQgZnRwc2VzYW1lLTAuOTUg Zm9yIE9wZW5CU0QgMy42Lg0KDQpKdXN0IHRyaWVkIHRvIGNvbXBpbGUgYm90aCAwLjkxIGFu ZCAwLjk1IG9uIEZyZWVCU0QgNS40IC0gbm8gbHVjayA6KA0KDQotLSANCkJlc3QgcmVnYXJk cywNCiBBcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFpbHRvOmFydEBva3VuZXYu Y29tDQo= ------------12221627BB051D Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCsL8e9Cyfi5N8P54RArdzAJ9HU8iBzq0jnk6Gn8ijRwTvL7BXCACeMaph +R+qcF0rAhNszq20trs2aiI= =GgZQ -----END PGP MESSAGE----- ------------12221627BB051D-- From owner-freebsd-pf@FreeBSD.ORG Wed Jun 15 23:56:52 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 2BE3B16A41C for ; Wed, 15 Jun 2005 23:56:52 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id D566343D1F for ; Wed, 15 Jun 2005 23:56:51 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so29148rna for ; Wed, 15 Jun 2005 16:56:51 -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=urMEYUSE8bs1WI3o2mDsS+bSJG4zv5LGlWlk7gonwyazEljPJcfiyyTuSyxRxFMZOUeAmglprfCGb933k0TqmlBP29yevJT3oH4P7I0H5phFOVJw/SUvE4MG3pEV+P3gcz4z5quea+q2EAuHdbIsp7ls7KZeY1PuDQcp1VWxm3g= Received: by 10.38.73.68 with SMTP id v68mr116559rna; Wed, 15 Jun 2005 16:56:51 -0700 (PDT) Received: by 10.38.207.79 with HTTP; Wed, 15 Jun 2005 16:56:51 -0700 (PDT) Message-ID: Date: Wed, 15 Jun 2005 19:56:51 -0400 From: Scott Ullrich To: Art Okunev In-Reply-To: <137200685.20050616095158@okunev.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <105247053.20050615163349@okunev.com> <200506151337.13051.max@love2party.net> <42B0B674.1010403@quip.cz> <137200685.20050616095158@okunev.com> Cc: freebsd-pf@freebsd.org Subject: Re: Re[2]: FTP reverse proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scott Ullrich 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, 15 Jun 2005 23:56:52 -0000 On 6/15/05, Art Okunev wrote: > Just tried to compile both 0.91 and 0.95 on FreeBSD 5.4 - no luck :( Give http://www.pfsense.com/~sullrich/ftpsesame-0.95.tgz a try. We previously used ftp-sesame on pfSense before switching to pftpx.=20 I can get you a copy of pftpx that works on 5.X and 6.X as well.. Just let me know. Scott From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 00:21:21 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 1953516A41C for ; Thu, 16 Jun 2005 00:21:21 +0000 (GMT) (envelope-from art@okunev.com) Received: from server7.vnpages.net (server7.vnpages.net [216.152.251.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id F051A43D48 for ; Thu, 16 Jun 2005 00:21:20 +0000 (GMT) (envelope-from art@okunev.com) Received: from [203.84.225.2] (helo=dell4150.hostway.net.au) by server7.vnpages.net with esmtpa (Exim 4.50) id 1Dii8Q-0000j7-II; Wed, 15 Jun 2005 17:21:30 -0700 Date: Thu, 16 Jun 2005 10:21:13 +1000 From: Art Okunev X-Mailer: The Bat! (v3.5) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <1535382865.20050616102113@okunev.com> To: Scott Ullrich In-Reply-To: References: <105247053.20050615163349@okunev.com> <200506151337.13051.max@love2party.net> <42B0B674.1010403@quip.cz> <137200685.20050616095158@okunev.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------E18224A13B20AE9" X-PopBeforeSMTPSenders: art@okunev.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server7.vnpages.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - okunev.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-pf@freebsd.org Subject: Re: FTP reverse proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Art Okunev 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, 16 Jun 2005 00:21:21 -0000 ------------E18224A13B20AE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 SGVsbG8gU2NvdHQsDQoNClRodXJzZGF5LCBKdW5lIDE2LCAyMDA1LCA5OjU2OjUxIEFNLCB5 b3Ugd3JvdGU6DQoNCj4gT24gNi8xNS8wNSwgQXJ0IE9rdW5ldiA8YXJ0QG9rdW5ldi5jb20+ IHdyb3RlOg0KPj4gSnVzdCB0cmllZCB0byBjb21waWxlIGJvdGggMC45MSBhbmQgMC45NSBv biBGcmVlQlNEIDUuNCAtIG5vIGx1Y2sgOigNCg0KPiBHaXZlIGh0dHA6Ly93d3cucGZzZW5z ZS5jb20vfnN1bGxyaWNoL2Z0cHNlc2FtZS0wLjk1LnRneiBhIHRyeS4NCj4gV2UgcHJldmlv dXNseSB1c2VkIGZ0cC1zZXNhbWUgb24gcGZTZW5zZSBiZWZvcmUgc3dpdGNoaW5nIHRvIHBm dHB4LiANCg0KVGhhbmtzLCBTY290dC4gSGFkIG5vIGNoYW5jZSB0byB0ZXN0IGZ0cHNlc2Ft ZSB5b3Ugc2VudCBpbiByZWFsIHNldHVwDQpidXQgYXQgbGVhc3QgaXQgY29tcGlsZXMgb24g RnJlZUJTRC4NCg0KPiBJICBjYW4gIGdldCAgeW91IGEgY29weSBvZiBwZnRweCB0aGF0IHdv cmtzIG9uIDUuWCBhbmQgNi5YIGFzIHdlbGwuLg0KPiBKdXN0IGxldCBtZSBrbm93DQoNCldv dWxkICBiZSAgbmljZSAgdG8gIGhhdmUgIHBmdHB4IGFzIHdlbGwgKCBJIGJlbGlldmUgaXQg aXMgYSBwcmVmZXJyZWQNCnNvbHV0aW9uIG5vdyBhY2NvcmRpbmcgdG8gT3BlbkJTRCBtYWls IGxpc3RzKS4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQogQXJ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG1haWx0bzphcnRAb2t1bmV2LmNvbQ0K ------------E18224A13B20AE9 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCsMX59Cyfi5N8P54RAr7fAJ4moHgzyX8d32NdUxBKqZioLwABGwCeJwrQ HQ0wpX1TUlZC1eL+XzdIUYI= =8YSm -----END PGP MESSAGE----- ------------E18224A13B20AE9-- From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 00:39: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 1674016A41C for ; Thu, 16 Jun 2005 00:39:30 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1A2343D49 for ; Thu, 16 Jun 2005 00:39:29 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so34271rna for ; Wed, 15 Jun 2005 17:39:29 -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=t6jbRrvztCFwrkdd1RgP9zwQB1XP3bu2IFk0v8ABc10SsxeBdMLlFAC/UJ5w2ZW8zbXYXDGeh6JL+9kmoLW58owN/rfu5ZdoBcTAFGBG76tdNqZFr3U8QDuY7q1TZehI3pOZcIWmiJjmdSkvwEbtwYzsO9Ra5D1Vkr1fPPe9K4U= Received: by 10.38.90.78 with SMTP id n78mr134935rnb; Wed, 15 Jun 2005 17:39:29 -0700 (PDT) Received: by 10.38.207.79 with HTTP; Wed, 15 Jun 2005 17:39:28 -0700 (PDT) Message-ID: Date: Wed, 15 Jun 2005 20:39:29 -0400 From: Scott Ullrich To: Art Okunev In-Reply-To: <1535382865.20050616102113@okunev.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <105247053.20050615163349@okunev.com> <200506151337.13051.max@love2party.net> <42B0B674.1010403@quip.cz> <137200685.20050616095158@okunev.com> <1535382865.20050616102113@okunev.com> Cc: freebsd-pf@freebsd.org Subject: Re: FTP reverse proxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scott Ullrich 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, 16 Jun 2005 00:39:30 -0000 On 6/15/05, Art Okunev wrote: > Hello Scott, >=20 > Thursday, June 16, 2005, 9:56:51 AM, you wrote: >=20 > > On 6/15/05, Art Okunev wrote: > >> Just tried to compile both 0.91 and 0.95 on FreeBSD 5.4 - no luck :( >=20 > > Give http://www.pfsense.com/~sullrich/ftpsesame-0.95.tgz a try. > > We previously used ftp-sesame on pfSense before switching to pftpx. >=20 > Thanks, Scott. Had no chance to test ftpsesame you sent in real setup > but at least it compiles on FreeBSD. >=20 > > I can get you a copy of pftpx that works on 5.X and 6.X as well.. > > Just let me know >=20 > Would be nice to have pftpx as well ( I believe it is a preferred > solution now according to OpenBSD mail lists). >=20 > -- > Best regards, > Art mailto:art@okunev.com >=20 >=20 Not a problem. It's posted as well. This was built with current. http://www.pfsense.com/~sullrich/pftpx-0.8.tgz Scott From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 06:01:10 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 81E7C16A41C; Thu, 16 Jun 2005 06:01:10 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FBBA43D49; Thu, 16 Jun 2005 06:01:10 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5G612ms011357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 23:01:03 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B115B0.4090603@errno.com> Date: Wed, 15 Jun 2005 23:01:20 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Hartmeier References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> In-Reply-To: <20050615204232.GX8526@insomnia.benzedrine.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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, 16 Jun 2005 06:01:10 -0000 Daniel Hartmeier wrote: > On Mon, Jun 13, 2005 at 09:23:50PM +0000, Marcel Moolenaar wrote: > > >>Synopsis: Unaligned Reference with pf on 5.4/IA64 >> >>Responsible-Changed-From-To: freebsd-net->freebsd-pf >>Responsible-Changed-By: marcel >>Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005 >>Responsible-Changed-Why: >>Move to a more pf-focussed responsible party. >> >>http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 > > > If I understand the problem correctly, there is an underlying > network-generic question I'd like to ask here. > > When a function in the kernel gets passed a struct ip pointer, can it > assume that the struct ip object pointed to is properly aligned? Or > should it assume that this is not the case, and extract members more > carefully? > > We can fix the access in pf of course, but if other functions rightfully > count on struct ip objects being properly aligned, this might simply > crash outside of pf, too. > > In short, is the problem that bridge doesn't properly align the struct > ip object (which I can try to fix, too), or that pf assumes that such > objects should be aligned? > > On OpenBSD's 64-bit architectures with varying alignment rules, this has > never occured, I think because the struct ip objects (and, hence, their > ip_src/dst members) are kept aligned. > > If I'm way off, and proper alignment of struct ip objects does not > guarantee proper alignment of the ip_src/dst members as 32-bit > unsigneds, please explain. If ia64 is different from other 64-bit > architectures (of which I only know amd64, sparc64 and alpha), please > explain what alignment rules there are for u_int32_t. Much code assumes ip packets are aligned. Sam From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 12:01:54 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 98E3216A437; Thu, 16 Jun 2005 12:01:54 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C6E343D55; Thu, 16 Jun 2005 12:01:53 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5GC1eo4019380; Thu, 16 Jun 2005 22:01:40 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5GC1aA2030497; Thu, 16 Jun 2005 22:01:37 +1000 Date: Thu, 16 Jun 2005 22:02:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Marcel Moolenaar In-Reply-To: Message-ID: <20050616210944.Y833@delplex.bde.org> References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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, 16 Jun 2005 12:01:54 -0000 On Wed, 15 Jun 2005, Marcel Moolenaar wrote: > On Jun 15, 2005, at 1:42 PM, Daniel Hartmeier wrote: >> If I understand the problem correctly, there is an underlying >> network-generic question I'd like to ask here. >> >> When a function in the kernel gets passed a struct ip pointer, can it >> assume that the struct ip object pointed to is properly aligned? Or >> should it assume that this is not the case, and extract members more >> carefully? Yes. A struct ip pointer points, by definition, to a struct ip. All structs are sufficiently aligned in C. > That entirely depends. If a struct ip pointer is constructed without > any form of casting, then one can assume that alignment is guaranteed. > The compiler guarantees to do so, except of course in this case: > the structure is defined as a packed structure. We, as the developers, > have told the compiler to *NOT* guarantee alignment of fields. We're > on our own and we miserably fail being on our own. This case is not really different. Packed structs are, by definition, still structs. All structs are sufficiently aligned in C. "Sufficiently" just means that valid accesses to the struct are sufficiently aligned. For arches with strict alignment requirements like ia64, this means laboriously accessing the struct 1 byte at a time and combining the results. So declaring a struct as packed when it doesn't need to be, is mostly just a pessimization. For struct ip, this pessimization was implemented in rev.1.20 of netinet/ip.h. >> We can fix the access in pf of course, but if other functions rightfully >> count on struct ip objects being properly aligned, this might simply >> crash outside of pf, too. I suppose the problems are that: - pf makes invalid accesses like: void foo(struct in_addr *iap); /* use *iap */ struct ip *ip; foo(&ip->ip_src); - the compiler doesn't diagnose the invalid access in the above. Since *ip is packed, ip->ip_src in it isn't actually a struct in_addr -- it is a packed struct in_addr, so it might not have sufficent alignment to be a struct in_addr. > True. But since struct ip is defined as packed, nobody can assume proper > alignment of multi-byte fields and all code needs to be fixed if such > assumptions are being made. This is a reason why packed structs should never be used. Programming is too hard if &ip->ip_src doesn't work, and even if it did work it would export the pessimal packing. >> If ia64 is different from other 64-bit >> architectures (of which I only know amd64, sparc64 and alpha), please >> explain what alignment rules there are for u_int32_t. > > ia64 is not different in this respect. That's why the bug is not > specific to ia64. Note that amd64 may not be a perfect reference > in this case because it's too much like i386, which does unaligned > loads and stores. ia64 is different in that it actually traps misaligned accesses. i486+'s can trap all misaligned accesses too, at least in user mode, but alignment checking is rarely turned on and gcc has never supported it. E.g., gcc has always copying structs like "struct foo { short x[16]; };". This struct is only guaranteed to be 16-bit aligned, but gcc now uses only 32-bit accesses to copy it. So it is an ABI requirement in practice at least for alignment checking to not be enabled. gcc also exploits this to not generate different code to access struct ip's when struct ip is bogusly packed. Bruce From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 12:39:49 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 E10BF16A41C; Thu, 16 Jun 2005 12:39:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75DB743D5E; Thu, 16 Jun 2005 12:39:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5GCdfYm026994; Thu, 16 Jun 2005 22:39:41 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5GCdcae010499; Thu, 16 Jun 2005 22:39:39 +1000 Date: Thu, 16 Jun 2005 22:40:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Daniel Hartmeier In-Reply-To: <20050615223450.GY8526@insomnia.benzedrine.cx> Message-ID: <20050616220249.N833@delplex.bde.org> References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> <20050615223450.GY8526@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org, Marcel Moolenaar Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 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, 16 Jun 2005 12:39:49 -0000 On Thu, 16 Jun 2005, Daniel Hartmeier wrote: > 'packed', as I understand it, prohibits the compiler from inserting any > padding anywhere in the struct. That is, it guarantees that the total > size of a struct object equals the sum of the sizes of its members. It also requires the complier to generate specially pessimized code to access the struct. Otherwise even direct references like ip->ip_src might trap. > As a consequence, individual members can't be aligned properly if that > would require padding in front of them. The compiler can (and must?) > still align the first member, i.e. the beginning of the struct object, > though, no? No. This wouldn't be very useful, and wouldn't work right for things like arrays of packed structs -- the individual structs would have to be padded at the end since there can be no space between array elements, but packed structs are supposed to be unpadded at the end too. You can see that there is no alignment requirement for packed structs as a whole by looking at assembler output -- for a packed struct ip there is a .comm..,1 where the 1 says 1-byte alignment. > The IP header and the struct that represents it are defined very ^^^ were ... > carefully. It's no coincidence that ip_src/dst are placed where they > are: > > struct ip { > u_int ip_hl:4, /* header length */ > ip_v:4; /* version */ > u_char ip_tos; /* type of service */ > u_short ip_len; /* total length */ > u_short ip_id; /* identification */ > u_short ip_off; /* fragment offset field */ > u_char ip_ttl; /* time to live */ > u_char ip_p; /* protocol */ > u_short ip_sum; /* checksum */ > struct in_addr ip_src,ip_dst; /* source and dest address */ > } __packed; ^^^^^^^^^^ ... before this bug > > This guarantees that > > struct ip h; > &h.ip_src == (char *)&h + 12 > &h.ip_dst == (char *)&h + 16 > > i.e. they are both on 32-bit aligned if h itself is 32-bit aligned. > > If you look at any example in sys/netinet where struct ip members are > accessed, you see direct access to both u_short and uint32_t members. > Nowhere does anyone memcpy, bcopy or char-wise-copy ip_src/dst, for > instance. Except the compiler does this. > The issue also involves how the IP header is aligned within mbufs. > Functions usually get passed an mbuf pointer, and do > > struct mbuf *m; > struct ip *ip = mtod(m, struct ip *); > > and then happily access ip_src/dst without further alignment checks. mtod() just does a dubious cast. It depends on the data already being sufficiently aligned. For non-bogusly-packed IP headers this means 32-bit alignment (for the in_addr's). It's not clear where the misaligned headers come from. At least with gcc-3.3.3, I couldn't get a non-32-bit-aligned struct ip as a local variable by putting a char variable or char array before or after it. gcc has obscure rules for reordering local variables to pack them better, and this helps here. Padded structs withing (even unpadded) structs can easily be misaligned depending on what is before them, but struct ip's within structs seem to be rare. The one in ip_icmp.h is OK. Bruce From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 13:18:05 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 A87F616A41C for ; Thu, 16 Jun 2005 13:18:05 +0000 (GMT) (envelope-from flo@kasimir.com) Received: from h9166.serverkompetenz.net (zivodo.net [81.169.188.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 638A343D1F for ; Thu, 16 Jun 2005 13:18:05 +0000 (GMT) (envelope-from flo@kasimir.com) Received: from localhost (localhost [127.0.0.1]) by h9166.serverkompetenz.net (Postfix) with ESMTP id AA5DC2B000E for ; Thu, 16 Jun 2005 15:18:03 +0200 (CEST) Received: from h9166.serverkompetenz.net ([127.0.0.1]) by localhost (h9166 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25161-05 for ; Thu, 16 Jun 2005 15:18:03 +0200 (CEST) Received: by h9166.serverkompetenz.net (Postfix, from userid 1001) id 586212B0017; Thu, 16 Jun 2005 15:18:03 +0200 (CEST) Received: from [127.0.0.1] (unknown [82.113.100.4]) by h9166.serverkompetenz.net (Postfix) with ESMTP id 062702B000E for ; Thu, 16 Jun 2005 15:17:59 +0200 (CEST) Message-ID: <42B17C3D.6040907@kasimir.com> Date: Thu, 16 Jun 2005 15:18:53 +0200 From: "Florian C. Smeets" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on h9166.serverkompetenz.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Virus-Scanned: by amavisd-new-20030616-p10 at zivodo.info Subject: kernel: ticket: 2 != [1]3 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, 16 Jun 2005 13:18:05 -0000 Hi, i'm on a DSL Line where my ISP forces a disconnect every 24 hours, every time my connection is disconnected and i get a new ip i get these messages: Jun 8 14:23:35 soekris kernel: ticket: 2 != [1]3 Jun 8 14:23:43 soekris kernel: ticket: 4 != [1]6 Jun 9 14:23:39 soekris kernel: ticket: 8 != [1]9 Jun 10 14:23:46 soekris kernel: ticket: 12 != [1]13 Jun 11 14:23:53 soekris kernel: ticket: 16 != [1]17 Jun 12 14:24:01 soekris kernel: ticket: 20 != [1]21 Jun 13 14:24:08 soekris kernel: ticket: 24 != [1]25 Jun 14 14:24:26 soekris kernel: ticket: 38 != [1]40 Jun 15 14:24:23 soekris kernel: ticket: 42 != [1]44 Jun 16 14:24:41 soekris kernel: ticket: 46 != [1]48 Is this something i should worry about ? I have not experienced any problems though. I use this in my pf.conf for the external interface (the one which gets the new ip): ext_if="tun0" internal_net="{ 172.30.1.0/24, 172.30.2.0/24 }" nat on $ext_if from $internal_net to any -> ($ext_if) In case it is needed the complete ruleset is available here: http://flds.dyndns.org/pf.conf I think this started when the OpenBSD 3.7 pf was commited. Cheers, Florian From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 15:14:28 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 85F5E16A41C; Thu, 16 Jun 2005 15:14:28 +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 D336F43D4C; Thu, 16 Jun 2005 15:14:27 +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 j5GFEPEh042224; Thu, 16 Jun 2005 19:14:25 +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 j5GFEPEm042223; Thu, 16 Jun 2005 19:14:25 +0400 (MSD) (envelope-from yar) Date: Thu, 16 Jun 2005 19:14:24 +0400 From: Yar Tikhiy To: Josh Kayse Message-ID: <20050616151424.GA40160@comp.chem.msu.su> References: <7c8f2792050610090049064e11@mail.gmail.com> <7c8f279205061116021f55e8da@mail.gmail.com> <7c8f279205061307103b1782f4@mail.gmail.com> <20050613153550.GA54388@comp.chem.msu.su> <7c8f2792050613090040c924c3@mail.gmail.com> <20050615143919.GE8060@cell.sick.ru> <7c8f27920506151132670c035@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c8f27920506151132670c035@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, Gleb Smirnoff , freebsd-pf@freebsd.org Subject: Re: Carp Suppression 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, 16 Jun 2005 15:14:28 -0000 On Wed, Jun 15, 2005 at 02:32:19PM -0400, Josh Kayse wrote: > On 6/15/05, Gleb Smirnoff wrote: > > > AFAIU, you use PLIP line as some flag that triggers suppression. If > > slave "sees" master via PLIP, it keeps itself in slave mode. May be > > I don't understand you right. > > > > Although the idea is not officially supported, it is interesting. Can you > > please draw your setup, since I don't understand it clearly? > > > __________ > em0 | |em1 > ------------| FW1 |----------- > |_________| > xl0(carp0)| | plip0(carp1) > ___|___|___ > em0 | | em1 > -----------| FW2 |---------- > |__________| > > > Bridging is done through em0/em1 which are both monitored by ifstated > for link state only (backported patch from HEAD). > > When one of the bridging ports is disconnected, ifstaded changes the > advskew of carp0 and carp1 to 254 so that the carp interfaces > failover. > > When ifstated see the carp interfaces as BOTH master, the slave > firewall takes over bridging. > > This gives us redundant firewalls, with redundant heartbeat connections. In fact, not all network failures lead to detectable link loss. I can imagine a situation when the switch port FW1-em0 is connected to just hangs and so FW1 is unable to notice the event. If CARP ran on the em0 side of FW1 and FW2, they would notice such an event though due to CARP packets unable to flow between FW1-em0 and FW2-em0 any longer. The advantage of CARP used customarily and not on a separate "heartbeat" interface is that it provides active detection of failures on the very network that should be made fail-safe. -- Yar From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 18:25:15 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 F17A716A41C; Thu, 16 Jun 2005 18:25:14 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id A60E243D48; Thu, 16 Jun 2005 18:25:14 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (iijogh@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j5GIP4gb066863; Thu, 16 Jun 2005 11:25:04 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j5GIP2Hx066862; Thu, 16 Jun 2005 11:25:02 -0700 (PDT) (envelope-from jmg) Date: Thu, 16 Jun 2005 11:25:02 -0700 From: John-Mark Gurney To: Daniel Hartmeier Message-ID: <20050616182502.GL742@funkthat.com> Mail-Followup-To: Daniel Hartmeier , Marcel Moolenaar , freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> <20050615223450.GY8526@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615223450.GY8526@insomnia.benzedrine.cx> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, Marcel Moolenaar , freebsd-pf@freebsd.org, Marcel Moolenaar Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney 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, 16 Jun 2005 18:25:15 -0000 Daniel Hartmeier wrote this message on Thu, Jun 16, 2005 at 00:34 +0200: > So, are you really sure we should do differently in pf, instead of > looking for a bridge problem, where bridge constructs an mbuf with the > IP header not properly aligned? > > I.e. if the IP header is properly aligned within the mbuf (on 32-bit > boundaries, I presume), wouldn't ip_src/dst have to be properly aligned > as well, even though __packed is used, because the layout of struct ip > is chosen like that? This is a more general problem.. All of our ethernet drivers that run on aligned platforms have special code to offset by 2 the ethernet packet specificly so that struct ip and friends are properly aligned.. This is because the ethernet header is 14 bytes long, and if the data was left unchanged, the struct ip would start at x mod 4 = 2... of course, this is stupid, and each component that requires alignment when accepting a packet from another interface (i.e. pf taking in an mbuf from another system like bridge, or even the if stack) should use the m_copyup function that I committed a bit back.. This will give you correct alignment, and at the same time, make it continue to work if/when we finally decide to not have the ethernet drivers align packets... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 19:10:52 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 643BD16A41C for ; Thu, 16 Jun 2005 19:10:52 +0000 (GMT) (envelope-from ah@crypta.net) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E02643D49 for ; Thu, 16 Jun 2005 19:10:51 +0000 (GMT) (envelope-from ah@crypta.net) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id 422C8ECD419; Thu, 16 Jun 2005 21:10:48 +0200 (CEST) Date: Thu, 16 Jun 2005 21:10:48 +0200 From: Andy Hilker To: freebsd-pf@freebsd.org Message-ID: <20050616191047.GA98176@mail.crypta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker Subject: synproxy and states 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, 16 Jun 2005 19:10:52 -0000 Hi, i have a problem with using synproxy (FreeBSD 5.4 Release p2). # Client with x.x.x.x do not get an answer with synproxy, keep state works pass in log quick proto tcp from x.x.x.x to port { 80,443 } flags S/SA synproxy state # log said rule 101/0(match): block in on em1: IP webserver.80 > x.x.x.x.3040: S 3694411781:3694411781(0) ack 1964249403 win 65535 # but if allow this explicit, client get an answer pass in log quick on em1 proto tcp from any to any modulate state What is the recommended way to work with synproxy? I do not want such rule like the last one. I thought that state entries are the same with synproxy like keep state. Topology: ---internet------ fxp0-(box with pf)-em1 --- (webserver) If it helps I can provide full rule set or any other needed information. bye, Andy From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 19:38: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 DAB8716A41C for ; Thu, 16 Jun 2005 19:38:53 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 916CD43D53 for ; Thu, 16 Jun 2005 19:38:53 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so634912wri for ; Thu, 16 Jun 2005 12:38:52 -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=i2oINX8VEFxJp3DUZcqP/MY+ZLD4aFnyIjkIyCFcHpirJ499nPAQ/+zKnBTzOwwFylWCQRbJ5vP/AnWqLzuC8mBXoQUDJFHYtI03GJuLrhdhaSMIWBPlLKQdN8KA5/A4j4GoYOgsHWOrGoDsvZCsUD+PmWVYh0+kNnGFgWeufJQ= Received: by 10.54.25.75 with SMTP id 75mr675876wry; Thu, 16 Jun 2005 12:38:52 -0700 (PDT) Received: by 10.54.39.65 with HTTP; Thu, 16 Jun 2005 12:38:52 -0700 (PDT) Message-ID: <8eea0408050616123835594e12@mail.gmail.com> Date: Thu, 16 Jun 2005 12:38:52 -0700 From: Jon Simola To: Andy Hilker In-Reply-To: <20050616191047.GA98176@mail.crypta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050616191047.GA98176@mail.crypta.net> Cc: freebsd-pf@freebsd.org Subject: Re: synproxy and states X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jon@abccomm.com 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, 16 Jun 2005 19:38:54 -0000 On 6/16/05, Andy Hilker wrote: > pass in log quick proto tcp from x.x.x.x to po= rt { 80,443 } flags S/SA synproxy state I've used this a couple times to stop infected clients without totally locking them out: pass in quick on vlan130 proto tcp from x.x.x.174 to any synproxy state > ---internet------ fxp0-(box with pf)-em1 --- (webserver) If that's a bridge config, synproxy will not work. It's not possible to tell from the documentation you provided. --=20 Jon Simola Systems Administrator ABC Communications From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 20:10: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 701C816A41C; Thu, 16 Jun 2005 20:10:55 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from exch01smtp11.hdi.tvcabo (smtp3.netcabo.pt [212.113.174.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D5A43D1F; Thu, 16 Jun 2005 20:10:54 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from VS2.hdi.tvcabo ([192.168.16.49] RDNS failed) by exch01smtp11.hdi.tvcabo with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 21:10:52 +0100 Received: from mail pickup service by VS2.hdi.tvcabo with Microsoft SMTPSVC; Thu, 16 Jun 2005 21:04:58 +0100 Received: from exch01smtp08.hdi.tvcabo ([10.137.34.8]) by VS2.hdi.tvcabo with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Jun 2005 13:42:25 +0100 Received: from mail pickup service by exch01smtp08.hdi.tvcabo with Microsoft SMTPSVC; Thu, 16 Jun 2005 13:42:24 +0100 Received: from mail pickup service by exch01smtp08.hdi.tvcabo with Microsoft SMTPSVC; Thu, 16 Jun 2005 13:42:22 +0100 Received: from mx2.freebsd.org ([216.136.204.119]) by exch01smtp08.hdi.tvcabo with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 13:40:18 +0100 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 3F6C5589B8; Thu, 16 Jun 2005 12:40:13 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 47E3C16A438; Thu, 16 Jun 2005 12:40:12 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E10BF16A41C; Thu, 16 Jun 2005 12:39:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75DB743D5E; Thu, 16 Jun 2005 12:39:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5GCdfYm026994; Thu, 16 Jun 2005 22:39:41 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5GCdcae010499; Thu, 16 Jun 2005 22:39:39 +1000 Date: Thu, 16 Jun 2005 22:40:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Daniel Hartmeier In-Reply-To: <20050615223450.GY8526@insomnia.benzedrine.cx> Message-ID: <20050616220249.N833@delplex.bde.org> References: <200506132123.j5DLNove069255@freefall.freebsd.org> <20050615204232.GX8526@insomnia.benzedrine.cx> <20050615223450.GY8526@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-CTCH-ID: _80F6CD19-9DAA-4CF8-AEAC-9CC03F804BEC_ X-CTCH-RefID: 0001.0A090205.42B1723D.000E-A- X-CTCH-Action: Ignore X-CTCH-RetryNextTime: 2005-06-16 12:42:20 X-OriginalArrivalTime: 16 Jun 2005 12:40:19.0203 (UTC) FILETIME=[8DDEF530:01C57270] Cc: freebsd-net@freebsd.org, Marcel Moolenaar , Marcel Moolenaar , freebsd-pf@freebsd.org Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 X-BeenThere: freebsd-pf@freebsd.org 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, 16 Jun 2005 20:10:55 -0000 On Thu, 16 Jun 2005, Daniel Hartmeier wrote: > 'packed', as I understand it, prohibits the compiler from inserting any > padding anywhere in the struct. That is, it guarantees that the total > size of a struct object equals the sum of the sizes of its members. It also requires the complier to generate specially pessimized code to access the struct. Otherwise even direct references like ip->ip_src might trap. > As a consequence, individual members can't be aligned properly if that > would require padding in front of them. The compiler can (and must?) > still align the first member, i.e. the beginning of the struct object, > though, no? No. This wouldn't be very useful, and wouldn't work right for things like arrays of packed structs -- the individual structs would have to be padded at the end since there can be no space between array elements, but packed structs are supposed to be unpadded at the end too. You can see that there is no alignment requirement for packed structs as a whole by looking at assembler output -- for a packed struct ip there is a comm..,1 where the 1 says 1-byte alignment. > The IP header and the struct that represents it are defined very ^^^ were ... > carefully. It's no coincidence that ip_src/dst are placed where they > are: > > struct ip { > u_int ip_hl:4, /* header length */ > ip_v:4; /* version */ > u_char ip_tos; /* type of service */ > u_short ip_len; /* total length */ > u_short ip_id; /* identification */ > u_short ip_off; /* fragment offset field */ > u_char ip_ttl; /* time to live */ > u_char ip_p; /* protocol */ > u_short ip_sum; /* checksum */ > struct in_addr ip_src,ip_dst; /* source and dest address */ > } __packed; ^^^^^^^^^^ ... before this bug > > This guarantees that > > struct ip h; > &h.ip_src == (char *)&h + 12 > &h.ip_dst == (char *)&h + 16 > > i.e. they are both on 32-bit aligned if h itself is 32-bit aligned. > > If you look at any example in sys/netinet where struct ip members are > accessed, you see direct access to both u_short and uint32_t members. > Nowhere does anyone memcpy, bcopy or char-wise-copy ip_src/dst, for > instance. Except the compiler does this. > The issue also involves how the IP header is aligned within mbufs. > Functions usually get passed an mbuf pointer, and do > > struct mbuf *m; > struct ip *ip = mtod(m, struct ip *); > > and then happily access ip_src/dst without further alignment checks. mtod() just does a dubious cast. It depends on the data already being sufficiently aligned. For non-bogusly-packed IP headers this means 32-bit alignment (for the in_addr's). It's not clear where the misaligned headers come from. At least with gcc-3.3.3, I couldn't get a non-32-bit-aligned struct ip as a local variable by putting a char variable or char array before or after it. gcc has obscure rules for reordering local variables to pack them better, and this helps here. Padded structs withing (even unpadded) structs can easily be misaligned depending on what is before them, but struct ip's within structs seem to be rare. The one in ip_icmp.h is OK. Bruce _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Thu Jun 16 20:14:52 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 014BD16A41C for ; Thu, 16 Jun 2005 20:14:52 +0000 (GMT) (envelope-from ah@crypta.net) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B87FE43D53 for ; Thu, 16 Jun 2005 20:14:51 +0000 (GMT) (envelope-from ah@crypta.net) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id 04B3AECD414; Thu, 16 Jun 2005 22:14:49 +0200 (CEST) Date: Thu, 16 Jun 2005 22:14:48 +0200 From: Andy Hilker To: jon@abccomm.com Message-ID: <20050616201448.GB1149@mail.crypta.net> References: <20050616191047.GA98176@mail.crypta.net> <8eea0408050616123835594e12@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8eea0408050616123835594e12@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker Cc: freebsd-pf@freebsd.org Subject: Re: synproxy and states 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, 16 Jun 2005 20:14:52 -0000 Hi, You (Jon Simola) wrote: > If that's a bridge config, synproxy will not work. It's not possible > to tell from the documentation you provided. No, it is the pf box is acting as gateway. But the reply packet from webserver is dropped at the dmz interface. If I allow this reply explicitly, synproxy works. Obviously I have a problem with state table entries. bye, Andy