From owner-freebsd-net@FreeBSD.ORG Sun Dec 12 23:25:30 2004 Return-Path: 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 DE09216A4CE for ; Sun, 12 Dec 2004 23:25:30 +0000 (GMT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A96E743D4C for ; Sun, 12 Dec 2004 23:25:30 +0000 (GMT) (envelope-from pheerboth@apple.com) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iBCNXVIJ020609 for ; Sun, 12 Dec 2004 15:33:31 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com ; Sun, 12 Dec 2004 15:26:44 -0800 Received: from [17.219.205.121] ([17.219.205.121]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id iBCNPCcj004992; Sun, 12 Dec 2004 15:25:13 -0800 (PST) In-Reply-To: <41BB40B7.5000907@mac.com> References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> <41BB40B7.5000907@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B251E0B-4C95-11D9-A057-000393CFACB0@apple.com> Content-Transfer-Encoding: 7bit From: Peter Heerboth Date: Sun, 12 Dec 2004 15:25:27 -0800 To: Chuck Swiger X-Mailer: Apple Mail (2.619) cc: Andrea Campi cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2004 23:25:31 -0000 I'm not a zeroconf expert per se, but I would love to see FreeBSD have a great zeroconf implementation. Here are some things to think about. > > If your first implementation happens to leave the interface with a > 169.254 IP address, it's doing something it shouldn't, however that is > likely to be mostly harmless until you or someone has a chance to > improve the implementation. If a device does keep its link local address once it obtains a lease from a DHCP server or the user manually enters an address, it is important that it stops responding to A record queries with its 169.254/16 address. Depending upon the IP implementations of the other devices on the network, the freebsd box may appear unreachable. Imagine this situation: My freebsd box initially has a link local address, it later obtains a DHCP address on 10.0.1/24. Now other devices with 10.0.1/24 addresses on the network need to use services advertised on my freebsd box. If the multicast DNS daemon on the Freebsd box responds to A record queries for its host name with the 169.254/16 address, subsequent TCP connection attempts from a device without a link local address may quite possibly fail. I believe most mDNS implementations have interfaces to the multicast DNS daemon that allow the programmer to build a list of IP addresses resolved for a hostname by interface, but I'm not sure how many people are this thorough. Also, how is Freebsd going to handle IPv4 link local addresses on multi-homed hosts? Does FreeBSD have a notion of a "primary" interface like Mac OS X? If FreeBSD assigns v4 link-local address to all its interfaces, then the link-local address for each device on each network to which my FreeBSD device is attached must be unique across all networks, or the routing implications are obvious. From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 05:18:19 2004 Return-Path: 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 E735B16A4CE for ; Mon, 13 Dec 2004 05:18:19 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id A94E443D53 for ; Mon, 13 Dec 2004 05:18:19 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id D996E651F7; Mon, 13 Dec 2004 05:18:18 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 88874-04-2; Mon, 13 Dec 2004 05:18:18 +0000 (GMT) Received: from empiric.dek.spc.org (adsl-66-127-57-127.dsl.snfc21.pacbell.net [66.127.57.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 22AEF651EE; Mon, 13 Dec 2004 05:18:18 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id EDA5E6334; Sun, 12 Dec 2004 21:18:16 -0800 (PST) Date: Sun, 12 Dec 2004 21:18:16 -0800 From: Bruce M Simpson To: Andrea Campi Message-ID: <20041213051816.GC689@empiric.icir.org> References: <20041211090235.GD11190@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041211090235.GD11190@webcom.it> cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 05:18:20 -0000 On Sat, Dec 11, 2004 at 10:02:35AM +0100, Andrea Campi wrote: > just a quick note to let concerned parties know I have started > working on the howl port. As mentioned on the dingo page, the goal > is to have a fully working BSD-licensed implementation of zeroconf. Yes please! Much of what ended up as 'Dingo' has been on my list for the last year or so. I am currently wrapping things up in Berkeley for the holidays. I will be back in the UK for a month, so I should have some free time to catch up on FreeBSD things. Once again, thanks for looking at this! I will try to help when/where I can. BMS From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 09:06:13 2004 Return-Path: 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 91EEA16A4CE for ; Mon, 13 Dec 2004 09:06:13 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53E0543D48 for ; Mon, 13 Dec 2004 09:06:13 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id E56E0A6; Mon, 13 Dec 2004 10:06:09 +0100 (CET) Date: Mon, 13 Dec 2004 10:06:09 +0100 From: Andrea Campi To: Peter Heerboth Message-ID: <20041213090609.GA30379@webcom.it> References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> <41BB40B7.5000907@mac.com> <1B251E0B-4C95-11D9-A057-000393CFACB0@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B251E0B-4C95-11D9-A057-000393CFACB0@apple.com> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 09:06:13 -0000 On Sun, Dec 12, 2004 at 03:25:27PM -0800, Peter Heerboth wrote: > I'm not a zeroconf expert per se, but I would love to see FreeBSD have > a great zeroconf implementation. Here are some things to think about. > > > > >If your first implementation happens to leave the interface with a > >169.254 IP address, it's doing something it shouldn't, however that is > >likely to be mostly harmless until you or someone has a chance to > >improve the implementation. > > If a device does keep its link local address once it obtains a lease > from a DHCP server or the user manually enters an address, it is > important that it stops responding to A record queries with its > 169.254/16 address. Depending upon the IP implementations of the other Sure, I'll make sure this is going to work fine. But I need some time before I can really work on mDNS ;-) > Also, how is Freebsd going to handle IPv4 link local addresses on > multi-homed hosts? Does FreeBSD have a notion of a "primary" interface > like Mac OS X? If FreeBSD assigns v4 link-local address to all its > interfaces, then the link-local address for each device on each network > to which my FreeBSD device is attached must be unique across all > networks, or the routing implications are obvious. I'd like to live complications such as this for a later stage. I'd say if you have a multihomed machine you better know how to configure it; the primary target for my work are laptops and other clients. That is not to say I don't care; rather, I need to limit how much I chew at a time. For now I only work on one interface. Bye, Andrea -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 10:08:32 2004 Return-Path: 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 A7FFB16A4CE for ; Mon, 13 Dec 2004 10:08:32 +0000 (GMT) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0310F43D68 for ; Mon, 13 Dec 2004 10:08:32 +0000 (GMT) (envelope-from keiichi@iijlab.net) Received: OMGO id iBDA8TQL029014; Mon, 13 Dec 2004 19:08:29 +0900 (JST) Received: OTM-MIX0 id iBDA8SfN002308; Mon, 13 Dec 2004 19:08:28 +0900 (JST) Received: JC-SMTP from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) id iBDA8S9c023444; Mon, 13 Dec 2004 19:08:28 +0900 (JST) Date: Mon, 13 Dec 2004 19:07:26 +0900 (JST) Message-Id: <20041213.190726.38982816.keiichi@iijlab.net> To: liettneff@bk.ru From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <196116794593.20041210071459@bk.ru> References: <196116794593.20041210071459@bk.ru> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: KAME mip6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 10:08:32 -0000 Hi, From: Michael Lednev Subject: KAME mip6 Date: Fri, 10 Dec 2004 07:14:59 +0300 > is there any chance, that kame mip6 stack will work with freebsd-5.3 > out of the box soon? The KAME project is now working on Mobile IPv6 support for FreeBSD-5.3+KAME. The latest KAME snap shot of FreeBSD5.3+KAME already have MIP6 code. However, the code is not the same with the old KAME/MIP6. We are now rewriting the code as a user space program. (The old KAME/MIP6 is implemented in a kernel space) Unfortunately, the quality is not very good compared to the old one, but, we will try to improve the new code continuously. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 10:26:40 2004 Return-Path: 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 DD6A116A4CE for ; Mon, 13 Dec 2004 10:26:40 +0000 (GMT) Received: from phoenix.severttk.ru (phoenix.severttk.ru [80.92.0.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88B8143D5C for ; Mon, 13 Dec 2004 10:26:40 +0000 (GMT) (envelope-from liettneff@bk.ru) Received: from phoenix.severttk.ru (localhost [127.0.0.1]) by phoenix.severttk.ru (Postfix) with SMTP id C3839A919 for ; Mon, 13 Dec 2004 13:26:39 +0300 (MSK) Received: from gate-sttk.km.vibrators.ru (vlan101-sv-yar03ra.severttk.ru [80.92.2.130]) by phoenix.severttk.ru (Postfix) with ESMTP id 392EAA95F for ; Mon, 13 Dec 2004 13:26:30 +0300 (MSK) Received: from [192.168.1.90] (reaper-home [192.168.1.90] (may be forged)) iBDAQQYK049165; Mon, 13 Dec 2004 13:26:28 +0300 (MSK) (envelope-from liettneff@bk.ru) Date: Mon, 13 Dec 2004 13:25:20 +0300 From: Michael Lednev X-Mailer: The Bat! (v3.0.1.33) UNREG / CD5BF9353B3B7091 Organization: none X-Priority: 3 (Normal) Message-ID: <1665849094.20041213132520@bk.ru> To: Keiichi SHIMA In-Reply-To: <20041213.190726.38982816.keiichi@iijlab.net> References: <196116794593.20041210071459@bk.ru> <20041213.190726.38982816.keiichi@iijlab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re[2]: KAME mip6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: liettneff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 10:26:41 -0000 Hello, B. On 13 декабря 2004 г., 13:07:26 you wrote: Bkin> The latest KAME snap shot of FreeBSD5.3+KAME already have MIP6 code. Bkin> However, the code is not the same with the old KAME/MIP6. We are now Bkin> rewriting the code as a user space program. (The old KAME/MIP6 is Bkin> implemented in a kernel space) you mean that you how-to from http://www.kame.net/newsletter/20031007/ will not work with kame+freebsd5? Bkin> Unfortunately, the quality is not very good compared to the old one, Bkin> but, we will try to improve the new code continuously. i tried snap from 20041122 and got compilation error described in http://www.kame.net/dev/query-pr.cgi?pr=808 have anything changed since? -- Regards, Michael mailto:liettneff@bk.ru From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 10:29:30 2004 Return-Path: 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 3184216A4CE; Mon, 13 Dec 2004 10:29:30 +0000 (GMT) Received: from poison2.syncrontech.com (adsl-nat.syncrontech.com [213.28.98.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 662A343D5E; Mon, 13 Dec 2004 10:29:28 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57])iBDATKvg074446; Mon, 13 Dec 2004 12:29:21 +0200 (EET) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.syncrontech.com [62.71.8.37]) iBDATEoD045231; Mon, 13 Dec 2004 12:29:15 +0200 (EET) (envelope-from ari@suutari.iki.fi) Message-ID: <017001c4e0fe$99ce36c0$2508473e@sad.syncrontech.com> From: "Ari Suutari" To: "Andre Oppermann" References: <20041129100949.GA19560@bps.jodocus.org><41AAF696.6ED81FBF@freebsd.org><41AB3A74.8C05601D@freebsd.org><41AB65B2.A18534BF@freebsd.org><41B85729.40F00890@freebsd.org> <08f001c4de83$dfbb1b80$2508473e@sad.syncrontech.com> <41B98307.50D01EDB@freebsd.org> Date: Mon, 13 Dec 2004 12:29:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: "Bjoern A. Zeeb" cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order foroutgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 10:29:30 -0000 Hi, > > All I intend to provide is a way to specify whether you want IPSEC before > or after pfil_hooks. By default it will be as it is today and work > exactly > the same. OK, this sounds like a good step. Maybe the next step could be third choice like 'both before and after' for us who are perhaps over-concerned about security ? Ari S. From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 10:38:14 2004 Return-Path: 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 DB39816A4CE for ; Mon, 13 Dec 2004 10:38:14 +0000 (GMT) Received: from able.com.ua (able.com.ua [80.91.162.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4302E43D4C for ; Mon, 13 Dec 2004 10:38:14 +0000 (GMT) (envelope-from don_oles@able.com.ua) Received: from localhost (localhost [127.0.0.1]) by able.com.ua (Postfix) with SMTP id AB08B44AC3 for ; Mon, 13 Dec 2004 12:38:06 +0200 (EET) Received: from ohnatkevych.kiev.ua.alfabank (unknown [80.91.172.226]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by able.com.ua (Postfix) with ESMTP id 8F11544ABB for ; Mon, 13 Dec 2004 12:38:05 +0200 (EET) Date: Mon, 13 Dec 2004 12:38:25 +0200 From: Oles Hnatkevych X-Mailer: The Bat! (v1.60) X-Priority: 3 (Normal) Message-ID: <884019296.20041213123825@able.com.ua> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: TCP ECN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Oles Hnatkevych List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 10:38:15 -0000 Hello dear All. I have a very strange FreeBSD box. It was 4.6, now it runs currently 4.11 - prerelease, cvsupped yesterday, on sunday. However the problem persists. The problem is that TCP connections to this BOX with SYN+ENC bits can not be established. There's another Linux box, that can not send mail to FreeBSD box. tcpdump shows the following: 12:12:21.960831 212.82.218.243.4349 > 212.109.60.114.25: SE 855427262:855427262(0) win 5840 (DF) 12:12:24.960902 212.82.218.243.4349 > 212.109.60.114.25: SE 855427262:855427262(0) win 5840 (DF) 12:12:30.957610 212.82.218.243.4349 > 212.109.60.114.25: SE 855427262:855427262(0) win 5840 (DF) 12:12:42.957429 212.82.218.243.4349 > 212.109.60.114.25: SE 855427262:855427262(0) win 5840 (DF) 12:13:06.955415 212.82.218.243.4349 > 212.109.60.114.25: SE 855427262:855427262(0) win 5840 (DF) ... and timeout. Yet again, when remote administator uses telnet to connect to port 25, everything goes as needed. 12:13:13.787333 212.82.218.243.50686 > 212.109.60.114.25: S 1250984054:1250984054(0) win 65535 (DF) 12:13:13.823640 212.109.60.114.25 > 212.82.218.243.50686: S 1362670573:1362670573(0) ack 1250984055 win 57344 (DF) 12:13:16.775253 212.82.218.243.50686 > 212.109.60.114.25: S 1250984054:1250984054(0) win 65535 (DF) 12:13:16.813864 212.109.60.114.25 > 212.82.218.243.50686: S 1362670573:1362670573(0) ack 1250984055 win 57344 (DF) I have another FreeBSD boxes, they work properly in both cases, so this is really an exceptional OS/kernel installation. I hardly believe it is IPFW problem: the rule is allow tcp from any to 212.109.60.114 25 in recv ${oif} What the problem can be????? -- Oles mailto:don_oles@able.com.ua From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 11:02:17 2004 Return-Path: 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 E7DA316A4CE for ; Mon, 13 Dec 2004 11:02:17 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C642D43D2D for ; Mon, 13 Dec 2004 11:02:17 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iBDB2Heq075161 for ; Mon, 13 Dec 2004 11:02:17 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iBDB2Hfd075153 for freebsd-net@freebsd.org; Mon, 13 Dec 2004 11:02:17 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Dec 2004 11:02:17 GMT Message-Id: <200412131102.iBDB2Hfd075153@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 11:02:18 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 11:37:28 2004 Return-Path: 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 4169816A4CE for ; Mon, 13 Dec 2004 11:37:28 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78E1843D1F for ; Mon, 13 Dec 2004 11:37:27 +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 iBDBbOag044345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Dec 2004 14:37:25 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBDBbNxd032808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2004 14:37:24 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBDBbD6n032799; Mon, 13 Dec 2004 14:37:13 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 13 Dec 2004 14:37:13 +0300 From: Gleb Smirnoff To: Andrew White Message-ID: <20041213113713.GA32719@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andrew White , freebsd-net@freebsd.org References: <20041208233954.HXJM1456.aamta06-winn.mailhost.ntl.com@HOMEBREW> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041208233954.HXJM1456.aamta06-winn.mailhost.ntl.com@HOMEBREW> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: freebsd-net@freebsd.org Subject: Re: Best layer 2 bridge over IP solution ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 11:37:28 -0000 On Wed, Dec 08, 2004 at 11:43:31PM -0000, Andrew White wrote: A> I'm looking for suggestions to the problem below, any help appreciated !! A> A> I have several offices which use LAT MOP and IPX. This works over the A> existing WAN as it is a combination of bridging and routing (routed IP ). A> A> I would like to move to a pure IP network, but need to transport these A> protocols until we can remove them entirely from the network. A> A> Is Vtun and netgraph the way to go ? Or is there a simple more stable/proven A> method of achiving this ? You should try ng_bridge using ng_ksocket or ng_gif as IP transport. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 12:40:56 2004 Return-Path: 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 11C9B16A4CE for ; Mon, 13 Dec 2004 12:40:56 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48CB643D49 for ; Mon, 13 Dec 2004 12:40:55 +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 iBDCeqJs045445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Dec 2004 15:40:53 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBDCeq5T033445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Dec 2004 15:40:52 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBDCeq3G033444 for net@freebsd.org; Mon, 13 Dec 2004 15:40:52 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 13 Dec 2004 15:40:51 +0300 From: Gleb Smirnoff To: net@freebsd.org Message-ID: <20041213124051.GB32719@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean Subject: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 12:40:56 -0000 Dear networkers, I finally managed to pronounce my idea, although I'm afraid of a bikeshed it is going to be burried under. When managing a complex router with many interfaces the output of `ipfw show` (or ipf/pf analog) is getting long and difficult to understand. It is also important that many packets are checked against the rules that can never be applied to them, wasting CPU cycles. A simple example can be local network router with many inner interfaces and with one interface to internet. Actually filtering is desired only in external interface, and there is no need for local traffic to enter packet fitlering routines, e.g. ipfw_chk(). I'd like to implement per-interface pfil hooks, like in Cisco world. Each interface may have 'in' list of rules, 'out' list of rules. Current global ip_{input,output}, filters may coexist with per-interface ones, but can be turned off. Our PFIL interface is quite ready for this, and this is very nice. I'll start with creating/editing alternative chains in ipfw. Then we will need to add possibility to register per-interface hooks in pfil, and add possibility to pass one more optional argument from pfil to the filter itself. I'm glad to see any constructive comments on plan. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 14:49:33 2004 Return-Path: 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 887AB16A4CE for ; Mon, 13 Dec 2004 14:49:33 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B959A43D66 for ; Mon, 13 Dec 2004 14:49:32 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 18455 invoked from network); 13 Dec 2004 14:38:35 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Dec 2004 14:38:35 -0000 Message-ID: <41BDABFB.E64C0A31@freebsd.org> Date: Mon, 13 Dec 2004 15:49:31 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 14:49:33 -0000 Gleb Smirnoff wrote: > > Dear networkers, > > I finally managed to pronounce my idea, although I'm afraid > of a bikeshed it is going to be burried under. > > When managing a complex router with many interfaces the output > of `ipfw show` (or ipf/pf analog) is getting long and difficult to > understand. It is also important that many packets are checked > against the rules that can never be applied to them, wasting CPU > cycles. > > A simple example can be local network router with many inner interfaces > and with one interface to internet. Actually filtering is desired > only in external interface, and there is no need for local traffic > to enter packet fitlering routines, e.g. ipfw_chk(). Then you argument about long ipfw show doesn't hold... ;) > I'd like to implement per-interface pfil hooks, like in Cisco > world. Each interface may have 'in' list of rules, 'out' list > of rules. Current global ip_{input,output}, filters may coexist > with per-interface ones, but can be turned off. Different worlds. I wonder why everything has to "like Cisco". It's not always the most clever way they solve a given problem. > Our PFIL interface is quite ready for this, and this is very nice. I don't see any changes to pfil for this. Pfil already passes the interface in the argument call. This is something for the packet filters (ipfw/pf/ipf) than the pfil API? > I'll start with creating/editing alternative chains in ipfw. Then > we will need to add possibility to register per-interface hooks > in pfil, and add possibility to pass one more optional argument > from pfil to the filter itself. Can you provide example how you think the syntax should be? > I'm glad to see any constructive comments on plan. You have to be careful not to collide with the "in|out|via" inside the rules. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 16:42:44 2004 Return-Path: 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 ACDC016A4CE; Mon, 13 Dec 2004 16:42:44 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0281143D6A; Mon, 13 Dec 2004 16:42:44 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CdtHX-00028S-00; Mon, 13 Dec 2004 17:42:43 +0100 Received: from [217.83.4.147] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CdtHW-0007HW-00; Mon, 13 Dec 2004 17:42:43 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 13 Dec 2004 17:43:26 +0100 User-Agent: KMail/1.7.1 References: <20041213124051.GB32719@cell.sick.ru> In-Reply-To: <20041213124051.GB32719@cell.sick.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1765365.jWeuOKUX53"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412131743.36722.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 16:42:44 -0000 --nextPart1765365.jWeuOKUX53 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 13 December 2004 13:40, Gleb Smirnoff wrote: > Dear networkers, > > I finally managed to pronounce my idea, although I'm afraid > of a bikeshed it is going to be burried under. > > When managing a complex router with many interfaces the output > of `ipfw show` (or ipf/pf analog) is getting long and difficult to > understand. It is also important that many packets are checked > against the rules that can never be applied to them, wasting CPU > cycles. That's an error in the ruleset evaluation code then. Pf automatically jumps= =20 over rules that cannot be matched after one failed. If you have a block of= =20 1000 rules "on xl0" and the first one does not match because of the interfa= ce=20 pf will continue checking with rule #1001. I am not sure if such shortcuts= =20 are possible for ipfw, but I suggest looking into that first. > A simple example can be local network router with many inner interfaces > and with one interface to internet. Actually filtering is desired > only in external interface, and there is no need for local traffic > to enter packet fitlering routines, e.g. ipfw_chk(). This is a very special case and you will only penalize the common case (i.e= =2E=20 looking for a per interface ruleset etc.) > I'd like to implement per-interface pfil hooks, like in Cisco > world. Each interface may have 'in' list of rules, 'out' list > of rules. Current global ip_{input,output}, filters may coexist > with per-interface ones, but can be turned off. If you want this behavior you can - for instance - use pf anchors. For=20 instance like this: anchor INTERN on xl0 anchor EXTERN on tun0 ... see the "ANCHORS AND NAMED RULESETS" section of pf.conf(5). You can even do= =20 things like: anchor SPAM on tun0 proto tcp from any to any port smtp You can then load rulesets into each anchor and pf steps into the ruleset o= nly=20 if the conditions are meat. Of course you can also look at the rules in a=20 given anchor, expand the complete ruleset and have "normal" rules in=20 conjunction with the anchors. That's the way to go - in my humble opinion. > Our PFIL interface is quite ready for this, and this is very nice. > I'll start with creating/editing alternative chains in ipfw. Then > we will need to add possibility to register per-interface hooks > in pfil, and add possibility to pass one more optional argument > from pfil to the filter itself. pfil already passes the interface. So if you really want to do this - I=20 personally don't think it is the right way to go - you can do it *inside* t= he=20 pfil hook without messing the API for everything else. I don't see what is= =20 missing in the current API that will stop you from doing so. > I'm glad to see any constructive comments on plan. Sorry, I don't see the point. If you are going to penalize the common case = for=20 this I will object. =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 --nextPart1765365.jWeuOKUX53 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBvca4XyyEoT62BG0RAioFAJ927rx3XLNGCCk3A24VlYWO2FD5gQCcCDHF 2xJQEHZblyjIbKIY65fuFvQ= =KXPT -----END PGP SIGNATURE----- --nextPart1765365.jWeuOKUX53-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 17:30:57 2004 Return-Path: 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 3113316A4CF for ; Mon, 13 Dec 2004 17:30:57 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C29443D46 for ; Mon, 13 Dec 2004 17:30:56 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 19928 invoked from network); 13 Dec 2004 17:19:57 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Dec 2004 17:19:57 -0000 Message-ID: <41BDD1C7.7060105@freebsd.org> Date: Mon, 13 Dec 2004 18:30:47 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41BA0088.9000107@freebsd.org> In-Reply-To: <41BA0088.9000107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: gallatin@cs.duke.edu Subject: Re: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 17:30:57 -0000 Andre Oppermann wrote: > I've totally rewritten the TCP reassembly function to be a lot more > efficient. In tests with normal bw*delay products and packet loss > plus severe reordering I've measured an improvment of at least 30% in > performance. For high and very high bw*delay product links the > performance improvement is most likely much higher. > > The main property of the new code is O(1) insert for 95% of all normal > reassembly cases. If there is more than one hole the insert time is > O(holes). If a packet arrives that closes a hole the chains to the left > and right are merged. Artificially constructed worst case is O(n). No > malloc's are done for new segments. The old code was O(n) in all cases > plus n*malloc for a describing structure. > > There are some problems with the new code I will fix before committing > it to the tree. One is it can't handle non-writeable mbuf's and the > other is too little leading space in the mbuf (found only on loopback > interface, but there we don't have packet loss). Once these two are > dealed with it is ready to go in. > > Nothing is perfect and this code is only a first significant step over > what we have currently in the tree, especially for transfers over lossy > (wireless) and high speed links with and without packet reordering. > I have the next steps already in the works which will further optimize > (worst case O(windowsize/mclusters) instead of O(n)) and simplify a bit > more again. > > The patch can be found here: > > http://www.nrg4u.com/freebsd/tcp_reass-20041210.patch > > Please test and report good and bad news back. I've got some excellent review feedback from Mike Spengler and he found a off-by-one queue limit tracking error. http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch Please test again. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 17:38:01 2004 Return-Path: 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 9B29616A4CE for ; Mon, 13 Dec 2004 17:38:01 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81BB543D45 for ; Mon, 13 Dec 2004 17:38:01 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id iBDHc01O000889; Mon, 13 Dec 2004 09:38:01 -0800 (PST) Received: from [10.1.1.245] (nfw1.codefab.com [199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id iBDHbxQS023290; Mon, 13 Dec 2004 09:38:00 -0800 (PST) In-Reply-To: <20041213090609.GA30379@webcom.it> References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> <41BB40B7.5000907@mac.com> <1B251E0B-4C95-11D9-A057-000393CFACB0@apple.com> <20041213090609.GA30379@webcom.it> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Mon, 13 Dec 2004 12:37:58 -0500 To: Andrea Campi X-Mailer: Apple Mail (2.619) cc: net@freebsd.org cc: Peter Heerboth Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 17:38:01 -0000 On Dec 13, 2004, at 4:06 AM, Andrea Campi wrote: > I'd like to live complications such as this for a later stage. I'd say > if you have a multihomed machine you better know how to configure it; > the primary target for my work are laptops and other clients. That is > not to say I don't care; rather, I need to limit how much I chew at a > time. For now I only work on one interface. Indeed, handling link-local addressing by only looking at one interface at a time is something the zeroconf spec seems to encourage if the implementation does not yet handle IP collision avoidance across multiple interfaces. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 17:44:45 2004 Return-Path: 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 7E8E416A4CE for ; Mon, 13 Dec 2004 17:44:45 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B229E43D1D for ; Mon, 13 Dec 2004 17:44:44 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) iBDHijeq023099 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2004 18:44:46 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.1/8.12.10/Submit) id iBDHijXK006107; Mon, 13 Dec 2004 18:44:45 +0100 (MET) Date: Mon, 13 Dec 2004 18:44:45 +0100 From: Daniel Hartmeier To: Max Laier Message-ID: <20041213174445.GA13268@insomnia.benzedrine.cx> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412131743.36722.max@love2party.net> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 17:44:45 -0000 On Mon, Dec 13, 2004 at 05:43:26PM +0100, Max Laier wrote: > > I'm glad to see any constructive comments on plan. > > Sorry, I don't see the point. If you are going to penalize the common case for > this I will object. On the other hand, if there was a simple (and cheap) way to disable packet filtering for arbitrary interfaces (for instance flag in struct ifnet, like 'ifconfig lo0 no-pfil' or such), that could be useful in cases like http://www.monkey.org/openbsd/archive/tech/0407/msg00061.html Daniel From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 17:53:07 2004 Return-Path: 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 50EFD16A4CE; Mon, 13 Dec 2004 17:53:07 +0000 (GMT) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB3F843D4C; Mon, 13 Dec 2004 17:53:06 +0000 (GMT) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.13.1/8.13.1) with ESMTP id iBDHr5L7059139; Mon, 13 Dec 2004 12:53:05 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.13.1/8.13.1/Submit) id iBDHr5ur059138; Mon, 13 Dec 2004 12:53:05 -0500 (EST) (envelope-from ras) Date: Mon, 13 Dec 2004 12:53:05 -0500 From: Richard A Steenbergen To: Andre Oppermann Message-ID: <20041213175305.GR6312@overlord.e-gerbil.net> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BDABFB.E64C0A31@freebsd.org> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 17:53:07 -0000 On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote: > > I'd like to implement per-interface pfil hooks, like in Cisco > > world. Each interface may have 'in' list of rules, 'out' list > > of rules. Current global ip_{input,output}, filters may coexist > > with per-interface ones, but can be turned off. > > Different worlds. I wonder why everything has to "like Cisco". It's > not always the most clever way they solve a given problem. The worlds are only different in so much as "most" FreeBSD boxes only have one network interface. If you have more that one interface on ANY platform, you really really really want the ability to have seperate interface rulesets. Trying to cram everything into one list with interface matching qualifiers, even if there is a magic optimization layer which wisks away the rules which can not match, is unnecessarily messy and backwards. Note that the ability to use a global filter is also still perfectly appropriate for a host vs a router. I don't see any reason reason that you couldn't support both, with interface specific rules being processed before global. As someone who has clearly spent a lot of time trying to un-hose fbsd's legacy network code, I'm surprised to see you on the wrong side of that argument. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 18:11:26 2004 Return-Path: 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 4F54116A4CE; Mon, 13 Dec 2004 18:11:26 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B63B43D2F; Mon, 13 Dec 2004 18:11:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id C43B17A403; Mon, 13 Dec 2004 10:11:25 -0800 (PST) Message-ID: <41BDDB4D.2050201@elischer.org> Date: Mon, 13 Dec 2004 10:11:25 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> In-Reply-To: <20041213124051.GB32719@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 18:11:26 -0000 Gleb Smirnoff wrote: > Dear networkers, > > I finally managed to pronounce my idea, although I'm afraid >of a bikeshed it is going to be burried under. > >When managing a complex router with many interfaces the output >of `ipfw show` (or ipf/pf analog) is getting long and difficult to >understand. It is also important that many packets are checked >against the rules that can never be applied to them, wasting CPU >cycles. > >A simple example can be local network router with many inner interfaces >and with one interface to internet. Actually filtering is desired >only in external interface, and there is no need for local traffic >to enter packet fitlering routines, e.g. ipfw_chk(). > >I'd like to implement per-interface pfil hooks, like in Cisco >world. Each interface may have 'in' list of rules, 'out' list >of rules. Current global ip_{input,output}, filters may coexist >with per-interface ones, but can be turned off. > >Our PFIL interface is quite ready for this, and this is very nice. >I'll start with creating/editing alternative chains in ipfw. Then >we will need to add possibility to register per-interface hooks >in pfil, and add possibility to pass one more optional argument >from pfil to the filter itself. > >I'm glad to see any constructive comments on plan. > > I do this now with the current ipfw unchanged.. my rules always start with something like: add 100 skipto 1000 ip from any to any in recv fxp0 add 101 skipto 2000 ip from any to any out xmit fxp0 add 110 skipto 3000 ip from any to any in recv fxp1 add 111 skipto 4000 ip from any to any out xmit fxp1 add 120 skipto 5000 ip from any to any in recv fxp2 add 121 skipto 6000 ip from any to any out xmit fxp2 This allows me to have a dedicated set of rules for each logical flow. Sometimes I even go one step further and define subsections for "out recv fxp0 xmit fxp1" and "from any to me in recv fxp1" .. etc I also sometimes break the rules up further with (for each interface set.) add 1000 skipto 1100 tcp from any to any add 2000 skipto 2100 tcp from any to any Then at 1050 ans 2050 I have processing for things like UDP and icmp. The aim is to minimise the running of unneeded rules, as you said. It is actually faster than just that because the rules in each section never need to test the interface or direction. I think this should be in an ipfw "howto". I'm not sayig we should n't do what you are saying but that it is already possible to do very similar things. From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 18:33:52 2004 Return-Path: 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 11B9C16A4CE for ; Mon, 13 Dec 2004 18:33:52 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 480FA43D5A for ; Mon, 13 Dec 2004 18:33:51 +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 iBDIXi5A050623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Dec 2004 21:33:44 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBDIXhDA037060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2004 21:33:44 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBDIXhmr037059; Mon, 13 Dec 2004 21:33:43 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 13 Dec 2004 21:33:43 +0300 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20041213183343.GA36707@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDDB4D.2050201@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BDDB4D.2050201@elischer.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 18:33:52 -0000 On Mon, Dec 13, 2004 at 10:11:25AM -0800, Julian Elischer wrote: J> I do this now with the current ipfw unchanged.. J> my rules always start with something like: J> J> add 100 skipto 1000 ip from any to any in recv fxp0 J> add 101 skipto 2000 ip from any to any out xmit fxp0 J> J> add 110 skipto 3000 ip from any to any in recv fxp1 J> add 111 skipto 4000 ip from any to any out xmit fxp1 J> J> add 120 skipto 5000 ip from any to any in recv fxp2 J> add 121 skipto 6000 ip from any to any out xmit fxp2 J> J> This allows me to have a dedicated set of rules for each logical flow. J> J> Sometimes I even go one step further and define subsections for J> "out recv fxp0 xmit fxp1" and "from any to me in recv fxp1" .. etc I often do the same way. We should admit that this is a workaround. And the fact that people are doing above setup means that it is claimed. This workaround is not error-prone, you can mess up rule numbers, not separated lists may collide, etc. And you can't have some interfaces without filter processing at all. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 18:42:03 2004 Return-Path: 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 2CEBB16A4CE for ; Mon, 13 Dec 2004 18:42:03 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A79343D41 for ; Mon, 13 Dec 2004 18:42:02 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBDIg0ea062338; Mon, 13 Dec 2004 10:42:00 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBDIg0FR062337; Mon, 13 Dec 2004 10:42:00 -0800 (PST) (envelope-from rizzo) Date: Mon, 13 Dec 2004 10:42:00 -0800 From: Luigi Rizzo To: Max Laier Message-ID: <20041213104200.A62152@xorpc.icir.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200412131743.36722.max@love2party.net>; from max@love2party.net on Mon, Dec 13, 2004 at 05:43:26PM +0100 cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 18:42:03 -0000 On Mon, Dec 13, 2004 at 05:43:26PM +0100, Max Laier wrote: ... > > When managing a complex router with many interfaces the output > > of `ipfw show` (or ipf/pf analog) is getting long and difficult to > > understand. It is also important that many packets are checked > > against the rules that can never be applied to them, wasting CPU > > cycles. > > That's an error in the ruleset evaluation code then. Pf automatically jumps > over rules that cannot be matched after one failed. If you have a block of > 1000 rules "on xl0" and the first one does not match because of the interface > pf will continue checking with rule #1001. I am not sure if such shortcuts > are possible for ipfw, but I suggest looking into that first. well well well... what you say above just means that pf rules are internally stored 'per interface'. It is an optimization much like the one suggested in the original posting. I considered doing that when designing ipfw2 (implementing per-interface lists in addition to the global one, for backward compatibility), but then decided against it because 1) a simple initial switch based on the interface checks -- basically the way as julian suggested -- is very fast provided you don't have tens of interfaces (which, I admit, could be the case if you have many many vlans or ppp or ng nodes), and 2) this way you can do the initial demultiplexing in the most appropriate way for your configuration (e.g. based on protocol, interface name or type, direction, address ranges...) as opposed to TheOnlyWaySuppliedByTheSystem. Not that I am against adding the feature, but i think the performance gain is modest, and readability is not going to improve a lot because you have to remember the existance of global and per-interface rulesets (the former are mandatory for backward compatibility) and the criteria for using one or the other or both. In the end i think it confuses ideas even more. If you care about readability of the packet filter configuration, i think you are better off spending your time building suitable preprocessing tools, and commenting your configurations (remember that // style comments can be stored in ipfw2 rules and there is a listing mode that shows just action+comments, not even the rule bodies, so you can see what the configuration is supposed to do. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 18:47:03 2004 Return-Path: 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 D92E516A4CE; Mon, 13 Dec 2004 18:47:03 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2723E43D2D; Mon, 13 Dec 2004 18:47:03 +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 iBDIl1Fl050819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Dec 2004 21:47:02 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBDIl162037166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2004 21:47:01 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBDIl09O037165; Mon, 13 Dec 2004 21:47:00 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 13 Dec 2004 21:47:00 +0300 From: Gleb Smirnoff To: Andre Oppermann , mlaier@freebsd.org Message-ID: <20041213184700.GA37107@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BDABFB.E64C0A31@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 18:47:04 -0000 Andre, Max, please don't take this hard. I'm not going to change pfil(4) API, since it has everything required. Max, you showed me that pf has some optimizations. ipfw has only skipto rule, it helps to reduce CPU consumption, but makes 'ipfw show' more complicated. On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote: A> > When managing a complex router with many interfaces the output A> > of `ipfw show` (or ipf/pf analog) is getting long and difficult to A> > understand. It is also important that many packets are checked A> > against the rules that can never be applied to them, wasting CPU A> > cycles. A> > A> > A simple example can be local network router with many inner interfaces A> > and with one interface to internet. Actually filtering is desired A> > only in external interface, and there is no need for local traffic A> > to enter packet fitlering routines, e.g. ipfw_chk(). A> A> Then you argument about long ipfw show doesn't hold... ;) I mean that this feature can be useful on a complicated setups because of maintainability, and even on simple ones, because of speed. A> > I'd like to implement per-interface pfil hooks, like in Cisco A> > world. Each interface may have 'in' list of rules, 'out' list A> > of rules. Current global ip_{input,output}, filters may coexist A> > with per-interface ones, but can be turned off. A> A> Different worlds. I wonder why everything has to "like Cisco". It's A> not always the most clever way they solve a given problem. Andre, I know your dislikes about Cisco, and I share it too. Idea of maintaining separate filter lists for each interface is handy, no matter that it is like in Cisco. Before writing this mail I have a lot of practice with complicated firewall setups, and I have asked several network administrators, who run FreeBSD routers, for their opinion. A> > Our PFIL interface is quite ready for this, and this is very nice. A> A> I don't see any changes to pfil for this. Pfil already passes the A> interface in the argument call. This is something for the packet A> filters (ipfw/pf/ipf) than the pfil API? (Now I speak only about ipfw. But other filters can be used in same manner with a very small changes.) We have list of rules defined in struct ip_fw_chain. At this moment we have only one instance of it - a global variable layer3_chain. What I'm going to do: 1) adding possibility to add new chains and editing them. 2) adding possibility to run ipfw_chk() against a chain other than layer3_chain. 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk() on different chains. Supply chain identifier in void arg. Edit ipfw_hook() so that it can register ipfw as a pfil, but with chain different to layer3_chain. 4) add possibility to register a pfil_head for an interface. Once the pfil_head is registered, administrator can call ipfw_hook() on it, and hook ipfw chain to this pfil_head, either in or out. 5) In ip_input()/ip_output() check if interface has pfil_head associated with it. If it does pfil_run_hooks on it. Important points: 1. No API breakage in PFIL, at least I don't see any problems now. 2. No conflicts with current filtering. Interface filters can happily coexist with global ones. 3. Overhead of comparing one pointer. A> > I'll start with creating/editing alternative chains in ipfw. Then A> > we will need to add possibility to register per-interface hooks A> > in pfil, and add possibility to pass one more optional argument A> > from pfil to the filter itself. A> A> Can you provide example how you think the syntax should be? A> A> > I'm glad to see any constructive comments on plan. A> A> You have to be careful not to collide with the "in|out|via" inside A> the rules. It is not going to collide. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 20:28:11 2004 Return-Path: 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 A4CBC16A4CE for ; Mon, 13 Dec 2004 20:28:11 +0000 (GMT) Received: from mta08-winn.mailhost.ntl.com (mailhost.ntl.com [212.250.162.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B97C43D55 for ; Mon, 13 Dec 2004 20:28:10 +0000 (GMT) (envelope-from andywhite@ntlworld.ie) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP <20041213202808.FLEG24423.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com> for ; Mon, 13 Dec 2004 20:28:08 +0000 Received: from HOMEBREW ([81.98.95.65]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20041213202808.LFYU27146.aamta01-winn.mailhost.ntl.com@HOMEBREW> for ; Mon, 13 Dec 2004 20:28:08 +0000 From: "Andrew White" To: Date: Mon, 13 Dec 2004 20:31:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041208233954.HXJM1456.aamta06-winn.mailhost.ntl.com@HOMEBREW> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTdf7kwsbdYKzI+R6Wuq69N8qD3BgD0slmQ Message-Id: <20041213202808.LFYU27146.aamta01-winn.mailhost.ntl.com@HOMEBREW> Subject: RE: Best layer 2 bridge over IP solution ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 20:28:11 -0000 Thanks to everyone for their suggestions which included ng_bridge using ng_ksocket or ng_gif OpenBSD OpenVPN It turns out cisco support l2tpv3 on the new routers and it works perfectly, but is expensive, so I will give these solutions a test ! Tks .Andrew -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Andrew White Sent: 08 December 2004 23:44 To: freebsd-net@freebsd.org Subject: Best layer 2 bridge over IP solution ? I'm looking for suggestions to the problem below, any help appreciated !! I have several offices which use LAT MOP and IPX. This works over the existing WAN as it is a combination of bridging and routing (routed IP ). I would like to move to a pure IP network, but need to transport these protocols until we can remove them entirely from the network. Is Vtun and netgraph the way to go ? Or is there a simple more stable/proven method of achiving this ? Thanks in advance !! .Andrew _______________________________________________ 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-net@FreeBSD.ORG Mon Dec 13 21:04:51 2004 Return-Path: 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 43FBB16A4CE; Mon, 13 Dec 2004 21:04:51 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A44043D31; Mon, 13 Dec 2004 21:04:50 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.1/8.13.1) with ESMTP id iBDL4nIn021743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2004 16:04:49 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id iBDL4i4V054808; Mon, 13 Dec 2004 16:04:44 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16830.1004.797220.47672@grasshopper.cs.duke.edu> Date: Mon, 13 Dec 2004 16:04:44 -0500 (EST) To: Andre Oppermann In-Reply-To: <41BDD1C7.7060105@freebsd.org> References: <41BA0088.9000107@freebsd.org> <41BDD1C7.7060105@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-net@freebsd.org Subject: Re: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 21:04:51 -0000 Andre Oppermann writes: > > I've got some excellent review feedback from Mike Spengler and he found > a off-by-one queue limit tracking error. > > http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch > Here are the same tests running your new patch in comparison to a stock 6.x kernel from Friday. It looks like everything is faster. I've never seen 3.7Gb/sec on FreeBSD before. Nice work! The "before" and "tcp_reass-20041213" kernels differ only in the contents of the above patch. I ran netperf with 20 times for each of 4 socket buffer sizes (64KB, 128KB, 256KB, and 1MB) before and after patching. All tests were run with net.isr.enable=1, and machdep.cpu_idle_hlt=0. CPU was pretty much maxed thoughout. (SMP kernel, 1 HTT p4). All the numbers in Mb/sec. The sender was running linux-2.6.6 (also SMP on an identical HTT P4). The out-of-order accounting bug seems to be gone. Drew x before.65536 + tcp_reass-20041213.65536 +--------------------------------------------------------------------------+ | + | | + | | xx + + + + +*x + ++ ++ + ++ + +++| ||__________________A________|______M__|_____MA________________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 4 3121.03 3135.88 3135.27 3128.3325 8.3667691 + 20 3126.75 3151.97 3139.41 3139.608 7.5192088 Difference at 95.0% confidence 11.2755 +/- 8.67923 0.360432% +/- 0.277439% (Student's t, pooled s = 7.64032) x before.131072 + tcp_reass-20041213.131072 +--------------------------------------------------------------------------+ | x x ++ xx + + + | |x x xxx xx*x x x+* + xxx++ + + + ++ + + + +| | |_________AM_______||_____________A_M_____________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 20 3336.63 3516.95 3449.87 3447.838 52.708815 + 20 3443.67 3717.15 3579.92 3571.8355 80.445555 Difference at 95.0% confidence 123.997 +/- 43.5271 3.59638% +/- 1.26245% (Student's t, pooled s = 68.0063) x before.262144 + tcp_reass-20041213.262144 +--------------------------------------------------------------------------+ | x + | | x x ++ x + ++ | |+ x x x x xx+ *x x * ++ +xx xx+ x++ + * + +| | |_______|____A_________A__|M__________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 20 3197.77 3421.67 3316.64 3314.8555 59.787371 + 20 3135.57 3479.29 3380.31 3361.5785 71.303501 Difference at 95.0% confidence 46.723 +/- 42.1136 1.4095% +/- 1.27045% (Student's t, pooled s = 65.7979) x before.1048576 + tcp_reass-20041213.1048576 +--------------------------------------------------------------------------+ | + + | | x + +x x+ x+ | |xx x x *x * x x * +x +* x+x+x++ x+ ++ +| | |_______________A|__M________AM|__________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 20 2658.05 2732.45 2706.91 2700.1955 23.318833 + 20 2686.35 2765.88 2722.09 2720.7805 18.752084 Difference at 95.0% confidence 20.585 +/- 13.5427 0.762352% +/- 0.501546% (Student's t, pooled s = 21.159) From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 21:13:37 2004 Return-Path: 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 4B6E916A4CE for ; Mon, 13 Dec 2004 21:13:37 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CF9F43D5C for ; Mon, 13 Dec 2004 21:13:36 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 21431 invoked from network); 13 Dec 2004 21:02:36 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Dec 2004 21:02:36 -0000 Message-ID: <41BE05FE.7CBA6BBA@freebsd.org> Date: Mon, 13 Dec 2004 22:13:34 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard A Steenbergen References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213175305.GR6312@overlord.e-gerbil.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 21:13:37 -0000 Richard A Steenbergen wrote: > > On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote: > > > I'd like to implement per-interface pfil hooks, like in Cisco > > > world. Each interface may have 'in' list of rules, 'out' list > > > of rules. Current global ip_{input,output}, filters may coexist > > > with per-interface ones, but can be turned off. > > > > Different worlds. I wonder why everything has to "like Cisco". It's > > not always the most clever way they solve a given problem. > > The worlds are only different in so much as "most" FreeBSD boxes only have > one network interface. If you have more that one interface on ANY > platform, you really really really want the ability to have seperate > interface rulesets. Trying to cram everything into one list with interface > matching qualifiers, even if there is a magic optimization layer which > wisks away the rules which can not match, is unnecessarily messy and > backwards. Well, this is a question of the userland interface of any particular firewall set, be it ipfw, pf or ipf. The kernel and pfil API is not in the way of doing it. > Note that the ability to use a global filter is also still perfectly > appropriate for a host vs a router. I don't see any reason reason that you > couldn't support both, with interface specific rules being processed > before global. As someone who has clearly spent a lot of time trying to > un-hose fbsd's legacy network code, I'm surprised to see you on the wrong > side of that argument. :) I'm against making things complicated on the coding side. I'm a fan of KISS. Sure we can do and become everything for everyone with two gazillion sysctls and one-thousand compile time options but it's not going to scale and only a minority will use it at any given time. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 21:20:01 2004 Return-Path: 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 560AB16A544 for ; Mon, 13 Dec 2004 21:20:01 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80DBE43D58 for ; Mon, 13 Dec 2004 21:20:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 21476 invoked from network); 13 Dec 2004 21:09:00 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Dec 2004 21:09:00 -0000 Message-ID: <41BE077E.5CD2B517@freebsd.org> Date: Mon, 13 Dec 2004 22:19:58 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: <20041213124051.GB32719@cell.sick.ru> <41BDDB4D.2050201@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 21:20:01 -0000 Julian Elischer wrote: > > Gleb Smirnoff wrote: > > > Dear networkers, > > > > I finally managed to pronounce my idea, although I'm afraid > > of a bikeshed it is going to be burried under. ... > I'm not sayig we should n't do what you are saying but that it is > already possible to do very similar things. I'm not against this as such. However it's more of a presentaion and user interface issue than a kernel issue. I'm certanly against hacking the kernel to make this possible and it's not needed in this case. With the different firewall packages different solutions with different representations for this problem exists. Maybe the only thing neede is a different ipfw(8) userland application with a syntax more suitable to what Gleb wants to present to the user. In the background it would issue the normal ipfw micro-ops which are entirely sufficient in functionality. Like writing "hello world" in different programming languages, the machine code is pretty much the same. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 21:34:21 2004 Return-Path: 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 AE0A916A4CE for ; Mon, 13 Dec 2004 21:34:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B66B443D31 for ; Mon, 13 Dec 2004 21:34:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 21567 invoked from network); 13 Dec 2004 21:23:19 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Dec 2004 21:23:19 -0000 Message-ID: <41BE0ADA.9A1EE748@freebsd.org> Date: Mon, 13 Dec 2004 22:34:18 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin References: <41BA0088.9000107@freebsd.org> <16830.1004.797220.47672@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 21:34:21 -0000 Andrew Gallatin wrote: > > Andre Oppermann writes: > > > > I've got some excellent review feedback from Mike Spengler and he found > > a off-by-one queue limit tracking error. > > > > http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch > > > > Here are the same tests running your new patch in comparison to a > stock 6.x kernel from Friday. It looks like everything is faster. Excellent! > I've never seen 3.7Gb/sec on FreeBSD before. Nice work! Thanks! > The "before" and "tcp_reass-20041213" kernels differ only in the > contents of the above patch. I ran netperf with 20 times for each of > 4 socket buffer sizes (64KB, 128KB, 256KB, and 1MB) before and after > patching. All tests were run with net.isr.enable=1, and > machdep.cpu_idle_hlt=0. CPU was pretty much maxed thoughout. (SMP > kernel, 1 HTT p4). All the numbers in Mb/sec. The sender was running > linux-2.6.6 (also SMP on an identical HTT P4). > > The out-of-order accounting bug seems to be gone. Perfect. I want to get this patch into the tree next. I have already the next round in the works which is optimized even more by merging consecutive mbuf chains together (at the moment I have packet segment chains which have a direct pointer to the mbuf at the end of the chain) and which get passed in one go to soappend_stream. This removes the "present" loop and simplifies the general code a bit more again. With this and two other optimizations I have in mind you should be able to get very close to the theoretical maximum bandwidth of your current 4Gig Myrinet cards. There are a couple of other TCP tweaks that would help your special case some more now though. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 21:48:41 2004 Return-Path: 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 A85E716A4CE; Mon, 13 Dec 2004 21:48:41 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A9343D73; Mon, 13 Dec 2004 21:48:40 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.1/8.13.1) with ESMTP id iBDLmeA4027513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2004 16:48:40 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id iBDLmZwV054857; Mon, 13 Dec 2004 16:48:35 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16830.3635.392271.923345@grasshopper.cs.duke.edu> Date: Mon, 13 Dec 2004 16:48:35 -0500 (EST) To: Andre Oppermann In-Reply-To: <41BE0ADA.9A1EE748@freebsd.org> References: <41BA0088.9000107@freebsd.org> <41BDD1C7.7060105@freebsd.org> <16830.1004.797220.47672@grasshopper.cs.duke.edu> <41BE0ADA.9A1EE748@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-net@freebsd.org Subject: Re: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 21:48:42 -0000 Andre Oppermann writes: > > I have already the next round in the works which is optimized even more > by merging consecutive mbuf chains together (at the moment I have packet > segment chains which have a direct pointer to the mbuf at the end of the > chain) and which get passed in one go to soappend_stream. This removes > the "present" loop and simplifies the general code a bit more again. Great.. I've been a little busy, and have only run tests -- I haven't even looked at the code ;) > With this and two other optimizations I have in mind you should be able > to get very close to the theoretical maximum bandwidth of your current > 4Gig Myrinet cards. > > There are a couple of other TCP tweaks that would help your special case > some more now though. FWIW, the out-of-order frames are a firmware bug that we hope to fix soon. Its just icing on the cake that the bug makes such a nice test case for you ;) With no copy overhead (kttcp), 3.95Gb/sec is easily achievable, even in 5-stable with the old TCP reassembly code. Drew From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 21:50:04 2004 Return-Path: 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 79FE216A4D1 for ; Mon, 13 Dec 2004 21:50:04 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 424DE43D5D for ; Mon, 13 Dec 2004 21:50:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 21672 invoked from network); 13 Dec 2004 21:39:02 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Dec 2004 21:39:02 -0000 Message-ID: <41BE0E89.AE21445@freebsd.org> Date: Mon, 13 Dec 2004 22:50:01 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mlaier@freebsd.org cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 21:50:04 -0000 Gleb Smirnoff wrote: > > Andre, Max, > > please don't take this hard. I'm not going to change pfil(4) API, > since it has everything required. Great. > Max, you showed me that pf has some optimizations. ipfw has only skipto > rule, it helps to reduce CPU consumption, but makes 'ipfw show' > more complicated. Yes. > On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote: > A> > When managing a complex router with many interfaces the output > A> > of `ipfw show` (or ipf/pf analog) is getting long and difficult to > A> > understand. It is also important that many packets are checked > A> > against the rules that can never be applied to them, wasting CPU > A> > cycles. > A> > > A> > A simple example can be local network router with many inner interfaces > A> > and with one interface to internet. Actually filtering is desired > A> > only in external interface, and there is no need for local traffic > A> > to enter packet fitlering routines, e.g. ipfw_chk(). > A> > A> Then you argument about long ipfw show doesn't hold... ;) > > I mean that this feature can be useful on a complicated setups > because of maintainability, and even on simple ones, because > of speed. I don't believe the speed one. See Luigi's reply as well. > A> > I'd like to implement per-interface pfil hooks, like in Cisco > A> > world. Each interface may have 'in' list of rules, 'out' list > A> > of rules. Current global ip_{input,output}, filters may coexist > A> > with per-interface ones, but can be turned off. > A> > A> Different worlds. I wonder why everything has to "like Cisco". It's > A> not always the most clever way they solve a given problem. > > Andre, I know your dislikes about Cisco, and I share it too. Idea > of maintaining separate filter lists for each interface is handy, no > matter that it is like in Cisco. Before writing this mail I have a lot > of practice with complicated firewall setups, and I have asked several > network administrators, who run FreeBSD routers, for their opinion. This is ok. It was more of an rhetorical rant by me. > A> > Our PFIL interface is quite ready for this, and this is very nice. > A> > A> I don't see any changes to pfil for this. Pfil already passes the > A> interface in the argument call. This is something for the packet > A> filters (ipfw/pf/ipf) than the pfil API? > > (Now I speak only about ipfw. But other filters can be used in same > manner with a very small changes.) > > We have list of rules defined in struct ip_fw_chain. At this moment > we have only one instance of it - a global variable layer3_chain. > What I'm going to do: > 1) adding possibility to add new chains and editing them. > 2) adding possibility to run ipfw_chk() against a chain other than > layer3_chain. > 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk() > on different chains. Supply chain identifier in void arg. Edit > ipfw_hook() so that it can register ipfw as a pfil, but with > chain different to layer3_chain. This is what I don't get. You can register only once with pfil. > 4) add possibility to register a pfil_head for an interface. Once the > pfil_head is registered, administrator can call ipfw_hook() on > it, and hook ipfw chain to this pfil_head, either in or out. > 5) In ip_input()/ip_output() check if interface has pfil_head > associated with it. If it does pfil_run_hooks on it. You are going to change the pfil API. This is not neccessary. pfil passes the ifp to the hook, this is sufficient. > Important points: > 1. No API breakage in PFIL, at least I don't see any problems now. But Max and me see problems. The API does not break but it is different. We don't want it to be different in such a way. > 2. No conflicts with current filtering. Interface filters can happily > coexist with global ones. You haven't talked about the presentation interface towards the user. This is where everything has to start. How would the ipfw syntax look like? Provide some examples please. The problem we have is that you have a specific solution in mind without adequatly stating the problem first. Because then we would sit down and work out what the best way is to implement it. So far Max and I do not agree with you on the your stated ideas to solve this. -- Andre > 3. Overhead of comparing one pointer. > > A> > I'll start with creating/editing alternative chains in ipfw. Then > A> > we will need to add possibility to register per-interface hooks > A> > in pfil, and add possibility to pass one more optional argument > A> > from pfil to the filter itself. > A> > A> Can you provide example how you think the syntax should be? > A> > A> > I'm glad to see any constructive comments on plan. > A> > A> You have to be careful not to collide with the "in|out|via" inside > A> the rules. > > It is not going to collide. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Dec 13 22:27:02 2004 Return-Path: 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 1331416A4CE for ; Mon, 13 Dec 2004 22:27:02 +0000 (GMT) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4797D43D1D for ; Mon, 13 Dec 2004 22:27:01 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (ss.eunet.cz. [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id iBDMQlvJ090299 for ; Mon, 13 Dec 2004 23:26:47 +0100 (CET) (envelope-from mime@traveller.cz) Message-ID: <41BE1731.8070902@traveller.cz> Date: Mon, 13 Dec 2004 23:26:57 +0100 From: Michal Mertl User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; cs-CZ; rv:1.7.3) Gecko/20041117 X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: extending ifmib(4) and de-mem(4)izing netstat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2004 22:27:02 -0000 Hello all, I like the idea of a system without mem(4) but some system utilities depend on it. I thought I would go and change them to use other ways to get the information. I started with 'netstat -r' and almost completely (refcnt field is missing) removed the need for /dev/mem (in fact there already was incomplete support for it in the sources). I then went to reimplement 'netstat -i' and found out I can't get all the information from sysctls. The stats which I can't find are the counters for addresses configured on the interfaces (in kernel stored in struct in_ifaddr). Am I missing something or would I have to export the data from the kernel? What is the best way to export them? I can see two ways: make it accessible like if_data is exported for physical interfaces in getifaddrs(3) or export the data into some other place like ifmib(4) - e.g. net.inet.generic and net.inet6.generic. From getifaddrs.c I can see that one way to add the information would be to implement something called ifam_data (probably in fact struct ifam_msghdr) which is present on BSDI. It would probably be also possible to hack it rather easily into sysctl_iflist (src/sys/net/rtsock.c) a-la ifm_data member of struct if_msghdr. P.S.: It was a great adventure to browse through the code trying to understand what it does. Did humans write it? :-) I'm talking about the data structures in the kernel, netstat sources are on the other hand a mess. -- Michal Mertl From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 00:06:34 2004 Return-Path: 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 B883316A4DB for ; Tue, 14 Dec 2004 00:06:34 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE3D043D58 for ; Tue, 14 Dec 2004 00:06:32 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iBE05S3e024935 for ; Tue, 14 Dec 2004 10:35:28 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Tue, 14 Dec 2004 10:36:22 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iBDNtGQ30278 for ; Tue, 14 Dec 2004 10:25:16 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK36TF8S; Tue, 14 Dec 2004 10:25:10 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iBDNtjJ2037104 for ; Tue, 14 Dec 2004 10:25:45 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iBDNtjqt037103 for net@freebsd.org; Tue, 14 Dec 2004 10:25:45 +1030 (CST) (envelope-from wilkinsa) Date: Tue, 14 Dec 2004 10:25:45 +1030 From: "Wilkinson, Alex" To: net@freebsd.org Message-ID: <20041213235545.GF36827@squash.dsto.defence.gov.au> Mail-Followup-To: net@freebsd.org References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20041213184700.GA37107@cell.sick.ru> User-Agent: Mutt/1.5.6i Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 00:06:34 -0000 0n Mon, Dec 13, 2004 at 09:47:00PM +0300, Gleb Smirnoff wrote: > Andre, I know your dislikes about Cisco, and I share it too. Idea > of maintaining separate filter lists for each interface is handy, no > matter that it is like in Cisco. Before writing this mail I have a lot > of practice with complicated firewall setups, and I have asked several > network administrators, who run FreeBSD routers, for their opinion. Why in the hell do you guys have such a problem with Cisco ? - aW From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 00:08:23 2004 Return-Path: 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 6EB8016A4CE for ; Tue, 14 Dec 2004 00:08:23 +0000 (GMT) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8273E43D67 for ; Tue, 14 Dec 2004 00:08:22 +0000 (GMT) (envelope-from keiichi@iijlab.net) Received: OMGO id iBE08Irc017279; Tue, 14 Dec 2004 09:08:18 +0900 (JST) Received: OTM-MIX0 id iBE08HUx013833; Tue, 14 Dec 2004 09:08:17 +0900 (JST) Received: JC-SMTP from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) id iBE08Hcv008223; Tue, 14 Dec 2004 09:08:17 +0900 (JST) Date: Tue, 14 Dec 2004 09:07:17 +0900 (JST) Message-Id: <20041214.090717.77151330.keiichi@iijlab.net> To: liettneff@bk.ru From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <1665849094.20041213132520@bk.ru> References: <196116794593.20041210071459@bk.ru> <20041213.190726.38982816.keiichi@iijlab.net> <1665849094.20041213132520@bk.ru> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: KAME mip6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 00:08:23 -0000 Hi, From: Michael Lednev Subject: Re[2]: KAME mip6 Date: Mon, 13 Dec 2004 13:25:20 +0300 > Bkin> The latest KAME snap shot of FreeBSD5.3+KAME already have MIP6 code. > Bkin> However, the code is not the same with the old KAME/MIP6. We are now > Bkin> rewriting the code as a user space program. (The old KAME/MIP6 is > Bkin> implemented in a kernel space) > > you mean that you how-to from http://www.kame.net/newsletter/20031007/ > will not work with kame+freebsd5? No, it (the old code) won't work on FreeBSD5+KAME. > Bkin> Unfortunately, the quality is not very good compared to the old one, > Bkin> but, we will try to improve the new code continuously. > > i tried snap from 20041122 and got compilation error described in > http://www.kame.net/dev/query-pr.cgi?pr=808 have anything changed > since? Yes, we have replaced the code. The new code supports FreeBSD5.3+KAME. We also provide a brief introduction of the new code. Please look at http://www.kame.net/newsletter/20041211/, too. Note that the code is not good quality for now. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 05:33:08 2004 Return-Path: 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 4057116A506; Tue, 14 Dec 2004 05:33:08 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E4A943D31; Tue, 14 Dec 2004 05:33:08 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 89ED32F947; Tue, 14 Dec 2004 00:33:07 -0500 (EST) Date: Tue, 14 Dec 2004 00:33:07 -0500 From: James To: Gleb Smirnoff Message-ID: <20041214053307.GA97056@scylla.towardex.com> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041213184700.GA37107@cell.sick.ru> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 05:33:08 -0000 I'm personally against modifying ipfw(4) for this purpose. It gets into the complexity of syntax and simply violates the initial simple model of the whole ipfw packet filter itself. I agree in that freebsd systems acting as routers need a more "efficient" or "better" engine by allowing per-interface firewall hooks, but we all know pfil_hooks api already provides this; and modifying ipfw for this is just a mess for a little gain. That said, the pfil_hooks already provides the ifp -- so why not just write a new firewall of your own that is totally separate from pf/ipfw? Please feel free to make it as compiled (like Crisco Turbo ACL) instead of linear rule by rule checks :) Just need to make it compatible to pfil_hooks api. While it is good to make freebsd more router-like, keeping things simple for systems acting as non-routing platforms for endusers is also equally important. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 08:05:54 2004 Return-Path: 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 1F7E316A4CE for ; Tue, 14 Dec 2004 08:05:54 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id E6B0743D72 for ; Tue, 14 Dec 2004 08:05:52 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 32690 invoked from network); 14 Dec 2004 08:05:48 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 14 Dec 2004 08:05:48 -0000 Received: (qmail 4322 invoked by uid 1000); 14 Dec 2004 08:05:50 -0000 Date: Tue, 14 Dec 2004 10:05:50 +0200 From: Peter Pentchev To: freebsd-net@FreeBSD.org Message-ID: <20041214080549.GC3183@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q" Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: Darren Reed Subject: IPFilter, mpd/Netgraph problems on RELENG_4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 08:05:54 -0000 --rQ2U398070+RC21q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I am seeing a lot of ICMP Must Fragment packets with incorrect ICMP checksums on a RELENG_4 box which holds up 40-60 PPTP (mpd/Netgraph) VPN connections at any given time. The peer understandably ignores the ICMP packet with a bad checksum and never fragments the offending TCP packet, effectively killing the connection after a while. A major point is that I'm only seeing them on the interfaces NAT'ed by ipnat. Is anybody else having trouble with ICMP checkums with IPFilter 3.4.35 on a reasonably recent RELENG_4 box? FreeBSD unnamed 4.10-STABLE FreeBSD 4.10-STABLE #1: Thu Dec 2 10:31:16 EET = 2004 root@unnamed:/usr/obj/usr/src-bsd/4.0S/src/sys/UNNAMED i386 drwxr-xr-x 2 root wheel 512 Dec 2 11:43 /var/db/pkg/mpd-3.18_2 G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. --rQ2U398070+RC21q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBvp7d7Ri2jRYZRVMRAtAZAJ43LBp23NZxxdR4xYU4dNMtfrbtogCbBHQj KuxegUvh8sEPZgJj24zrnbw= =FgDi -----END PGP SIGNATURE----- --rQ2U398070+RC21q-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 08:21:01 2004 Return-Path: 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 7EE1016A4CE for ; Tue, 14 Dec 2004 08:21:01 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B53A643D46 for ; Tue, 14 Dec 2004 08:21:00 +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 iBE8KveK061684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 11:20:58 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBE8KuXJ042836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 11:20:57 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBE8KuHG042835; Tue, 14 Dec 2004 11:20:56 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 11:20:56 +0300 From: Gleb Smirnoff To: James Message-ID: <20041214082056.GA42820@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> <20041214053307.GA97056@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041214053307.GA97056@scylla.towardex.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 08:21:01 -0000 James, On Tue, Dec 14, 2004 at 12:33:07AM -0500, James wrote: J> I'm personally against modifying ipfw(4) for this purpose. It gets into the J> complexity of syntax and simply violates the initial simple model of the whole J> ipfw packet filter itself. I agree in that freebsd systems acting as routers J> need a more "efficient" or "better" engine by allowing per-interface firewall J> hooks, but we all know pfil_hooks api already provides this; and modifying J> ipfw for this is just a mess for a little gain. you will not notice anything new in your day to day ipfw usage. The change will not hurt any of current users. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 08:51:30 2004 Return-Path: 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 2101616A4CE for ; Tue, 14 Dec 2004 08:51:30 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36DEA43D49 for ; Tue, 14 Dec 2004 08:51:29 +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 iBE8pQwS062348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 11:51:27 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBE8pPWn043037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 11:51:26 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBE8pOkm043028; Tue, 14 Dec 2004 11:51:24 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 11:51:23 +0300 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20041214085123.GB42820@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Luigi Rizzo , Max Laier , freebsd-net@freebsd.org References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041213104200.A62152@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 08:51:30 -0000 Luigi, On Mon, Dec 13, 2004 at 10:42:00AM -0800, Luigi Rizzo wrote: L> I considered doing that when designing ipfw2 (implementing per-interface L> lists in addition to the global one, for backward compatibility), L> but then decided against it because 1) a simple initial switch based L> on the interface checks -- basically the way as julian suggested L> -- is very fast provided you don't have tens of interfaces (which, L> I admit, could be the case if you have many many vlans or ppp or L> ng nodes), and 2) this way you can do the initial demultiplexing L> in the most appropriate way for your configuration (e.g. based on L> protocol, interface name or type, direction, address ranges...) as L> opposed to TheOnlyWaySuppliedByTheSystem. L> L> Not that I am against adding the feature, but i think the L> performance gain is modest, and readability is not going It depends on router configuration. L> to improve a lot because you have to remember the existance L> of global and per-interface rulesets (the former are mandatory L> for backward compatibility) and the criteria for using one or L> the other or both. In the end i think it confuses ideas even more. They are not mandatory: net.inet.ip.fw.enable = 0. When one uses per-interface filters, it is suggested do not use global ones. L> If you care about readability of the packet filter configuration, L> i think you are better off spending your time building suitable L> preprocessing tools, and commenting your configurations (remember L> that // style comments can be stored in ipfw2 rules and there is L> a listing mode that shows just action+comments, not even the rule bodies, L> so you can see what the configuration is supposed to do. I know this. We have a well commented firewall scripts, we store them at RCS, we do many things to make our life easier. But my practice (and my collegues) shows that per interface filters are easier to understand and maintain when number of interfaces grows up to 20 and more, and they all are logically different - clients, servers, DMZs, hardware, nated networks, etc. Again, this feature is not for all. This is for people who build complicated routers on FreeBSD. It is not going to hurt standard host setups. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 08:53:13 2004 Return-Path: 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 832BE16A4CE; Tue, 14 Dec 2004 08:53:13 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B663343D62; Tue, 14 Dec 2004 08:53:12 +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 iBE8rBvm062412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 11:53:11 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBE8rANe043084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 11:53:11 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBE8rAOx043083; Tue, 14 Dec 2004 11:53:10 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 11:53:10 +0300 From: Gleb Smirnoff To: Peter Pentchev Message-ID: <20041214085310.GC42820@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Peter Pentchev , freebsd-net@freebsd.org, Darren Reed References: <20041214080549.GC3183@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041214080549.GC3183@straylight.m.ringlet.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: Darren Reed cc: freebsd-net@freebsd.org Subject: Re: IPFilter, mpd/Netgraph problems on RELENG_4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 08:53:13 -0000 Peter, does the problem disappear if you turn ipfilter off, and run natd on this interface? it is not clear from your mail. On Tue, Dec 14, 2004 at 10:05:50AM +0200, Peter Pentchev wrote: P> I am seeing a lot of ICMP Must Fragment packets with incorrect ICMP P> checksums on a RELENG_4 box which holds up 40-60 PPTP (mpd/Netgraph) VPN P> connections at any given time. The peer understandably ignores the ICMP P> packet with a bad checksum and never fragments the offending TCP packet, P> effectively killing the connection after a while. P> P> A major point is that I'm only seeing them on the interfaces NAT'ed by P> ipnat. Is anybody else having trouble with ICMP checkums with IPFilter P> 3.4.35 on a reasonably recent RELENG_4 box? P> P> FreeBSD unnamed 4.10-STABLE FreeBSD 4.10-STABLE #1: Thu Dec 2 10:31:16 EET 2004 root@unnamed:/usr/obj/usr/src-bsd/4.0S/src/sys/UNNAMED i386 P> P> drwxr-xr-x 2 root wheel 512 Dec 2 11:43 /var/db/pkg/mpd-3.18_2 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 08:57:26 2004 Return-Path: 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 1C3D216A4CE; Tue, 14 Dec 2004 08:57:26 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 547CC43D3F; Tue, 14 Dec 2004 08:57:25 +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 iBE8vOHR062597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 11:57:24 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBE8vNsW044324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 11:57:23 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBE8vNfx044323; Tue, 14 Dec 2004 11:57:23 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 11:57:22 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041214085722.GD42820@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BDABFB.E64C0A31@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 08:57:26 -0000 On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote: A> Different worlds. I wonder why everything has to "like Cisco". It's A> not always the most clever way they solve a given problem. By the way, Juniper has per-interface filters, too. Juniper's world is not so far from ours, as Cisco's is :) Strange to hear from you that "different worlds". If I remember correctly you run full BGP on FreeBSD routers. You use FreeBSD as router, not server. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 09:16:56 2004 Return-Path: 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 7171616A4CE; Tue, 14 Dec 2004 09:16:56 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE9443D66; Tue, 14 Dec 2004 09:16:55 +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 iBE9Grau063136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 12:16:54 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBE9GrIo044505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 12:16:53 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBE9Gq2D044504; Tue, 14 Dec 2004 12:16:53 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 12:16:52 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041214091652.GE42820@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> <41BE0E89.AE21445@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BE0E89.AE21445@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: mlaier@freebsd.org cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 09:16:56 -0000 On Mon, Dec 13, 2004 at 10:50:01PM +0100, Andre Oppermann wrote: A> > (Now I speak only about ipfw. But other filters can be used in same A> > manner with a very small changes.) A> > A> > We have list of rules defined in struct ip_fw_chain. At this moment A> > we have only one instance of it - a global variable layer3_chain. A> > What I'm going to do: A> > 1) adding possibility to add new chains and editing them. A> > 2) adding possibility to run ipfw_chk() against a chain other than A> > layer3_chain. A> > 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk() A> > on different chains. Supply chain identifier in void arg. Edit A> > ipfw_hook() so that it can register ipfw as a pfil, but with A> > chain different to layer3_chain. A> A> This is what I don't get. You can register only once with pfil. in ipfw_hook(): pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet); pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet); smth like: s/pfh_inet/ifp->pfil_head/ No API change. A> > 4) add possibility to register a pfil_head for an interface. Once the A> > pfil_head is registered, administrator can call ipfw_hook() on A> > it, and hook ipfw chain to this pfil_head, either in or out. A> > 5) In ip_input()/ip_output() check if interface has pfil_head A> > associated with it. If it does pfil_run_hooks on it. A> A> You are going to change the pfil API. This is not neccessary. pfil A> passes the ifp to the hook, this is sufficient. Yes. It is possible to do this on level of ipfw. But I'd prefer to do this on level of pfil. This will give possibility to run pf on one interface and ipfw on other. (tools, not policy). A> > Important points: A> > 1. No API breakage in PFIL, at least I don't see any problems now. A> A> But Max and me see problems. The API does not break but it is different. A> We don't want it to be different in such a way. AFAIU, the pfil API is designed to attach a list of generic filters to a any place you want. If you say that pfil is designed to perform filtering in ip_{in,out}put(), this sounds strange. A> > 2. No conflicts with current filtering. Interface filters can happily A> > coexist with global ones. A> A> You haven't talked about the presentation interface towards the user. A> This is where everything has to start. How would the ipfw syntax look A> like? Provide some examples please. ipfw syntax will be 100% backward compatible. The following keywords would be added: ipfw chain list - list configured chains ipfw chain add | delete - delete, remove chain ipfw chain _number_ [common rule definition] - add/delete rules to non-default chain It would be possible to attach chains to interfaces specifing also direction. It will be done with ifconfig, or a specific utility (not yet decided). A> The problem we have is that you have a specific solution in mind without A> adequatly stating the problem first. Because then we would sit down and A> work out what the best way is to implement it. So far Max and I do not A> agree with you on the your stated ideas to solve this. The fact that Juniper and Cisco (and I suspect other router vendors) use this technique, proves that it is handy for routers. I'm sure many sysadmins will agree at this point. Users, not developers. The fact that one have written some IP packet filter does not mean that he knows everything about its day to day usage. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 09:23:18 2004 Return-Path: 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 686DC16A4CE for ; Tue, 14 Dec 2004 09:23:18 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id CF4F743D4C for ; Tue, 14 Dec 2004 09:23:16 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 7573 invoked from network); 14 Dec 2004 09:23:10 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.84) by gandalf.online.bg with SMTP; 14 Dec 2004 09:23:10 -0000 Received: (qmail 63175 invoked by uid 1000); 14 Dec 2004 09:23:13 -0000 Date: Tue, 14 Dec 2004 11:23:13 +0200 From: Peter Pentchev To: Gleb Smirnoff Message-ID: <20041214092313.GD3183@straylight.m.ringlet.net> References: <20041214080549.GC3183@straylight.m.ringlet.net> <20041214085310.GC42820@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LTeJQqWS0MN7I/qa" Content-Disposition: inline In-Reply-To: <20041214085310.GC42820@cell.sick.ru> User-Agent: Mutt/1.5.6i cc: Darren Reed cc: freebsd-net@freebsd.org Subject: Re: IPFilter, mpd/Netgraph problems on RELENG_4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 09:23:18 -0000 --LTeJQqWS0MN7I/qa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 14, 2004 at 11:53:10AM +0300, Gleb Smirnoff wrote: > On Tue, Dec 14, 2004 at 10:05:50AM +0200, Peter Pentchev wrote: > P> I am seeing a lot of ICMP Must Fragment packets with incorrect ICMP > P> checksums on a RELENG_4 box which holds up 40-60 PPTP (mpd/Netgraph) V= PN > P> connections at any given time. The peer understandably ignores the IC= MP > P> packet with a bad checksum and never fragments the offending TCP packe= t, > P> effectively killing the connection after a while. > P>=20 > P> A major point is that I'm only seeing them on the interfaces NAT'ed by > P> ipnat. Is anybody else having trouble with ICMP checkums with IPFilter > P> 3.4.35 on a reasonably recent RELENG_4 box? > P>=20 > P> FreeBSD unnamed 4.10-STABLE FreeBSD 4.10-STABLE #1: Thu Dec 2 10:31:16= EET 2004 root@unnamed:/usr/obj/usr/src-bsd/4.0S/src/sys/UNNAMED i386 > P>=20 > P> drwxr-xr-x 2 root wheel 512 Dec 2 11:43 /var/db/pkg/mpd-3.18_2 >=20 > Peter, >=20 > does the problem disappear if you turn ipfilter off, and run natd on th= is > interface? it is not clear from your mail. We haven't actually tried it with natd. This is one of the possibilities that we may certainly try, though. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. --LTeJQqWS0MN7I/qa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBvrEB7Ri2jRYZRVMRAj8oAKCX6oNOVK9nyMcH1QN88LgcCCd6tACdF8Av N77F1v6FMJ7hVWuQiaYDHO4= =SbiD -----END PGP SIGNATURE----- --LTeJQqWS0MN7I/qa-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 09:40:07 2004 Return-Path: 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 40AE816A4CE; Tue, 14 Dec 2004 09:40:07 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A75A143D3F; Tue, 14 Dec 2004 09:40:06 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1Ce9A3-0001jv-P1; Tue, 14 Dec 2004 12:40:03 +0300 From: Vladimir Grebenschikov To: Gleb Smirnoff In-Reply-To: <20041214085123.GB42820@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Dec 2004 12:40:03 +0300 Message-Id: <1103017203.1060.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 09:40:07 -0000 =F7 =D7=D4, 14/12/2004 =D7 11:51 +0300, Gleb Smirnoff =D0=C9=DB=C5=D4: > I know this. We have a well commented firewall scripts, we store them at = RCS, > we do many things to make our life easier. But my practice (and my colleg= ues) > shows that per interface filters are easier to understand and maintain wh= en > number of interfaces grows up to 20 and more, and they all are logically > different - clients, servers, DMZs, hardware, nated networks, etc. >=20 > Again, this feature is not for all. This is for people who build complica= ted > routers on FreeBSD. It is not going to hurt standard host setups. Frankly speaking, I think ppl who runs real-life router with firewall on fbsd will vote for this feature by both hands. I sometime, some years ago I had freebsd router with near to 100 interfaces (mostly VLANs and FrameRelay customers connections, and about 10 physical media interfaces). This router transfers some thousands packets per second. It was real trouble to rearrange ipfw table with large (very large) number of jumps (especially in case when some number range was exceeded and renumbering required). Also most of router interrupt time was spent in going through client multiplexer part of ipfw ruleset. Gleb, please do the feature. Why we do not avoid bottlenecks where they can be avoided ?=20 With that feature we can select right rules for specific interface without do linear search by ruleset.=20 Do we what FreeBSD be used on large scale of setups or we have think targeting ?=20 -- off-topic -- Days ago FreeBSD was only OS flexible and stable enough to be use in complex, customized network environments, but now-days it is not so :(, and you know why. -- off-topic -- (not for flame or advocacy, just emotion) --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 09:56:06 2004 Return-Path: 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 3CC5F16A4CE; Tue, 14 Dec 2004 09:56:06 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C45B943D1F; Tue, 14 Dec 2004 09:56:05 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBE9u4LJ075240; Tue, 14 Dec 2004 01:56:04 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBE9u4f6075239; Tue, 14 Dec 2004 01:56:04 -0800 (PST) (envelope-from rizzo) Date: Tue, 14 Dec 2004 01:56:03 -0800 From: Luigi Rizzo To: Gleb Smirnoff , Max Laier , freebsd-net@freebsd.org Message-ID: <20041214015603.A75019@xorpc.icir.org> References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041214085123.GB42820@cell.sick.ru>; from glebius@freebsd.org on Tue, Dec 14, 2004 at 11:51:23AM +0300 Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 09:56:06 -0000 On Tue, Dec 14, 2004 at 11:51:23AM +0300, Gleb Smirnoff wrote: ... > Again, this feature is not for all. This is for people who build complicated > routers on FreeBSD. It is not going to hurt standard host setups. Trying to summarise the discussion with a hopefully unbiased position: As i also said before, i agree that when the number of interfaces becomes large, managing ipfw lists can become difficult (though i see no way your technique can help without the assistance of scripts generating the actual lists for each interface making sure that the 'common' checks are in sync, etc.) Implementationwise, the kernel side is evidently trivial as the original code already supports the idea of multiple chains. All you need is to extend the struct ifnet with a pointer to the chain, or use some other trick (e.g. going through ifindex) to quickly associate a chain to the input (and possibly output) interface. If i understand well (and this is an option i had not considered myself, but sounds very reasonable and is the key idea that convinced me!) you are going to make the feature mutually exclusive with the old firewall -- either you use the global chain for all interfaces, or you use the private chains. It remains open what to do if you have registered a private chain only on a few interfaces, but that's just a matter of defining a reasonable policy, e.g. fallback to the global chain or something like that. The additional iper-packet cost is effectively zero -- instead of accessing the chain through a global variable, you access it through a field of struct ifnet, which is already accessed a zillion times in the processing of the packet. In userland, it is equally trivial to add a new ipfw flag to select the interface/direction on which the command should operate. As a safety measure, I would recommend to dump, in ipfw's output, a warning message (disabled through another flag) all times the configuration has something inconsistent (e.g. some but not all interfaces have private chains registered, etc.) Once you do the above, i don't see how users could be negatively affected by the change, either in performance or ease of use. I believe that one still needs the assistance of scripts to generate the private chains of rules making sure that they are all in sync etc., but this is a problem that exists for other packet filters as well. So, from my point of view, i say go ahead, post a short description of the feature and usage examples if mine above is not what you have in mind, and that should convince those who are reluctant too. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 10:07:23 2004 Return-Path: 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 D14B416A4D0 for ; Tue, 14 Dec 2004 10:07:23 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C1C243D4C for ; Tue, 14 Dec 2004 10:07:23 +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 iBEA7LXQ064394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 13:07:21 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBEA7KPh045025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 13:07:21 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBEA7KaA045024; Tue, 14 Dec 2004 13:07:20 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 13:07:20 +0300 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20041214100720.GA44948@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Luigi Rizzo , Max Laier , freebsd-net@freebsd.org References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041214015603.A75019@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 10:07:24 -0000 On Tue, Dec 14, 2004 at 01:56:03AM -0800, Luigi Rizzo wrote: L> > Again, this feature is not for all. This is for people who build complicated L> > routers on FreeBSD. It is not going to hurt standard host setups. L> L> Trying to summarise the discussion with a hopefully unbiased position: L> L> As i also said before, i agree that when the number of interfaces L> becomes large, managing ipfw lists can become difficult (though i L> see no way your technique can help without the assistance of scripts L> generating the actual lists for each interface making sure that the L> 'common' checks are in sync, etc.) L> L> Implementationwise, the kernel side is evidently trivial as the L> original code already supports the idea of multiple chains. All L> you need is to extend the struct ifnet with a pointer to the chain, L> or use some other trick (e.g. going through ifindex) to quickly L> associate a chain to the input (and possibly output) interface. Yes, except that it points not to a chain but to pfil_hook_head, so that the feature can be later extended to other filtering facilities. L> If i understand well (and this is an option i had not considered L> myself, but sounds very reasonable and is the key idea that L> convinced me!) you are going to make the feature L> mutually exclusive with the old firewall -- either you use L> the global chain for all interfaces, or you use the private L> chains. It remains open what to do if you have registered a L> private chain only on a few interfaces, but that's just a matter L> of defining a reasonable policy, e.g. fallback to the global chain L> or something like that. They are suggested to be mutually exclusive. But administrator can decide to do filtering on per interface basis and global filtering, too. We are not going to deny this, if someone needs this. In this case it will be filtered in this order: input interface 'in' filter global filter called from ip_input global filter called from ip_output output interface 'out' filter L> The additional iper-packet cost is effectively zero -- instead of L> accessing the chain through a global variable, you access it through L> a field of struct ifnet, which is already accessed a zillion times L> in the processing of the packet. L> L> In userland, it is equally trivial to add a new ipfw flag to select L> the interface/direction on which the command should operate. L> As a safety measure, I would recommend to dump, in ipfw's output, L> a warning message (disabled through another flag) all times L> the configuration has something inconsistent (e.g. some but not all L> interfaces have private chains registered, etc.) Filtering on all interfaces is not mandatory. L> Once you do the above, i don't see how users could be negatively L> affected by the change, either in performance or ease of use. L> L> I believe that one still needs the assistance of scripts to generate L> the private chains of rules making sure that they are all in sync etc., but L> this is a problem that exists for other packet filters as well. L> L> So, from my point of view, i say go ahead, post a short L> description of the feature and usage examples if mine above is L> not what you have in mind, and that should convince those who L> are reluctant too. Sure. I'm going to document this well. Several examples in /usr/share/examples is minimum. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 12:47:36 2004 Return-Path: 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 41C5116A4CE for ; Tue, 14 Dec 2004 12:47:36 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65C9743D3F for ; Tue, 14 Dec 2004 12:47:35 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26304 invoked from network); 14 Dec 2004 12:36:28 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 12:36:28 -0000 Message-ID: <41BEE0E7.BD2316EB@freebsd.org> Date: Tue, 14 Dec 2004 13:47:35 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <20041213124051.GB32719@cell.sick.ru> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 12:47:36 -0000 Luigi Rizzo wrote: > > On Tue, Dec 14, 2004 at 11:51:23AM +0300, Gleb Smirnoff wrote: > ... > > Again, this feature is not for all. This is for people who build complicated > > routers on FreeBSD. It is not going to hurt standard host setups. > > Trying to summarise the discussion with a hopefully unbiased position: > > As i also said before, i agree that when the number of interfaces > becomes large, managing ipfw lists can become difficult (though i > see no way your technique can help without the assistance of scripts > generating the actual lists for each interface making sure that the > 'common' checks are in sync, etc.) This is one of the difficulties of per-interface ACL's like in Cisco and Juniper. On the other hand the global-only approach has it's own difficulties with larger number of interfaces. > Implementationwise, the kernel side is evidently trivial as the > original code already supports the idea of multiple chains. All > you need is to extend the struct ifnet with a pointer to the chain, > or use some other trick (e.g. going through ifindex) to quickly > associate a chain to the input (and possibly output) interface. Nonononononononononononononononononononononono. There MUST NOT be any firewall specific pointers or other information in struct ifnet or any other non-firewall private part of the kernel. Otherwise the entire independence we've gained with the nice and clean PFIL_HOOKS API goes down the drain. This MUST NOT happen again. The whole idea of the PFIL_HOOKS is to have independend and loadable firewall modules with different approaches, internal designs and so on. For example a way Gleb can get his way without any bickering from us is by creating his own gleb-firewall module using the PFIL_HOOKS API and put it into the ports tree for easy access, provided he doesn't modify the PFIL_HOOKS API (which he doesn't have to). > If i understand well (and this is an option i had not considered > myself, but sounds very reasonable and is the key idea that > convinced me!) you are going to make the feature > mutually exclusive with the old firewall -- either you use > the global chain for all interfaces, or you use the private > chains. It remains open what to do if you have registered a > private chain only on a few interfaces, but that's just a matter > of defining a reasonable policy, e.g. fallback to the global chain > or something like that. Whatever. This is private to the firewall implementation of his choice. > The additional iper-packet cost is effectively zero -- instead of > accessing the chain through a global variable, you access it through > a field of struct ifnet, which is already accessed a zillion times > in the processing of the packet. This is broken by design. This way we're back in the FreeBSD 4.x days of hacking the entire IP stack for one particular 'feature'. In those days there was no direct alternative but today we have PFIL_HOOKS and we MUST NOT fall back into old habits of hacking the world around a very particular and specific subset of functionality and thereby making the maintainance of the whole thing harder again. > In userland, it is equally trivial to add a new ipfw flag to select > the interface/direction on which the command should operate. > As a safety measure, I would recommend to dump, in ipfw's output, > a warning message (disabled through another flag) all times > the configuration has something inconsistent (e.g. some but not all > interfaces have private chains registered, etc.) > > Once you do the above, i don't see how users could be negatively > affected by the change, either in performance or ease of use. Maybe not the users but the developers are. I will curse the hell out of anyone f*cking up the stack that way. > I believe that one still needs the assistance of scripts to generate > the private chains of rules making sure that they are all in sync etc., but > this is a problem that exists for other packet filters as well. > > So, from my point of view, i say go ahead, post a short > description of the feature and usage examples if mine above is > not what you have in mind, and that should convince those who > are reluctant too. I'm all for discussing the merits of having per-interface firewall rules. Actually I agree that this is a nice thing to have on boxes with large number of interfaces. There are multiple way of getting there and we have nowhere near any kind of agreement on that. And this is where we have get at first before any code is implemented. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 12:54:26 2004 Return-Path: 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 3F38E16A4D0 for ; Tue, 14 Dec 2004 12:54:26 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BEF243D3F for ; Tue, 14 Dec 2004 12:54:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26379 invoked from network); 14 Dec 2004 12:43:17 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 12:43:17 -0000 Message-ID: <41BEE281.607DD0A8@freebsd.org> Date: Tue, 14 Dec 2004 13:54:25 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vova@fbsd.ru References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 12:54:26 -0000 Vladimir Grebenschikov wrote: > > ч ЧФ, 14/12/2004 Ч 11:51 +0300, Gleb Smirnoff РЙЫЕФ: > > > I know this. We have a well commented firewall scripts, we store them at RCS, > > we do many things to make our life easier. But my practice (and my collegues) > > shows that per interface filters are easier to understand and maintain when > > number of interfaces grows up to 20 and more, and they all are logically > > different - clients, servers, DMZs, hardware, nated networks, etc. > > > > Again, this feature is not for all. This is for people who build complicated > > routers on FreeBSD. It is not going to hurt standard host setups. > > Frankly speaking, I think ppl who runs real-life router with firewall on > fbsd will vote for this feature by both hands. > > I sometime, some years ago I had freebsd router with near to 100 > interfaces (mostly VLANs and FrameRelay customers connections, and > about 10 physical media interfaces). This router transfers some > thousands packets per second. It was real trouble to rearrange ipfw > table with large (very large) number of jumps (especially in case when > some number range was exceeded and renumbering required). Also most of > router interrupt time was spent in going through client multiplexer part > of ipfw ruleset. > > Gleb, please do the feature. > > Why we do not avoid bottlenecks where they can be avoided ? > With that feature we can select right rules for specific interface > without do linear search by ruleset. It's about HOW to implement it. I think the ways proposed so far are hackish, too complex and outside of our framework which was very well designed and allows this kind of feature without any of the hacks and extentions discussed here. We have to properly DESIGN these feature instead of just hacking them in. > Do we what FreeBSD be used on large scale of setups or we have think > targeting ? As long as there is a sufficient large base we are not opposed to it. What we are opposed at is tradeoffs which favor one particular minority special interest over the general average interest set. > -- off-topic -- > Days ago FreeBSD was only OS flexible and stable enough to be use in > complex, customized network environments, but now-days it is not so :(, > and you know why. > -- off-topic -- (not for flame or advocacy, just emotion) No, I don't know why and this isn't helping any. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 13:05:19 2004 Return-Path: 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 ED14516A4CF for ; Tue, 14 Dec 2004 13:05:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06C3F43D54 for ; Tue, 14 Dec 2004 13:05:19 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26457 invoked from network); 14 Dec 2004 12:54:11 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 12:54:11 -0000 Message-ID: <41BEE50E.6AA4FA4@freebsd.org> Date: Tue, 14 Dec 2004 14:05:18 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> <41BE0E89.AE21445@freebsd.org> <20041214091652.GE42820@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mlaier@freebsd.org cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 13:05:20 -0000 Gleb Smirnoff wrote: > > On Mon, Dec 13, 2004 at 10:50:01PM +0100, Andre Oppermann wrote: > A> > (Now I speak only about ipfw. But other filters can be used in same > A> > manner with a very small changes.) > A> > > A> > We have list of rules defined in struct ip_fw_chain. At this moment > A> > we have only one instance of it - a global variable layer3_chain. > A> > What I'm going to do: > A> > 1) adding possibility to add new chains and editing them. > A> > 2) adding possibility to run ipfw_chk() against a chain other than > A> > layer3_chain. > A> > 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk() > A> > on different chains. Supply chain identifier in void arg. Edit > A> > ipfw_hook() so that it can register ipfw as a pfil, but with > A> > chain different to layer3_chain. > A> > A> This is what I don't get. You can register only once with pfil. > > in ipfw_hook(): > > pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet); > pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet); > > smth like: s/pfh_inet/ifp->pfil_head/ Not neccessary. You get the ifp when pfil_run_hooks() is called and you can do the per-interface multiplexing just as simple in your firewall package. > No API change. Sure it is. Not directly with PFIL_HOOKS itself but in the way it is hooked into the kernel and it is called. You want to pass redundant information. > A> > 4) add possibility to register a pfil_head for an interface. Once the > A> > pfil_head is registered, administrator can call ipfw_hook() on > A> > it, and hook ipfw chain to this pfil_head, either in or out. > A> > 5) In ip_input()/ip_output() check if interface has pfil_head > A> > associated with it. If it does pfil_run_hooks on it. > A> > A> You are going to change the pfil API. This is not neccessary. pfil > A> passes the ifp to the hook, this is sufficient. > > Yes. It is possible to do this on level of ipfw. But I'd prefer to do > this on level of pfil. This will give possibility to run pf on one > interface and ipfw on other. (tools, not policy). But any firewall package needs to be modified to be able to deal with this. Tools, not policy does not apply in this context because we are not going to do an policy decision here. > A> > Important points: > A> > 1. No API breakage in PFIL, at least I don't see any problems now. > A> > A> But Max and me see problems. The API does not break but it is different. > A> We don't want it to be different in such a way. > > AFAIU, the pfil API is designed to attach a list of generic filters to > a any place you want. If you say that pfil is designed to perform filtering in > ip_{in,out}put(), this sounds strange. No. PFIL_HOOKS can hook into two directions (in and out) for each protocol class (INET, INET6 and so on). > A> > 2. No conflicts with current filtering. Interface filters can happily > A> > coexist with global ones. > A> > A> You haven't talked about the presentation interface towards the user. > A> This is where everything has to start. How would the ipfw syntax look > A> like? Provide some examples please. > > ipfw syntax will be 100% backward compatible. The following keywords would > be added: > > ipfw chain list - list configured chains > ipfw chain add | delete - delete, remove chain > ipfw chain _number_ [common rule definition] - add/delete rules to > non-default chain > > It would be possible to attach chains to interfaces specifing also > direction. It will be done with ifconfig, or a specific utility (not yet > decided). Why don't you specify the interface directly in the syntax? That would be more in line with ease of use instead of having yet another logical indirection? ipfw fxp0 add permit ip from any to any > A> The problem we have is that you have a specific solution in mind without > A> adequatly stating the problem first. Because then we would sit down and > A> work out what the best way is to implement it. So far Max and I do not > A> agree with you on the your stated ideas to solve this. > > The fact that Juniper and Cisco (and I suspect other router vendors) use this > technique, proves that it is handy for routers. I'm sure many sysadmins will > agree at this point. Users, not developers. The fact that one have written > some IP packet filter does not mean that he knows everything about its day > to day usage. Oh, come on. We are arguing not about having per-interface firewalls but about your implementation approach to it. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 13:07:16 2004 Return-Path: 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 C20D316A4CE; Tue, 14 Dec 2004 13:07:16 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C578743D49; Tue, 14 Dec 2004 13:07:15 +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 iBED7DJB068984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 16:07:13 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBED7C1p046526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 16:07:12 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBED7CLp046525; Tue, 14 Dec 2004 16:07:12 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 16:07:12 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041214130712.GA46386@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andre Oppermann , Luigi Rizzo , Max Laier , freebsd-net@freebsd.org References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BEE0E7.BD2316EB@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: Luigi Rizzo cc: freebsd-net@freebsd.org cc: Max Laier Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 13:07:16 -0000 On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: A> > Implementationwise, the kernel side is evidently trivial as the A> > original code already supports the idea of multiple chains. All A> > you need is to extend the struct ifnet with a pointer to the chain, A> > or use some other trick (e.g. going through ifindex) to quickly A> > associate a chain to the input (and possibly output) interface. A> A> Nonononononononononononononononononononononono. A> A> There MUST NOT be any firewall specific pointers or other information A> in struct ifnet or any other non-firewall private part of the kernel. A> Otherwise the entire independence we've gained with the nice and clean A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again. A> A> The whole idea of the PFIL_HOOKS is to have independend and loadable A> firewall modules with different approaches, internal designs and so A> on. The whole idea of PFIL_HOOKS is to have independend and loadable firewall modules, which can be attached to different parts of kernel! There is no such requirement that, pfil hooks MUST be sticked to a single entry point in ip_input() and ip_output(). Pfils attached to interface belong to interface, and thus should be stored in struct ifnet. This is the way it is done in per-interface filters. A> For example a way Gleb can get his way without any bickering from us A> is by creating his own gleb-firewall module using the PFIL_HOOKS API A> and put it into the ports tree for easy access, provided he doesn't A> modify the PFIL_HOOKS API (which he doesn't have to). I am not going to create a new firewall or change PFIL_HOOKS. I'm going to attach *the existing* pfil_hooks to a different place, to perform filtering with *existing* firewalls. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 13:16:54 2004 Return-Path: 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 CB71C16A4CF for ; Tue, 14 Dec 2004 13:16:54 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E18DF43D41 for ; Tue, 14 Dec 2004 13:16:53 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26579 invoked from network); 14 Dec 2004 13:05:46 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 13:05:46 -0000 Message-ID: <41BEE7C5.CA51ED08@freebsd.org> Date: Tue, 14 Dec 2004 14:16:53 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> <20041214130712.GA46386@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org cc: Max Laier Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 13:16:54 -0000 Gleb Smirnoff wrote: > > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > A> > Implementationwise, the kernel side is evidently trivial as the > A> > original code already supports the idea of multiple chains. All > A> > you need is to extend the struct ifnet with a pointer to the chain, > A> > or use some other trick (e.g. going through ifindex) to quickly > A> > associate a chain to the input (and possibly output) interface. > A> > A> Nonononononononononononononononononononononono. > A> > A> There MUST NOT be any firewall specific pointers or other information > A> in struct ifnet or any other non-firewall private part of the kernel. > A> Otherwise the entire independence we've gained with the nice and clean > A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again. > A> > A> The whole idea of the PFIL_HOOKS is to have independend and loadable > A> firewall modules with different approaches, internal designs and so > A> on. > > The whole idea of PFIL_HOOKS is to have independend and loadable firewall > modules, which can be attached to different parts of kernel! There is no > such requirement that, pfil hooks MUST be sticked to a single entry point > in ip_input() and ip_output(). PFIL_HOOKS is meant to be once on input and output per protocol and not per interface. That is the reason why there is the interface pointer in the argument list. > Pfils attached to interface belong to interface, and thus should be stored > in struct ifnet. This is the way it is done in per-interface filters. Again, you are changing the way PFIL_HOOKS are called. > A> For example a way Gleb can get his way without any bickering from us > A> is by creating his own gleb-firewall module using the PFIL_HOOKS API > A> and put it into the ports tree for easy access, provided he doesn't > A> modify the PFIL_HOOKS API (which he doesn't have to). > > I am not going to create a new firewall or change PFIL_HOOKS. I'm going > to attach *the existing* pfil_hooks to a different place, to perform > filtering with *existing* firewalls. The existing firewalls need to be modified anyway to be able to deal with per-interface hooks. They are not made for it. This makes your argument moot. But please hold on, I'm writing an email with a different proposed approach. Let's continue the discussion when all have read it. Give me a few minutes. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 13:20:35 2004 Return-Path: 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 5A54016A4CE; Tue, 14 Dec 2004 13:20:35 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A53C43D48; Tue, 14 Dec 2004 13:20:34 +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 iBEDKWiI069253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Dec 2004 16:20:33 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBEDKWta046619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2004 16:20:32 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBEDKWme046618; Tue, 14 Dec 2004 16:20:32 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2004 16:20:31 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041214132031.GB46386@cell.sick.ru> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> <41BE0E89.AE21445@freebsd.org> <20041214091652.GE42820@cell.sick.ru> <41BEE50E.6AA4FA4@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BEE50E.6AA4FA4@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: mlaier@freebsd.org cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 13:20:35 -0000 On Tue, Dec 14, 2004 at 02:05:18PM +0100, Andre Oppermann wrote: A> > A> > (Now I speak only about ipfw. But other filters can be used in same A> > A> > manner with a very small changes.) A> > A> > A> > A> > We have list of rules defined in struct ip_fw_chain. At this moment A> > A> > we have only one instance of it - a global variable layer3_chain. A> > A> > What I'm going to do: A> > A> > 1) adding possibility to add new chains and editing them. A> > A> > 2) adding possibility to run ipfw_chk() against a chain other than A> > A> > layer3_chain. A> > A> > 3) Edit ip_fw_check_{in,out}, so that it can call ipfw_chk() A> > A> > on different chains. Supply chain identifier in void arg. Edit A> > A> > ipfw_hook() so that it can register ipfw as a pfil, but with A> > A> > chain different to layer3_chain. A> > A> A> > A> This is what I don't get. You can register only once with pfil. A> > A> > in ipfw_hook(): A> > A> > pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet); A> > pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet); A> > A> > smth like: s/pfh_inet/ifp->pfil_head/ A> A> Not neccessary. You get the ifp when pfil_run_hooks() is called and you A> can do the per-interface multiplexing just as simple in your firewall A> package. I do not want to enter any filtering related functions on an interface where no filtering is performed. I think this argument is heavy for such fan of perfect design as you are. A> > No API change. A> A> Sure it is. Not directly with PFIL_HOOKS itself but in the way it is A> hooked into the kernel and it is called. You want to pass redundant A> information. Is it going to hurt you that ipfw_hook() can accept *optional* parameter which can tell it to hook to non-default pfil_hook? A> > A> > 4) add possibility to register a pfil_head for an interface. Once the A> > A> > pfil_head is registered, administrator can call ipfw_hook() on A> > A> > it, and hook ipfw chain to this pfil_head, either in or out. A> > A> > 5) In ip_input()/ip_output() check if interface has pfil_head A> > A> > associated with it. If it does pfil_run_hooks on it. A> > A> A> > A> You are going to change the pfil API. This is not neccessary. pfil A> > A> passes the ifp to the hook, this is sufficient. A> > A> > Yes. It is possible to do this on level of ipfw. But I'd prefer to do A> > this on level of pfil. This will give possibility to run pf on one A> > interface and ipfw on other. (tools, not policy). A> A> But any firewall package needs to be modified to be able to deal with this. Yes. If some developer likes idea of per-interface filters and prefers smth other than ipfw, he can add support for his favorite filter. A> Tools, not policy does not apply in this context because we are not going A> to do an policy decision here. We can give people possibility to attach ipfw chains to interfaces, we can give possibility to attach any pfil-compatible filters. The second one is less strict. A> > A> > Important points: A> > A> > 1. No API breakage in PFIL, at least I don't see any problems now. A> > A> A> > A> But Max and me see problems. The API does not break but it is different. A> > A> We don't want it to be different in such a way. A> > A> > AFAIU, the pfil API is designed to attach a list of generic filters to A> > a any place you want. If you say that pfil is designed to perform filtering in A> > ip_{in,out}put(), this sounds strange. A> A> No. PFIL_HOOKS can hook into two directions (in and out) for each protocol A> class (INET, INET6 and so on). I'm trying to show that PFIL_HOOKS are designed not solely for filtering on protocol level. They can be utilized in any code which deals with mbufs. A> > A> > 2. No conflicts with current filtering. Interface filters can happily A> > A> > coexist with global ones. A> > A> A> > A> You haven't talked about the presentation interface towards the user. A> > A> This is where everything has to start. How would the ipfw syntax look A> > A> like? Provide some examples please. A> > A> > ipfw syntax will be 100% backward compatible. The following keywords would A> > be added: A> > A> > ipfw chain list - list configured chains A> > ipfw chain add | delete - delete, remove chain A> > ipfw chain _number_ [common rule definition] - add/delete rules to A> > non-default chain A> > A> > It would be possible to attach chains to interfaces specifing also A> > direction. It will be done with ifconfig, or a specific utility (not yet A> > decided). A> A> Why don't you specify the interface directly in the syntax? That would be A> more in line with ease of use instead of having yet another logical A> indirection? A> A> ipfw fxp0 add permit ip from any to any Because one chain may be used for several interfaces. One can be used for ng_pfil node. One can be not used at all, but it is hanging there, so that it can replace the one used by interface (this is what bms requested for XORP). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:03:28 2004 Return-Path: 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 E912C16A4CE for ; Tue, 14 Dec 2004 14:03:28 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27DA443D46 for ; Tue, 14 Dec 2004 14:03:28 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26864 invoked from network); 14 Dec 2004 13:52:19 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 13:52:19 -0000 Message-ID: <41BEF2AF.470F9079@freebsd.org> Date: Tue, 14 Dec 2004 15:03:27 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:03:29 -0000 Let's take a high level view of the issue at hand and the consider some alternative approaches to the situation. Current situation: a1. There is a need to have per-interface specific firewall rules. a2. We have multiple firewall packages which have multiple way to specify interface specific rules. a3. With large numbers of interface specific rules the rulesets get complex and hard to manage. a4. This seems to be mainly a problem with ipfw and it's skipto actions. Request: b1. Users request a less complicated way of doing interface specific firewall rules. Analysis: c1. This is primarily a USER interface/syntax/semantics issue. c2. The different user interface approaches of the different firewall packages we have require different changes to their USER interfaces to make it easier for per-interface rule sets. c3. The firewall packages we have can only deal with one global rule set per protocol family and direction currently. They can't be loaded multiple times and can't have multiple rule set heads (only one entry point). Implementation approaches: d1. The PFIL_HOOKS API has one hook per direction per protocol and passes the interface information to the firewall package. d2. Should the PFIL_HOOKS API be changed and be per interface instead of per protocol? All firewall packages need to be modified and we are no longer compatible with the PFIL_HOOKS API. d3. Should the interface specific rules sets be per firewall package in the way that best suits the package? No kernel API is changed. d4. What is the user interface syntax and semantics for each firewall package that someone wants to be modified? Provide examples for those you are interested in. d5. Should it be a replica of Cisco|Juniper approaches or can we do better in syntax or semantics? Think outside of the box. Lets continue the discussion from here. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:03:42 2004 Return-Path: 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 13FBB16A4D9; Tue, 14 Dec 2004 14:03:42 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A312943D1D; Tue, 14 Dec 2004 14:03:41 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBEE3fiD077817; Tue, 14 Dec 2004 06:03:41 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBEE3fiC077816; Tue, 14 Dec 2004 06:03:41 -0800 (PST) (envelope-from rizzo) Date: Tue, 14 Dec 2004 06:03:41 -0800 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20041214060341.A77720@xorpc.icir.org> References: <20041213124051.GB32719@cell.sick.ru> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <41BEE0E7.BD2316EB@freebsd.org>; from andre@freebsd.org on Tue, Dec 14, 2004 at 01:47:35PM +0100 cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:03:42 -0000 On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: ... > > Implementationwise, the kernel side is evidently trivial as the > > original code already supports the idea of multiple chains. All > > you need is to extend the struct ifnet with a pointer to the chain, > > or use some other trick (e.g. going through ifindex) to quickly > > associate a chain to the input (and possibly output) interface. > > Nonononononononononononononononononononononono. andre you need to cool down a bit! i said "use some other trick" exactly to avoid changing the struct ifnet. All i meant to say is that we want a unique key, possibly in a small namespace, to quickly locate the per-if private firewall info. How the key is used is not a business of the rest of the kernel. But of course if it is an index in a smallish array (such as ifindex) the thing is fast and clean. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:13:22 2004 Return-Path: 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 F40D116A4CE; Tue, 14 Dec 2004 14:13:21 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D4A443D31; Tue, 14 Dec 2004 14:13:21 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 1B648651FA; Tue, 14 Dec 2004 14:13:19 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14733-04-4; Tue, 14 Dec 2004 14:13:18 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 0C96D651F7; Tue, 14 Dec 2004 14:13:14 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 280896710; Tue, 14 Dec 2004 06:13:08 -0800 (PST) Date: Tue, 14 Dec 2004 06:13:07 -0800 From: Bruce M Simpson To: Andre Oppermann Message-ID: <20041214141307.GA684@empiric.icir.org> Mail-Followup-To: Andre Oppermann , freebsd-net@freebsd.org References: <41BEF2AF.470F9079@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <41BEF2AF.470F9079@freebsd.org> cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:13:22 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote: > Let's take a high level view of the issue at hand and the consider > some alternative approaches to the situation. [snip] I'm wrapping up in Berkeley for the holidays, but I wanted to drop my 2c into this discussion. What I'm really missing in IPFW is the ability to maintain one or more 'shadow rulesets'. These rulesets may not be the active rulesets, but I can manipulate them as tables, independently of the active ruleset(s), push rules into them, flush them, and then atomically switch them to be the active ruleset, using a single syscall. IPF and PF have such functionality, IPFW does not. The lack of a documented ABI/API for access to IPFW by applications other than ipfw(8) is something which I'm leaving out of the picture for the moment. I don't really consider using 'skipto' and separate sections of rule index number space a valid answer here, because we should have the ability to independently flush each ruleset. When extended to stateful rules (I am talking here purely about the simple stateless packet filter case), this comes in even more useful. Regards, BMS --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBvvTzueUpAYYNtTsRAm4PAJ9E8pxkzNI6iq5l3XNeEvpjlHdjRACgn3q0 vZ89qYbXoYIc3wwXGpdvdOA= =fdcw -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:17:54 2004 Return-Path: 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 EBA0216A4CE; Tue, 14 Dec 2004 14:17:54 +0000 (GMT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5393B43D39; Tue, 14 Dec 2004 14:17:54 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 0CCC511CEE; Tue, 14 Dec 2004 15:17:53 +0100 (CET) Date: Tue, 14 Dec 2004 15:17:52 +0100 From: "Simon L. Nielsen" To: freebsd-net@freebsd.org Message-ID: <20041214141752.GC782@zaphod.nitro.dk> References: <41BEF2AF.470F9079@freebsd.org> <20041214141307.GA684@empiric.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Content-Disposition: inline In-Reply-To: <20041214141307.GA684@empiric.icir.org> User-Agent: Mutt/1.5.6i cc: Andre Oppermann Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:17:55 -0000 --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.12.14 06:13:07 -0800, Bruce M Simpson wrote: > What I'm really missing in IPFW is the ability to maintain one or more > 'shadow rulesets'. These rulesets may not be the active rulesets, but > I can manipulate them as tables, independently of the active ruleset(s), > push rules into them, flush them, and then atomically switch them to be > the active ruleset, using a single syscall. Isn't that more or less sets you are talking about? Quoting ipfw(8): Each rule belongs to one of 32 different sets , numbered 0 to 31. Set= 31 is reserved for the default rule. By default, rules are put in set 0, unless you use the set N attribute when entering a new rule. Sets can be individually and atomically enabled or disabled, so this mechanism permits an easy way to store mu= l- tiple configurations of the firewall and quickly (and atomically) swit= ch between them. The command to enable/disable sets is ipfw set [disable number ...] [enable number ...] where multiple enable or disable sections can be specified. Command e= xe- cution is atomic on all the sets specified in the command. By default, all sets are enabled. --=20 Simon L. Nielsen --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBvvYQh9pcDSc1mlERAo3KAKCKqUVevMhTp4sZOS7Tvno9oEjrzQCeOUPo qUY7MGxCHypbtTraiVo9MKE= =AGnE -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:19:29 2004 Return-Path: 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 9416E16A4CE for ; Tue, 14 Dec 2004 14:19:29 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDED643D49 for ; Tue, 14 Dec 2004 14:19:28 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26991 invoked from network); 14 Dec 2004 14:08:20 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 14:08:20 -0000 Message-ID: <41BEF670.95C30ED5@freebsd.org> Date: Tue, 14 Dec 2004 15:19:28 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce M Simpson References: <41BEF2AF.470F9079@freebsd.org> <20041214141307.GA684@empiric.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:19:29 -0000 Bruce M Simpson wrote: > > On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote: > > Let's take a high level view of the issue at hand and the consider > > some alternative approaches to the situation. > [snip] > > I'm wrapping up in Berkeley for the holidays, but I wanted to drop my 2c > into this discussion. > > What I'm really missing in IPFW is the ability to maintain one or more > 'shadow rulesets'. These rulesets may not be the active rulesets, but > I can manipulate them as tables, independently of the active ruleset(s), > push rules into them, flush them, and then atomically switch them to be > the active ruleset, using a single syscall. IPFW2 does have this functionality. It's called "sets" of rules which you can atomically swap, enable, disable, flush and intermix with each other. It's there, read ipfw(8), it's on the 15th line. > IPF and PF have such functionality, IPFW does not. The lack of a documented > ABI/API for access to IPFW by applications other than ipfw(8) is something > which I'm leaving out of the picture for the moment. It got a lot easier with the micro-ops but you are right there is no documented rule-API. You could write the documentation though. > I don't really consider using 'skipto' and separate sections of rule > index number space a valid answer here, because we should have the ability > to independently flush each ruleset. > > When extended to stateful rules (I am talking here purely about the simple > stateless packet filter case), this comes in even more useful. As long as you don't disable the rule set containing the 'check-state' rule then already active connections remain active but no new ones are allowed by the disabled set. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:20:11 2004 Return-Path: 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 69ABD16A4CE; Tue, 14 Dec 2004 14:20:11 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5135143D49; Tue, 14 Dec 2004 14:20:11 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBEEKAjW078040; Tue, 14 Dec 2004 06:20:10 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBEEKAA4078039; Tue, 14 Dec 2004 06:20:10 -0800 (PST) (envelope-from rizzo) Date: Tue, 14 Dec 2004 06:20:10 -0800 From: Luigi Rizzo To: Andre Oppermann , freebsd-net@freebsd.org Message-ID: <20041214062010.A77933@xorpc.icir.org> References: <41BEF2AF.470F9079@freebsd.org> <20041214141307.GA684@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041214141307.GA684@empiric.icir.org>; from bms@spc.org on Tue, Dec 14, 2004 at 06:13:07AM -0800 Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:20:11 -0000 On Tue, Dec 14, 2004 at 06:13:07AM -0800, Bruce M Simpson wrote: ... > What I'm really missing in IPFW is the ability to maintain one or more > 'shadow rulesets'. These rulesets may not be the active rulesets, but > I can manipulate them as tables, independently of the active ruleset(s), ??? What what ??? They do exist, they are called 'set' and you can associate rules to a specific set, atomically enable/disable/swap/rename sets, etc. This was designed exactly for this purpose (atomic updates of firewall configuration with a single syscall). have a look at the ipfw manpage and then see if it answer your needs. cheers luigi > IPF and PF have such functionality, IPFW does not. The lack of a documented > ABI/API for access to IPFW by applications other than ipfw(8) is something > which I'm leaving out of the picture for the moment. > I don't really consider using 'skipto' and separate sections of rule > index number space a valid answer here, because we should have the ability > to independently flush each ruleset. > > When extended to stateful rules (I am talking here purely about the simple > stateless packet filter case), this comes in even more useful. > > Regards, > BMS From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:21:12 2004 Return-Path: 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 4EE8516A4CE; Tue, 14 Dec 2004 14:21:12 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 633D943D1D; Tue, 14 Dec 2004 14:21:11 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CeDXv-0003za-00; Tue, 14 Dec 2004 15:20:59 +0100 Received: from [217.227.149.15] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CeDXv-0005zQ-00; Tue, 14 Dec 2004 15:20:59 +0100 From: Max Laier To: Luigi Rizzo Date: Tue, 14 Dec 2004 15:21:39 +0100 User-Agent: KMail/1.7.1 References: <20041213124051.GB32719@cell.sick.ru> <41BEE0E7.BD2316EB@freebsd.org> <20041214060341.A77720@xorpc.icir.org> In-Reply-To: <20041214060341.A77720@xorpc.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1666851.cVdm6rTj8D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412141521.53098.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:21:12 -0000 --nextPart1666851.cVdm6rTj8D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 14 December 2004 15:03, Luigi Rizzo wrote: > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > ... > > > > Implementationwise, the kernel side is evidently trivial as the > > > original code already supports the idea of multiple chains. All > > > you need is to extend the struct ifnet with a pointer to the chain, > > > or use some other trick (e.g. going through ifindex) to quickly > > > associate a chain to the input (and possibly output) interface. > > > > Nonononononononononononononononononononononono. > > andre you need to cool down a bit! We should all. > i said "use some other trick" exactly to avoid changing > the struct ifnet. All i meant to say is that we want a unique > key, possibly in a small namespace, to quickly locate the per-if > private firewall info. How the key is used is not a business of > the rest of the kernel. But of course if it is an index in a > smallish array (such as ifindex) the thing is fast and clean. Well spoken! Let's just *not* go linux here and have a "hook" on every laye= r=20 over and over and over again [1] ... because that certainly does *not* help= =20 performance. There is always room for optimization *within* the filter. Messing struct=20 ifnet or other parts of the kernel with firewall information is not the way= =20 to go. [1] http://fxr.watson.org/fxr/ident?v=3Dlinux-2.6.9;i=3DNF_HOOK =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 --nextPart1666851.cVdm6rTj8D Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBvvcBXyyEoT62BG0RAj7NAJ46GAsDsRkbmWiTq3C0S6Rzb6/8eQCeOJuD eQnnLVucs7PdH9kRnQDNfzI= =JOop -----END PGP SIGNATURE----- --nextPart1666851.cVdm6rTj8D-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:23:03 2004 Return-Path: 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 148D516A4CE for ; Tue, 14 Dec 2004 14:23:03 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B5C43D4C for ; Tue, 14 Dec 2004 14:23:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27088 invoked from network); 14 Dec 2004 14:11:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 14:11:54 -0000 Message-ID: <41BEF746.E8362858@freebsd.org> Date: Tue, 14 Dec 2004 15:23:02 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <20041213124051.GB32719@cell.sick.ru> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> <20041214060341.A77720@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:23:03 -0000 Luigi Rizzo wrote: > > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > ... > > > Implementationwise, the kernel side is evidently trivial as the > > > original code already supports the idea of multiple chains. All > > > you need is to extend the struct ifnet with a pointer to the chain, > > > or use some other trick (e.g. going through ifindex) to quickly > > > associate a chain to the input (and possibly output) interface. > > > > Nonononononononononononononononononononononono. > > andre you need to cool down a bit! I'm not angry but frustrated. In the network area it's too much 'lets quickly hack this in' instead of 'lets carefully design this in'. > i said "use some other trick" exactly to avoid changing > the struct ifnet. All i meant to say is that we want a unique > key, possibly in a small namespace, to quickly locate the per-if > private firewall info. How the key is used is not a business of > the rest of the kernel. But of course if it is an index in a > smallish array (such as ifindex) the thing is fast and clean. Ok, I'm fine with *this* approach. This can be done and handled inside ipfw_check_in|out() based on the interface pointer information passed in from pfil_run_hooks(). Then inside IPFW it can be implemented with multiple rule chains although I'm not convinced this would be the smartest approach. Wouldn't it be even better to have per-interface and global rules after each other? This way your problem with the general rule synching can be solved. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:31:18 2004 Return-Path: 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 9409416A4CE; Tue, 14 Dec 2004 14:31:18 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 718BD43D1D; Tue, 14 Dec 2004 14:31:18 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBEEVIsd078165; Tue, 14 Dec 2004 06:31:18 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBEEVIFf078164; Tue, 14 Dec 2004 06:31:18 -0800 (PST) (envelope-from rizzo) Date: Tue, 14 Dec 2004 06:31:18 -0800 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20041214063118.B77933@xorpc.icir.org> References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <41BEF746.E8362858@freebsd.org>; from andre@freebsd.org on Tue, Dec 14, 2004 at 03:23:02PM +0100 cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:31:18 -0000 On Tue, Dec 14, 2004 at 03:23:02PM +0100, Andre Oppermann wrote: ... > > the struct ifnet. All i meant to say is that we want a unique > > key, possibly in a small namespace, to quickly locate the per-if > > private firewall info. How the key is used is not a business of > > the rest of the kernel. But of course if it is an index in a > > smallish array (such as ifindex) the thing is fast and clean. > > Ok, I'm fine with *this* approach. > > This can be done and handled inside ipfw_check_in|out() based on the > interface pointer information passed in from pfil_run_hooks(). > > Then inside IPFW it can be implemented with multiple rule chains > although I'm not convinced this would be the smartest approach. alternatives ? > Wouldn't it be even better to have per-interface and global rules > after each other? This way your problem with the general rule > synching can be solved. this is what gleb suggested later today, but i don't think this solves the problem because sometimes you want the common processing to be at the beginning, sometimes at the end of the chain... Plus there is the issue of namespace -- when you do 'skipto 1000' is this a rule number in the global or the private chain ? Having only *one* chain (either public or private) solves the problem although at the price of some extra copies of the firewall code. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:42:29 2004 Return-Path: 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 EA28616A4CE; Tue, 14 Dec 2004 14:42:28 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3654A43D46; Tue, 14 Dec 2004 14:42:28 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CeDsf-000Cca-M8; Tue, 14 Dec 2004 17:42:25 +0300 From: Vladimir Grebenschikov To: Andre Oppermann In-Reply-To: <41BEE281.607DD0A8@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Dec 2004 17:42:25 +0300 Message-Id: <1103035345.1060.55.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:42:29 -0000 =F7 =D7=D4, 14/12/2004 =D7 13:54 +0100, Andre Oppermann =D0=C9=DB=C5=D4: > Vladimir Grebenschikov wrote: > =20 > > > I know this. We have a well commented firewall scripts, we store them= at RCS, > > > we do many things to make our life easier. But my practice (and my co= llegues) > > > shows that per interface filters are easier to understand and maintai= n when > > > number of interfaces grows up to 20 and more, and they all are logica= lly > > > different - clients, servers, DMZs, hardware, nated networks, etc. > > > > > > Again, this feature is not for all. This is for people who build comp= licated > > > routers on FreeBSD. It is not going to hurt standard host setups. > >=20 > > Frankly speaking, I think ppl who runs real-life router with firewall o= n > > fbsd will vote for this feature by both hands. > >=20 > > I sometime, some years ago I had freebsd router with near to 100 > > interfaces (mostly VLANs and FrameRelay customers connections, and > > about 10 physical media interfaces). This router transfers some > > thousands packets per second. It was real trouble to rearrange ipfw > > table with large (very large) number of jumps (especially in case when > > some number range was exceeded and renumbering required). Also most of > > router interrupt time was spent in going through client multiplexer par= t > > of ipfw ruleset. > >=20 > > Gleb, please do the feature. > >=20 > > Why we do not avoid bottlenecks where they can be avoided ? > > With that feature we can select right rules for specific interface > > without do linear search by ruleset. >=20 > It's about HOW to implement it. I think the ways proposed so far are > hackish, too complex and outside of our framework which was very well > designed and allows this kind of feature without any of the hacks and > extentions discussed here. >=20 > We have to properly DESIGN these feature instead of just hacking them > in. Well, I agree, that it is about how to design it. But I do not think that proposed solution is hackish, and I not alone with it. Let's imagine our firewall framework as general firewall, able to be plugged on different layers, after that you can get following: 1. Plug firewall (dedicated chain) between netgraph nodes 2. Plug firewall on any specific interface=20 3. Plug firewall on any network packet processing input/output (current) 4. Plug it into bridging code In this list interface looks very reasonable as place to plug, for me it looks even more reasonable then our usual input/output, because packet on ether output gives you no idea where it come from - local or remote, especially in complex setups, with often changing interface names and indexes (pptp server for example). It is not clear how to write rules that affects only local traffic and transit traffic (I do not mean loop- back when talk about local traffic) > > Do we what FreeBSD be used on large scale of setups or we have think > > targeting ? >=20 > As long as there is a sufficient large base we are not opposed to it. > What we are opposed at is tradeoffs which favor one particular minority > special interest over the general average interest set. >=20 > > -- off-topic -- > > Days ago FreeBSD was only OS flexible and stable enough to be use in > > complex, customized network environments, but now-days it is not so :(, > > and you know why. > > -- off-topic -- (not for flame or advocacy, just emotion) >=20 > No, I don't know why and this isn't helping any. >=20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:48:33 2004 Return-Path: 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 BBCA416A4CE for ; Tue, 14 Dec 2004 14:48:33 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDD6743D41 for ; Tue, 14 Dec 2004 14:48:32 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id iBEEjV8d097443 for freebsd-net@freebsd.org.checked; Tue, 14 Dec 2004 17:45:31 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id iBEEi4qk097407; Tue, 14 Dec 2004 17:44:04 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41BEFD67.2060501@cronyx.ru> Date: Tue, 14 Dec 2004 17:49:11 +0300 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <41BEF2AF.470F9079@freebsd.org> In-Reply-To: <41BEF2AF.470F9079@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 14:48:33 -0000 Hi, Could we also add ability to keep state between reseting of the rules? For, example, if I use keepstates, after flushing and setting new rules that could be different by two lines from an old one I kick my self from that server with out any serious reason, I didn't change anything for ssh. IMHO this could be done by keepstate for a while after flushing, but I didn't ever look inside this code. rik Andre Oppermann wrote: >Let's take a high level view of the issue at hand and the consider >some alternative approaches to the situation. > >Current situation: > > a1. There is a need to have per-interface specific firewall rules. > a2. We have multiple firewall packages which have multiple way to > specify interface specific rules. > a3. With large numbers of interface specific rules the rulesets get > complex and hard to manage. > a4. This seems to be mainly a problem with ipfw and it's skipto > actions. > >Request: > > b1. Users request a less complicated way of doing interface specific > firewall rules. > >Analysis: > > c1. This is primarily a USER interface/syntax/semantics issue. > c2. The different user interface approaches of the different firewall > packages we have require different changes to their USER interfaces > to make it easier for per-interface rule sets. > c3. The firewall packages we have can only deal with one global rule > set per protocol family and direction currently. They can't be > loaded multiple times and can't have multiple rule set heads (only > one entry point). > >Implementation approaches: > > d1. The PFIL_HOOKS API has one hook per direction per protocol and > passes the interface information to the firewall package. > d2. Should the PFIL_HOOKS API be changed and be per interface instead > of per protocol? All firewall packages need to be modified and > we are no longer compatible with the PFIL_HOOKS API. > d3. Should the interface specific rules sets be per firewall package > in the way that best suits the package? No kernel API is changed. > d4. What is the user interface syntax and semantics for each firewall > package that someone wants to be modified? Provide examples for > those you are interested in. > d5. Should it be a replica of Cisco|Juniper approaches or can we do > better in syntax or semantics? Think outside of the box. > >Lets continue the discussion from here. > > > From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 15:01:56 2004 Return-Path: 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 6B98A16A4CE; Tue, 14 Dec 2004 15:01:56 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21B8C43D45; Tue, 14 Dec 2004 15:01:54 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 38494653FF; Tue, 14 Dec 2004 15:01:53 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15433-02-8; Tue, 14 Dec 2004 15:01:52 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 5E85A65211; Tue, 14 Dec 2004 15:01:50 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 0A1666710; Tue, 14 Dec 2004 07:01:49 -0800 (PST) Date: Tue, 14 Dec 2004 07:01:49 -0800 From: Bruce M Simpson To: Andre Oppermann Message-ID: <20041214150148.GC684@empiric.icir.org> Mail-Followup-To: Andre Oppermann , freebsd-net@freebsd.org References: <41BEF2AF.470F9079@freebsd.org> <20041214141307.GA684@empiric.icir.org> <41BEF670.95C30ED5@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zCKi3GIZzVBPywwA" Content-Disposition: inline In-Reply-To: <41BEF670.95C30ED5@freebsd.org> cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 15:01:56 -0000 --zCKi3GIZzVBPywwA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, At this point I'm tempted to explicitly *not* roll support for IPFW1 in XORP's ACL manager precisely because of its limitations; see below. On Tue, Dec 14, 2004 at 03:19:28PM +0100, Andre Oppermann wrote: > IPFW2 does have this functionality. It's called "sets" of rules which > you can atomically swap, enable, disable, flush and intermix with each > other. It's there, read ipfw(8), it's on the 15th line. OK. This is probably something I can deal with. Basically XORP has an intermediate rule representation which tries to be generic enough to deal with divergent packet filter implementations across various OS platforms, and yet specific enough to be useful. A XORP rule tuple looks like this: ifname, vifname, src, dst, proto, sport, dport, action Rule matches take place on all fields but the 'action' part of the tuple. The interface to XORP's packet ACL manager is transaction driven to ensure atomicity. Where this atomicity can't be guaranteed by the underlying back-end, the back-end should attempt to mimic it using whatever tricks are necessary. Snapshots get taken at two levels: XORP's intermediate representation described above, and the back-end's state. These snapshots can be taken either for the purpose of safely rolling back state when rulesets are being changed, or for communicating rulesets between different parts of the packet ACL system. I would imagine that mapping between an IPFW2 'set' and a PaIpfwBackend snapshot on the fly would do the trick. I just committed the core of XORP's ACL manager last week, please feel free to have a look at it and give me feedback. Regards, BMS --zCKi3GIZzVBPywwA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBvwBcueUpAYYNtTsRAvh1AJ9R1OXVfLBta/M/D5PgimE9MW3/UwCfW+uS KYTGji5nwSljAEt20h+U6IY= =VUpk -----END PGP SIGNATURE----- --zCKi3GIZzVBPywwA-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 15:02:38 2004 Return-Path: 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 9F35C16A4CE for ; Tue, 14 Dec 2004 15:02:38 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5902543D41 for ; Tue, 14 Dec 2004 15:02:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27389 invoked from network); 14 Dec 2004 14:51:28 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 14:51:28 -0000 Message-ID: <41BF008D.AD79C9B@freebsd.org> Date: Tue, 14 Dec 2004 16:02:37 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vova@fbsd.ru References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <1103035345.1060.55.camel@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 15:02:38 -0000 Vladimir Grebenschikov wrote: > > ч ЧФ, 14/12/2004 Ч 13:54 +0100, Andre Oppermann РЙЫЕФ: > > It's about HOW to implement it. I think the ways proposed so far are > > hackish, too complex and outside of our framework which was very well > > designed and allows this kind of feature without any of the hacks and > > extentions discussed here. > > > > We have to properly DESIGN these feature instead of just hacking them > > in. > > Well, I agree, that it is about how to design it. > But I do not think that proposed solution is hackish, and I not alone > with it. It breaks the PFIL_HOOKS API. > Let's imagine our firewall framework as general firewall, able to be > plugged on different layers, after that you can get following: > > 1. Plug firewall (dedicated chain) between netgraph nodes [Doesn't work before and after PFIL_HOOKS API breakage. You'd need a ipfw netgraph node for that anyway.] > 2. Plug firewall on any specific interface > 3. Plug firewall on any network packet processing input/output (current) > 4. Plug it into bridging code How do you represent this complexity in syntax and semantics? This is the tricky problem to be solved first. Then we can start arguing about implementation issues, API's, ABI's and other related things. So give me syntax and semantics examples how you want to operate this functionality? We do not dispute the need for per-interface rules. The question is *how* to represent it. In fact that is the only question because the functionality is already there, only hard to use. I haven't yet seen how you make it easier to use other than saying "ipfw per-interface". But that doesn't answer my question. > In this list interface looks very reasonable as place to plug, for me it > looks even more reasonable then our usual input/output, because packet > on ether output gives you no idea where it come from - local or remote, > especially in complex setups, with often changing interface names and > indexes (pptp server for example). It is not clear how to write rules > that affects only local traffic and transit traffic (I do not mean loop- > back when talk about local traffic) With cloned devices you have a problem anyway. Who puts the correct ipfw chain head pointer into struct ifnet in your example? devd perhaps? Please enlighten me. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 15:05:24 2004 Return-Path: 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 8CE7F16A4CE; Tue, 14 Dec 2004 15:05:24 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40FBA43D2F; Tue, 14 Dec 2004 15:05:24 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 3EA2465418; Tue, 14 Dec 2004 15:05:23 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15217-04; Tue, 14 Dec 2004 15:05:22 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 4ADB665211; Tue, 14 Dec 2004 15:05:22 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id E55B16710; Tue, 14 Dec 2004 07:05:20 -0800 (PST) Date: Tue, 14 Dec 2004 07:05:20 -0800 From: Bruce M Simpson To: Luigi Rizzo Message-ID: <20041214150520.GD684@empiric.icir.org> Mail-Followup-To: Luigi Rizzo , Andre Oppermann , freebsd-net@freebsd.org References: <41BEF2AF.470F9079@freebsd.org> <20041214141307.GA684@empiric.icir.org> <20041214062010.A77933@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ylS2wUBXLOxYXZFQ" Content-Disposition: inline In-Reply-To: <20041214062010.A77933@xorpc.icir.org> cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 15:05:24 -0000 --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 14, 2004 at 06:20:10AM -0800, Luigi Rizzo wrote: > They do exist, they are called 'set' and you can associate > rules to a specific set, atomically enable/disable/swap/rename > sets, etc. This was designed exactly for this purpose (atomic > updates of firewall configuration with a single syscall). Thanks for this. I'm trying to consider IPFW1 in the picture as well; IPFW2 is something I'm considering as a separate entity. However I am put off by a lot of the limitations in IPFW1. Are there any nicer ways of telling IPFW v1 and v2 apart both at compile time and run-time? Right now I do something like this:- %%% AC_MSG_CHECKING(for an IPFW firewall build environment) AC_LANG_SAVE AC_LANG_C AC_TRY_COMPILE([ #include #include #include #include #include #include #include ], [ int mysockopt = IP_FW_ADD; #ifdef IPFW2 #error IPFW2 defined (should not be defined for IPFW). Test failed. #endif ], [AC_DEFINE(HAVE_FIREWALL_IPFW, 1, [Define to 1 if you have an IPFW build environment]) AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no)]) AC_LANG_RESTORE %%% The above test is for IPFW1. The equivalent test for IPFW2 simply flips the sense of the #ifdef inside. This is not ideal because can exist in both flavours in the same system (albeit in the case of FreeBSD 4.11, it will include the IPFW2 header instead if IPFW2 is defined). No doubt the present IPFW documentation can be improved. What will soon exist in XORP is something approximating an IPFW API. I may not have time to do anything in this area, but what I'm doing for XORP could certainly be re-used to some extent. Regards, BMS --ylS2wUBXLOxYXZFQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBvwEwueUpAYYNtTsRAlFyAJ9DyvwDfDEyZNZtaoQwy2/tDad0RgCfUZsY UdE39hKtFlXwujCbex4+kUs= =9AHD -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 15:27:20 2004 Return-Path: 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 C392216A4CE for ; Tue, 14 Dec 2004 15:27:20 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0289843D2D for ; Tue, 14 Dec 2004 15:27:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27599 invoked from network); 14 Dec 2004 15:16:11 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 15:16:11 -0000 Message-ID: <41BF0657.3CF0ED10@freebsd.org> Date: Tue, 14 Dec 2004 16:27:19 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce M Simpson References: <41BEF2AF.470F9079@freebsd.org> <20041214141307.GA684@empiric.icir.org> <41BEF670.95C30ED5@freebsd.org> <20041214150148.GC684@empiric.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 15:27:20 -0000 Bruce M Simpson wrote: > > Hi, > > At this point I'm tempted to explicitly *not* roll support for IPFW1 > in XORP's ACL manager precisely because of its limitations; see below. I'd say IPFW1 is dead. Just ignore it and require IPFW2 on 4.x. > On Tue, Dec 14, 2004 at 03:19:28PM +0100, Andre Oppermann wrote: > > IPFW2 does have this functionality. It's called "sets" of rules which > > you can atomically swap, enable, disable, flush and intermix with each > > other. It's there, read ipfw(8), it's on the 15th line. > > OK. This is probably something I can deal with. Basically XORP has an > intermediate rule representation which tries to be generic enough to > deal with divergent packet filter implementations across various OS > platforms, and yet specific enough to be useful. > > A XORP rule tuple looks like this: > ifname, vifname, src, dst, proto, sport, dport, action > Rule matches take place on all fields but the 'action' part of the tuple. Can you provide examples of a XORP packet filter rule set? > The interface to XORP's packet ACL manager is transaction driven to ensure > atomicity. Where this atomicity can't be guaranteed by the underlying > back-end, the back-end should attempt to mimic it using whatever tricks > are necessary. > > Snapshots get taken at two levels: XORP's intermediate representation > described above, and the back-end's state. These snapshots can be taken > either for the purpose of safely rolling back state when rulesets are > being changed, or for communicating rulesets between different parts of > the packet ACL system. > > I would imagine that mapping between an IPFW2 'set' and a PaIpfwBackend > snapshot on the fly would do the trick. Perfect match. You can even keep up to 32 versions in the kernel and do one-syscall rollback's/forward's to any of them. > I just committed the core of XORP's ACL manager last week, please feel > free to have a look at it and give me feedback. I did take a quick look but my c++ understanding is horribly and I don't have time to work myself through the XORP framework. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 15:32:52 2004 Return-Path: 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 EFC6C16A4CE for ; Tue, 14 Dec 2004 15:32:52 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30E8043D3F for ; Tue, 14 Dec 2004 15:32:52 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27652 invoked from network); 14 Dec 2004 15:21:43 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 15:21:43 -0000 Message-ID: <41BF07A3.8F1F505E@freebsd.org> Date: Tue, 14 Dec 2004 16:32:51 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 15:32:53 -0000 Luigi Rizzo wrote: > > On Tue, Dec 14, 2004 at 03:23:02PM +0100, Andre Oppermann wrote: > ... > > > the struct ifnet. All i meant to say is that we want a unique > > > key, possibly in a small namespace, to quickly locate the per-if > > > private firewall info. How the key is used is not a business of > > > the rest of the kernel. But of course if it is an index in a > > > smallish array (such as ifindex) the thing is fast and clean. > > > > Ok, I'm fine with *this* approach. > > > > This can be done and handled inside ipfw_check_in|out() based on the > > interface pointer information passed in from pfil_run_hooks(). > > > > Then inside IPFW it can be implemented with multiple rule chains > > although I'm not convinced this would be the smartest approach. > > alternatives ? See below. > > Wouldn't it be even better to have per-interface and global rules > > after each other? This way your problem with the general rule > > synching can be solved. > > this is what gleb suggested later today, but i don't think > this solves the problem because sometimes you want the common > processing to be at the beginning, sometimes at the end of the > chain... Plus there is the issue of namespace -- when you do > 'skipto 1000' is this a rule number in the global or the > private chain ? Having only *one* chain (either public or > private) solves the problem although at the price of some > extra copies of the firewall code. I've got something in mind marrying the global/interface approach based on my experience of managing large Cisco per-interface ACL's (which is a royal pain to get right). The big problem of the per- interface approach is the protection of the host itself (control plane in Cisco speak). They have fixed it in newest IOS with so called infrastructure ACL's but that is making life only a little better. Give a bit time to work out the idea some more. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 15:51:03 2004 Return-Path: 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 BDAB116A4CE; Tue, 14 Dec 2004 15:51:03 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EDCF43D5C; Tue, 14 Dec 2004 15:51:03 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBEFp3X4079042; Tue, 14 Dec 2004 07:51:03 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBEFp3wX079041; Tue, 14 Dec 2004 07:51:03 -0800 (PST) (envelope-from rizzo) Date: Tue, 14 Dec 2004 07:51:03 -0800 From: Luigi Rizzo To: Andre Oppermann , freebsd-net@freebsd.org Message-ID: <20041214075103.C78388@xorpc.icir.org> References: <41BEF2AF.470F9079@freebsd.org> <20041214062010.A77933@xorpc.icir.org> <20041214150520.GD684@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041214150520.GD684@empiric.icir.org>; from bms@spc.org on Tue, Dec 14, 2004 at 07:05:20AM -0800 Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 15:51:03 -0000 On Tue, Dec 14, 2004 at 07:05:20AM -0800, Bruce M Simpson wrote: ... > Are there any nicer ways of telling IPFW v1 and v2 apart both at compile > time and run-time? Right now I do something like this:- With very high accuracy, at compile time you can say that ipfw2 is available from 4.7 and higher, and ipfw1 is _not_ available in 5.0 and above. At runtime, the easiest way is try issue an ipfw2 command and see if it returns an error or not. Note however that ipfw2 features increase over time. Atomic 'set' support was introduced in 4.9/5.2, and opcodes of minor importance came later. cheers luigi > %%% > AC_MSG_CHECKING(for an IPFW firewall build environment) > AC_LANG_SAVE > AC_LANG_C > AC_TRY_COMPILE([ > #include > #include > #include > #include > #include > #include > #include > ], > [ > int mysockopt = IP_FW_ADD; > #ifdef IPFW2 > #error IPFW2 defined (should not be defined for IPFW). Test failed. > #endif > ], > [AC_DEFINE(HAVE_FIREWALL_IPFW, 1, > [Define to 1 if you have an IPFW build environment]) > AC_MSG_RESULT(yes)], > [AC_MSG_RESULT(no)]) > AC_LANG_RESTORE > %%% > > The above test is for IPFW1. The equivalent test for IPFW2 simply flips > the sense of the #ifdef inside. This is not ideal because > can exist in both flavours in the same system (albeit in > the case of FreeBSD 4.11, it will include the IPFW2 header instead if > IPFW2 is defined). > > No doubt the present IPFW documentation can be improved. What will soon > exist in XORP is something approximating an IPFW API. I may not have time > to do anything in this area, but what I'm doing for XORP could certainly > be re-used to some extent. > > Regards, > BMS From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 16:00:35 2004 Return-Path: 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 6065516A4CF; Tue, 14 Dec 2004 16:00:35 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B9A243D31; Tue, 14 Dec 2004 16:00:34 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CeF6G-0003pm-MO; Tue, 14 Dec 2004 19:00:32 +0300 From: Vladimir Grebenschikov To: Andre Oppermann In-Reply-To: <41BF008D.AD79C9B@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Dec 2004 19:00:32 +0300 Message-Id: <1103040032.1060.72.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 16:00:35 -0000 =D0=92 =D0=B2=D1=82, 14/12/2004 =D0=B2 16:02 +0100, Andre Oppermann =D0=BF= =D0=B8=D1=88=D0=B5=D1=82: > Vladimir Grebenschikov wrote: > >=20 > > =C3=B7 =C3=97=C3=94, 14/12/2004 =C3=97 13:54 +0100, Andre Oppermann =C3= =90=C3=89=C3=9B=C3=85=C3=94: > > > It's about HOW to implement it. I think the ways proposed so far are > > > hackish, too complex and outside of our framework which was very well > > > designed and allows this kind of feature without any of the hacks and > > > extentions discussed here. > > > > > > We have to properly DESIGN these feature instead of just hacking them > > > in. > >=20 > > Well, I agree, that it is about how to design it. > > But I do not think that proposed solution is hackish, and I not alone > > with it. >=20 > It breaks the PFIL_HOOKS API. If I not mistaken Gleb claims that do not break: G> please don't take this hard. I'm not going to change pfil(4) API, G> since it has everything required. > > Let's imagine our firewall framework as general firewall, able to be > > plugged on different layers, after that you can get following: > >=20 > > 1. Plug firewall (dedicated chain) between netgraph nodes >=20 > [Doesn't work before and after PFIL_HOOKS API breakage. You'd need a > ipfw netgraph node for that anyway.] Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph filtering has nothing common with host filtering. > > 2. Plug firewall on any specific interface > > 3. Plug firewall on any network packet processing input/output (current= ) > > 4. Plug it into bridging code >=20 > How do you represent this complexity in syntax and semantics? First what jump into my mind: flows management: ipfw flow add $customer1 iface fxp0 ipfw flow del $customer2 iface fxp0 ipfw flow set $customer1 iface fxp1 ipfw flow default $extrenal ipfw flow list changes rules for flow ipfw flow use $customer1 add ip from any to any ... or as variant ipfw -F $customer1 add ip from any to any ... I think there can be better interface if think a bit about it. > This is the tricky problem to be solved first. Then we can start arguing > about implementation issues, API's, ABI's and other related things. Again, Gleb do not going to change API or ABI. > So give me syntax and semantics examples how you want to operate this > functionality? =20 see above=20 > We do not dispute the need for per-interface rules. =20 Ok, so we agree that it is good idea ?=20 > The question is *how* to represent it. =20 > In fact that is the only question because the functionality is already th= ere,=20 > only hard to use. I haven't yet seen how you make it easier to use other= =20 > than saying "ipfw per-interface". But that doesn't answer my question. So what=20 > > In this list interface looks very reasonable as place to plug, for me i= t > > looks even more reasonable then our usual input/output, because packet > > on ether output gives you no idea where it come from - local or remote, > > especially in complex setups, with often changing interface names and > > indexes (pptp server for example). It is not clear how to write rules > > that affects only local traffic and transit traffic (I do not mean loop= - > > back when talk about local traffic) >=20 > With cloned devices you have a problem anyway. Who puts the correct > ipfw chain head pointer into struct ifnet in your example? devd perhaps? mpd while start pptp session, or like > Please enlighten me. --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 16:13:08 2004 Return-Path: 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 15A0416A4CE for ; Tue, 14 Dec 2004 16:13:08 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C9B343D49 for ; Tue, 14 Dec 2004 16:13:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 28161 invoked from network); 14 Dec 2004 16:01:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 16:01:58 -0000 Message-ID: <41BF1112.77C18DC6@freebsd.org> Date: Tue, 14 Dec 2004 17:13:06 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vova@fbsd.ru References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <1103040032.1060.72.camel@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 16:13:08 -0000 Vladimir Grebenschikov wrote: > > > It breaks the PFIL_HOOKS API. > > If I not mistaken Gleb claims that do not break: > > G> please don't take this hard. I'm not going to change pfil(4) API, > G> since it has everything required. But this is not correct. He changes the way PFIL_HOOKS are called. > > > Let's imagine our firewall framework as general firewall, able to be > > > plugged on different layers, after that you can get following: > > > > > > 1. Plug firewall (dedicated chain) between netgraph nodes > > > > [Doesn't work before and after PFIL_HOOKS API breakage. You'd need a > > ipfw netgraph node for that anyway.] > > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph > filtering has nothing common with host filtering. Nontheless you need to call it from somewhere? > > > 2. Plug firewall on any specific interface > > > 3. Plug firewall on any network packet processing input/output (current) > > > 4. Plug it into bridging code > > > > How do you represent this complexity in syntax and semantics? > > First what jump into my mind: > > flows management: > ipfw flow add $customer1 iface fxp0 > ipfw flow del $customer2 iface fxp0 > ipfw flow set $customer1 iface fxp1 > ipfw flow default $extrenal > ipfw flow list > > changes rules for flow > ipfw flow use $customer1 add ip from any to any > ... Ok, this is a start. Now we are getting somewhere. A "flow" would be what Gleb calls a "chain"? > or as variant > ipfw -F $customer1 add ip from any to any > ... > > I think there can be better interface if think a bit about it. Great. Please do so. > > This is the tricky problem to be solved first. Then we can start arguing > > about implementation issues, API's, ABI's and other related things. > > Again, Gleb do not going to change API or ABI. Again, he does. In a major way. > > So give me syntax and semantics examples how you want to operate this > > functionality? > > see above > > > We do not dispute the need for per-interface rules. > > Ok, so we agree that it is good idea ? Yes. If it is smartly done it can help a lot. If not well done it can wrek havrok. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 16:42:40 2004 Return-Path: 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 C950116A4CE; Tue, 14 Dec 2004 16:42:40 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F5C043D5A; Tue, 14 Dec 2004 16:42:40 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CeFl0-0005qW-TV; Tue, 14 Dec 2004 19:42:38 +0300 From: Vladimir Grebenschikov To: Andre Oppermann In-Reply-To: <41BF1112.77C18DC6@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <1103040032.1060.72.camel@localhost> <41BF1112.77C18DC6@freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Dec 2004 19:42:38 +0300 Message-Id: <1103042558.1060.82.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 16:42:40 -0000 =F7 =D7=D4, 14/12/2004 =D7 17:13 +0100, Andre Oppermann =D0=C9=DB=C5=D4: =20 > > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgrap= h > > filtering has nothing common with host filtering. >=20 > Nontheless you need to call it from somewhere? Yes, If, for example, I do connection of two VPNs without accessiong them into host packet flow and want to firewall something inside. > > > > 2. Plug firewall on any specific interface > > > > 3. Plug firewall on any network packet processing input/output (cur= rent) > > > > 4. Plug it into bridging code > > > > > > How do you represent this complexity in syntax and semantics? > >=20 > > First what jump into my mind: > >=20 > > flows management: > > ipfw flow add $customer1 iface fxp0 > > ipfw flow del $customer2 iface fxp0 > > ipfw flow set $customer1 iface fxp1 > > ipfw flow default $extrenal > > ipfw flow list > >=20 > > changes rules for flow > > ipfw flow use $customer1 add ip from any to any > > ... >=20 > Ok, this is a start. Now we are getting somewhere. >=20 > A "flow" would be what Gleb calls a "chain"? Yes, exactly, just read Gleb's message. > > or as variant > > ipfw -F $customer1 add ip from any to any > > ... > >=20 > > I think there can be better interface if think a bit about it. >=20 > Great. Please do so. Probably better way to do =20 ipfw flow set $custome1 add iface fxp0 del iface fxp1 ... etc for attaching multiple interfaces to single flow (or chain, does not matter) also=20 ipfw flow add $dummy - to add not connected flow and ipfw flow default $dummy to make this flow system-default (instead of old) > > > This is the tricky problem to be solved first. Then we can start arg= uing > > > about implementation issues, API's, ABI's and other related things. > >=20 > > Again, Gleb do not going to change API or ABI. >=20 > Again, he does. In a major way. Ok, I do not want to deep into details until I'll look code, but I guess it is possible to extend PFIL_HOOKS API without harming existing applications. > > > So give me syntax and semantics examples how you want to operate this > > > functionality? > >=20 > > see above > >=20 > > > We do not dispute the need for per-interface rules. > >=20 > > Ok, so we agree that it is good idea ? >=20 > Yes. If it is smartly done it can help a lot. If not well done it > can wrek havrok. >=20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 16:56:37 2004 Return-Path: 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 E0E1716A4CE for ; Tue, 14 Dec 2004 16:56:37 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D062F43D39 for ; Tue, 14 Dec 2004 16:56:36 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 28526 invoked from network); 14 Dec 2004 16:45:27 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 16:45:27 -0000 Message-ID: <41BF1B44.E3C1453E@freebsd.org> Date: Tue, 14 Dec 2004 17:56:36 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vova@fbsd.ru References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <1103040032.1060.72.camel@localhost> <1103042558.1060.82.camel@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 16:56:38 -0000 Vladimir Grebenschikov wrote: > > ч ЧФ, 14/12/2004 Ч 17:13 +0100, Andre Oppermann РЙЫЕФ: > > > > Yes, but is about "how netgraph interfere with ipfw" sometimes, netgraph > > > filtering has nothing common with host filtering. > > > > Nontheless you need to call it from somewhere? > > Yes, If, for example, I do connection of two VPNs without accessiong > them into host packet flow and want to firewall something inside. Hence you need a ng_ipfw node to plug in between. Should be easy for Gleb to write one. > > > > > 2. Plug firewall on any specific interface > > > > > 3. Plug firewall on any network packet processing input/output (current) > > > > > 4. Plug it into bridging code > > > > > > > > How do you represent this complexity in syntax and semantics? > > > > > > First what jump into my mind: > > > > > > flows management: > > > ipfw flow add $customer1 iface fxp0 > > > ipfw flow del $customer2 iface fxp0 > > > ipfw flow set $customer1 iface fxp1 > > > ipfw flow default $extrenal > > > ipfw flow list > > > > > > changes rules for flow > > > ipfw flow use $customer1 add ip from any to any > > > ... > > > > Ok, this is a start. Now we are getting somewhere. > > > > A "flow" would be what Gleb calls a "chain"? > > Yes, exactly, just read Gleb's message. > > > > or as variant > > > ipfw -F $customer1 add ip from any to any > > > ... > > > > > > I think there can be better interface if think a bit about it. > > > > Great. Please do so. > > Probably better way to do > > ipfw flow set $custome1 add iface fxp0 del iface fxp1 ... etc > for attaching multiple interfaces to single flow (or chain, does not > matter) > > also > > ipfw flow add $dummy - to add not connected flow > and > ipfw flow default $dummy to make this flow system-default (instead of > old) Ok, I see. Do you mind changing the term "flow" to something else? Because by most accounts a flow is commonly a tcp session for example in Netflow accounting. It would be very confusing to use it here with a total different meaning. > Ok, I do not want to deep into details until I'll look code, but I guess > it is possible to extend PFIL_HOOKS API without harming existing > applications. It is not required to change PFIL_HOOKS in any way. Everything we need is already in there. See Luigi's later emails as well. It just requires a slightly different implementation approach. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 17:25:39 2004 Return-Path: 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 EC80B16A4CE; Tue, 14 Dec 2004 17:25:38 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5459443D1F; Tue, 14 Dec 2004 17:25:38 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CeGQb-0006Aj-89; Tue, 14 Dec 2004 20:25:37 +0300 From: Vladimir Grebenschikov To: Andre Oppermann In-Reply-To: <41BF1B44.E3C1453E@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <1103017203.1060.25.camel@localhost> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <1103042558.1060.82.camel@localhost> <41BF1B44.E3C1453E@freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Dec 2004 20:25:36 +0300 Message-Id: <1103045136.1060.93.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 17:25:39 -0000 =F7 =D7=D4, 14/12/2004 =D7 17:56 +0100, Andre Oppermann =D0=C9=DB=C5=D4: > > > > Yes, but is about "how netgraph interfere with ipfw" sometimes, net= graph > > > > filtering has nothing common with host filtering. > > > > > > Nontheless you need to call it from somewhere? > >=20 > > Yes, If, for example, I do connection of two VPNs without accessiong > > them into host packet flow and want to firewall something inside. >=20 > Hence you need a ng_ipfw node to plug in between. Should be easy for > Gleb to write one. Yes, exactly what I mean, but whole ipfw subsystem should support multiple chains or flows. > > > > > > 2. Plug firewall on any specific interface > > > > > > 3. Plug firewall on any network packet processing input/output = (current) > > > > > > 4. Plug it into bridging code > > > > > > > > > > How do you represent this complexity in syntax and semantics? > > > > > > > > First what jump into my mind: > > > > > > > > flows management: > > > > ipfw flow add $customer1 iface fxp0 > > > > ipfw flow del $customer2 iface fxp0 > > > > ipfw flow set $customer1 iface fxp1 > > > > ipfw flow default $extrenal > > > > ipfw flow list > > > > > > > > changes rules for flow > > > > ipfw flow use $customer1 add ip from any to any > > > > ... > > > > > > Ok, this is a start. Now we are getting somewhere. > > > > > > A "flow" would be what Gleb calls a "chain"? > >=20 > > Yes, exactly, just read Gleb's message. > >=20 > > > > or as variant > > > > ipfw -F $customer1 add ip from any to any > > > > ... > > > > > > > > I think there can be better interface if think a bit about it. > > > > > > Great. Please do so. > >=20 > > Probably better way to do > >=20 > > ipfw flow set $custome1 add iface fxp0 del iface fxp1 ... etc > > for attaching multiple interfaces to single flow (or chain, does not > > matter) > >=20 > > also > >=20 > > ipfw flow add $dummy - to add not connected flow > > and > > ipfw flow default $dummy to make this flow system-default (instead of > > old) >=20 > Ok, I see. >=20 > Do you mind changing the term "flow" to something else? Because by > most accounts a flow is commonly a tcp session for example in Netflow > accounting. It would be very confusing to use it here with a total > different meaning. Term chain is not so bad, only objection - it has relation to Linux's ipchains but has a little common with it. > > Ok, I do not want to deep into details until I'll look code, but I gues= s > > it is possible to extend PFIL_HOOKS API without harming existing > > applications. >=20 > It is not required to change PFIL_HOOKS in any way. Everything we need i= s > already in there. See Luigi's later emails as well. It just requires a > slightly different implementation approach. Greate --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 17:43:50 2004 Return-Path: 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 457F716A4CE; Tue, 14 Dec 2004 17:43:50 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A98043D5D; Tue, 14 Dec 2004 17:43:50 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CeGiD-000CoH-9v; Tue, 14 Dec 2004 09:43:49 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16831.9812.789804.36697@ran.psg.com> Date: Tue, 14 Dec 2004 09:43:48 -0800 To: Andre Oppermann References: <20041213124051.GB32719@cell.sick.ru> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 17:43:50 -0000 >> As i also said before, i agree that when the number of interfaces >> becomes large, managing ipfw lists can become difficult (though i >> see no way your technique can help without the assistance of scripts >> generating the actual lists for each interface making sure that the >> 'common' checks are in sync, etc.) > > This is one of the difficulties of per-interface ACL's like in Cisco > and Juniper. grown-up operators generate their configs programmatically. life just does not scale any other way. randy From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 18:12:32 2004 Return-Path: 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 DC1EB16A4CE; Tue, 14 Dec 2004 18:12:32 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 930B643D64; Tue, 14 Dec 2004 18:12:32 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id EF2712F944; Tue, 14 Dec 2004 13:12:31 -0500 (EST) Date: Tue, 14 Dec 2004 13:12:31 -0500 From: James To: Andre Oppermann Message-ID: <20041214181231.GA80817@scylla.towardex.com> References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> <41BF07A3.8F1F505E@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BF07A3.8F1F505E@freebsd.org> User-Agent: Mutt/1.4.1i cc: Luigi Rizzo cc: freebsd-net@freebsd.org cc: Max Laier Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 18:12:33 -0000 On Tue, Dec 14, 2004 at 04:32:51PM +0100, Andre Oppermann wrote: > See below. > > > > Wouldn't it be even better to have per-interface and global rules > > > after each other? This way your problem with the general rule > > > synching can be solved. > > > > this is what gleb suggested later today, but i don't think > > this solves the problem because sometimes you want the common > > processing to be at the beginning, sometimes at the end of the > > chain... Plus there is the issue of namespace -- when you do > > 'skipto 1000' is this a rule number in the global or the > > private chain ? Having only *one* chain (either public or > > private) solves the problem although at the price of some > > extra copies of the firewall code. > > I've got something in mind marrying the global/interface approach > based on my experience of managing large Cisco per-interface ACL's > (which is a royal pain to get right). The big problem of the per- > interface approach is the protection of the host itself (control > plane in Cisco speak). They have fixed it in newest IOS with so > called infrastructure ACL's but that is making life only a little > better. Yes, it's called receive path ACL. Even if you are using global approach (the way we are now), you still have to deal with receive path to protect your own router-destined traffic. The idea of receive path is to mainly increase the performance and ease the configuration -- there is *no* reason a transit traffic should go thru every rules of a global ruleset like the way it is now (yes, you can avoid this by using bunch of tricks in ipfw, but that is makeshift hack than "doing it right in the beginning" approach). The way we have approached this in the past is to install /32 host routes for each interface addr's and respective subnet and broadcast /32 addresses into the kernel RIB, destined to lo0 interface. Place your per-interface filter on 'lo0' interface and packets destined to router iteslf will be subject to loopback filter before making it onto upper layer protocol. Also, by creating a receive adjacency, you can completely get rid of the unnecessary hash lookups in ip_fastforward() that determine whether packet is destined to us or not. We are already doing an expensive radix lookup on the kernel RIB -- that alone is well enough to give us the information we need with respect to what needs to be done to the packet. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 19:27:11 2004 Return-Path: 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 4ED1B16A4CE for ; Tue, 14 Dec 2004 19:27:11 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 107A343D68 for ; Tue, 14 Dec 2004 19:27:08 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so106582wra for ; Tue, 14 Dec 2004 11:27:02 -0800 (PST) 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:references; b=O0FLMWU/5sqYhxX84kLzvGAh76BUmx00VRe+797iksBG2KUWB1BCHO9D4XOuzs+iR1oaaeZa+KeSptKzOxwbgYjyNWRElsG6J2BeQSYSd7/xKDdfwwSoo2T53CbdaWXsQKvHQ6zoNq5XOpDfWSXsSkj/WamgOW24SFaL0j+gtEk= Received: by 10.54.33.33 with SMTP id g33mr1250909wrg; Tue, 14 Dec 2004 11:27:02 -0800 (PST) Received: by 10.54.23.33 with HTTP; Tue, 14 Dec 2004 11:27:01 -0800 (PST) Message-ID: <7c8f279204121411275ad919f9@mail.gmail.com> Date: Tue, 14 Dec 2004 14:27:01 -0500 From: Josh Kayse To: Andre Oppermann In-Reply-To: <41BEF2AF.470F9079@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41BEF2AF.470F9079@freebsd.org> cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gtg062h@mail.gatech.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 19:27:11 -0000 As someone who is quite new to all of this, take my thoughts with a grain of salt. That being said, this is my view on the matter. On Tue, 14 Dec 2004 15:03:27 +0100, Andre Oppermann wrote: > Let's take a high level view of the issue at hand and the consider > some alternative approaches to the situation. > > Current situation: > Implementation approaches: > > d1. The PFIL_HOOKS API has one hook per direction per protocol and > passes the interface information to the firewall package. > d2. Should the PFIL_HOOKS API be changed and be per interface instead > of per protocol? All firewall packages need to be modified and > we are no longer compatible with the PFIL_HOOKS API. I don't think so because as has been said, the PFIL_HOOKS API provides all the needed information. > d3. Should the interface specific rules sets be per firewall package > in the way that best suits the package? No kernel API is changed. > d4. What is the user interface syntax and semantics for each firewall > package that someone wants to be modified? Provide examples for > those you are interested in. > d5. Should it be a replica of Cisco|Juniper approaches or can we do > better in syntax or semantics? Think outside of the box. > > Lets continue the discussion from here. > > -- > Andre > _______________________________________________ I think so as it would be the best change, in my oblivious opinion. I would see it as the firewall package receives the mbuf, checks the interface, if it is processing rules on the interface, or if there is a global set of rules, to then continue processing the packet. If it isn't, it should just return/get out, whatever. I do believe this would require a change in rule processing. The firewall package would keep track of the different 'chains' for the rulesets. As far as writing rules go, I think that it would be simple to make a script that takes a set of firewall configuration rulesets and merges them so that they do not collide. I think it take more work to get it to make it pretty, but I don't see it being impossible. I'm sure that I'm not understanding exactly what the problem is, so please, let me know what I'm missing, thanks. -- Joshua Kayse Computer Engineering From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 20:57:18 2004 Return-Path: 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 0BE8F16A4CE for ; Tue, 14 Dec 2004 20:57:18 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2236643D48 for ; Tue, 14 Dec 2004 20:57:16 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so358905wri for ; Tue, 14 Dec 2004 12:57:03 -0800 (PST) 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:references; b=goBDSnN578IQ0yYfyVpXdR6ULk+eKMUKF+I/M7vGkxOdUdZ8IgJGhFXtQfcHbSIpUt2EoGJ3h0sE2Yk/uhGITCgBpWH6mKgdApT5O3lU1Xp6oFy0tnEQ2ClmwjluTgajaqR7KJrxBMy8Qe8Q9TOFlcpnti+lXdO3CvlDYcxoRo0= Received: by 10.54.10.76 with SMTP id 76mr134441wrj; Tue, 14 Dec 2004 12:56:26 -0800 (PST) Received: by 10.54.23.33 with HTTP; Tue, 14 Dec 2004 12:56:26 -0800 (PST) Message-ID: <7c8f2792041214125637459c71@mail.gmail.com> Date: Tue, 14 Dec 2004 15:56:26 -0500 From: Josh Kayse To: freebsd-net@freebsd.org In-Reply-To: <7c8f279204121411275ad919f9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41BEF2AF.470F9079@freebsd.org> <7c8f279204121411275ad919f9@mail.gmail.com> Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gtg062h@mail.gatech.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 20:57:18 -0000 On Tue, 14 Dec 2004 14:27:01 -0500, Josh Kayse wrote: > As someone who is quite new to all of this, take my thoughts with a > grain of salt. That being said, this is my view on the matter. > > On Tue, 14 Dec 2004 15:03:27 +0100, Andre Oppermann wrote: > > Let's take a high level view of the issue at hand and the consider > > some alternative approaches to the situation. > > > > Current situation: > > > Implementation approaches: > > > > d1. The PFIL_HOOKS API has one hook per direction per protocol and > > passes the interface information to the firewall package. > > d2. Should the PFIL_HOOKS API be changed and be per interface instead > > of per protocol? All firewall packages need to be modified and > > we are no longer compatible with the PFIL_HOOKS API. > > I don't think so because as has been said, the PFIL_HOOKS API provides > all the needed information. > > > d3. Should the interface specific rules sets be per firewall package > > in the way that best suits the package? No kernel API is changed. > > d4. What is the user interface syntax and semantics for each firewall > > package that someone wants to be modified? Provide examples for > > those you are interested in. > > d5. Should it be a replica of Cisco|Juniper approaches or can we do > > better in syntax or semantics? Think outside of the box. > > > > Lets continue the discussion from here. > > > > -- > > Andre > > _______________________________________________ > > I'm spreaking of d3. > I think so as it would be the best change, in my oblivious opinion. I > would see it as the firewall package receives the mbuf, checks the > interface, if it is processing rules on the interface, or if there is > a global set of rules, to then continue processing the packet. If it > isn't, it should just return/get out, whatever. I do believe this > would require a change in rule processing. The firewall package would > keep track of the different 'chains' for the rulesets. > > As far as writing rules go, I think that it would be simple to make a > script that takes a set of firewall configuration rulesets and merges > them so that they do not collide. I think it take more work to get it > to make it pretty, but I don't see it being impossible. > > I'm sure that I'm not understanding exactly what the problem is, so > please, let me know what I'm missing, thanks. > > -- > Joshua Kayse > Computer Engineering > -- Joshua Kayse Computer Engineering From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 21:36:59 2004 Return-Path: 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 C91D916A4CE; Tue, 14 Dec 2004 21:36:59 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABA4543D64; Tue, 14 Dec 2004 21:36:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 8A1A67A403; Tue, 14 Dec 2004 13:36:59 -0800 (PST) Message-ID: <41BF5CFB.90609@elischer.org> Date: Tue, 14 Dec 2004 13:36:59 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andre Oppermann References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <1103017203.1060.25.camel@localhost> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <1103040032.1060.72.camel@localhost> <1103042558.1060.82.camel@localhost> <41BF1B44.E3C1453E@freebsd.org> In-Reply-To: <41BF1B44.E3C1453E@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: vova@fbsd.ru cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 21:36:59 -0000 Andre Oppermann wrote: >Hence you need a ng_ipfw node to plug in between. Should be easy for >Gleb to write one. > One has existed for several years, bu tit hasn't been integrated for various reasons ( and probably laziness on my part) > > From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 21:59:08 2004 Return-Path: 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 A784D16A4CE; Tue, 14 Dec 2004 21:59:08 +0000 (GMT) Received: from poczta.o2.pl (mx.go2.pl [193.17.41.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DFD443D5F; Tue, 14 Dec 2004 21:59:07 +0000 (GMT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP id 7C258137788; Tue, 14 Dec 2004 22:59:04 +0100 (CET) Message-ID: <003501c4e228$5f2cd780$df5561d9@ALFA> From: "Heinz Knocke" To: , , Date: Tue, 14 Dec 2004 23:00:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Marvell 88E8001 on sk0 and RELENG_5_3 - big problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 21:59:08 -0000 Hi! Marvell's chip is not in supported nics section of 5_3 release notes, = but in man sk is , so I decided to write.=20 I've got some boxes with Marvell Gigabit NICs on-board (Gigabyte and = ASUS). Sadly, I can't be happy with it and freebsd 5.3 because of the = following two problems: a) sk0 driver seems to have some kind of bug in it - see = http://www.freebsd.org/cgi/query-pr.cgi?pr=3D71229 Does anybody know how is the work going on with it? I know that under = Linux they'd had some troubles with these NICs too, standard sk98lin = module didn't work properly and there was a vendors patch needed. Marvel = doesn't support FreeBSD, but maybe Windows NDIS2 will work?:=20 http://www.marvell.com/drivers/driverDisplay.do?dId=3D113&pId=3D16 . I = can do some tests, but let me know if it's not totaly useless (some tips = how to make it work would be helpfull to :)=20 b) according to the vendor's info, NIC should be able to do jumboframes. = (http://www.marvell.com/products/pcconn/yukon/Yukon_88E8001_10_073103_fin= al.pdf) ifconfig mtu 9000 works, but packets seems to come truncated (in both = directions) host1% sudo ping -s 2000 host2 PING host2 (10.10.10.2): 2000 data bytes ^C --- host2 ping statistics --- 23 packets transmitted, 0 packets received, 100% packet loss host2% sudo tcpdump -i sk0 -c 30 tcpdump: verbose output suppressed, use -v or -vv for full protocol = decode listening on sk0, link-type EN10MB (Ethernet), capture size 96 bytes 22:23:23.514150 IP truncated-ip - 524 bytes missing! dyplom1g > = dyplom2g: icmp 2008: echo request seq 3 22:23:24.524147 IP truncated-ip - 524 bytes missing! dyplom1g > = dyplom2g: icmp 2008: echo request seq 4 22:23:25.534282 IP truncated-ip - 524 bytes missing! dyplom1g > = dyplom2g: icmp 2008: echo request seq 5 22:23:26.544280 IP truncated-ip - 524 bytes missing! dyplom1g > = dyplom2g: icmp 2008: echo request seq 6 ^C Does anybody know what's going on?? Are a) and b) all the same big = Marvel problem :)) ?=20 Honestly said I don't know how to track it further, because the link = layer (hardware or the driver) seems just to clip frames. If there's not = enought info for the solution please tell me what tests can I do - I'll = do it ASAP.=20 I'd appreciate you support as usual :)) hk From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 22:10:10 2004 Return-Path: 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 A911016A4CE; Tue, 14 Dec 2004 22:10:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D703C43D5D; Tue, 14 Dec 2004 22:10:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 93B431FF9AD; Tue, 14 Dec 2004 23:10:07 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id A225D1FF931; Tue, 14 Dec 2004 23:10:05 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id DD3CE1539E; Tue, 14 Dec 2004 22:06:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id DACA215336; Tue, 14 Dec 2004 22:06:31 +0000 (UTC) Date: Tue, 14 Dec 2004 22:06:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Heinz Knocke In-Reply-To: <003501c4e228$5f2cd780$df5561d9@ALFA> Message-ID: References: <003501c4e228$5f2cd780$df5561d9@ALFA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org cc: freebsd-stable@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Marvell 88E8001 on sk0 and RELENG_5_3 - big problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 22:10:10 -0000 On Tue, 14 Dec 2004, Heinz Knocke wrote: Hi, [sk(4) problems] > Honestly said I don't know how to track it further, because > the link layer (hardware or the driver) seems just to clip > frames. If there's not enought info for the solution please > tell me what tests can I do - I'll do it ASAP. > > I'd appreciate you support as usual :)) please cvsup to latest RLEENG_5; I MFCed the fixes earlier today. If you have any more problems afterwards please let me know. See the archives for more information (mostly amd64 and current). PS: overlong line wrapped and Reply-To: set to avoid massive crossposting;) -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 23:40:59 2004 Return-Path: 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 B75E716A4CE; Tue, 14 Dec 2004 23:40:57 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD2743D53; Tue, 14 Dec 2004 23:40:57 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id D6EA1255975; Wed, 15 Dec 2004 00:40:54 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 9521340BB; Wed, 15 Dec 2004 00:41:03 +0100 (CET) Date: Wed, 15 Dec 2004 00:41:03 +0100 From: Jeremie Le Hen To: Gleb Smirnoff Message-ID: <20041214234102.GF740@obiwan.tataz.chchile.org> References: <20041213124051.GB32719@cell.sick.ru> <41BDABFB.E64C0A31@freebsd.org> <20041213184700.GA37107@cell.sick.ru> <41BE0E89.AE21445@freebsd.org> <20041214091652.GE42820@cell.sick.ru> <41BEE50E.6AA4FA4@freebsd.org> <20041214132031.GB46386@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041214132031.GB46386@cell.sick.ru> User-Agent: Mutt/1.5.6i cc: mlaier@freebsd.org cc: Andre Oppermann cc: net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 23:41:00 -0000 On Tue, Dec 14, 2004 at 04:20:31PM +0300, Gleb Smirnoff wrote: >>> ipfw syntax will be 100% backward compatible. The following keywords would >>> be added: >>> >>> ipfw chain list - list configured chains >>> ipfw chain add | delete - delete, remove chain >>> ipfw chain _number_ [common rule definition] - add/delete rules to >>> non-default chain >>> >>> It would be possible to attach chains to interfaces specifing also >>> direction. It will be done with ifconfig, or a specific utility (not yet >>> decided). >> >> Why don't you specify the interface directly in the syntax? That would be >> more in line with ease of use instead of having yet another logical >> indirection? >> >> ipfw fxp0 add permit ip from any to any > > Because one chain may be used for several interfaces. One can be used for > ng_pfil node. One can be not used at all, but it is hanging there, so that > it can replace the one used by interface (this is what bms requested for > XORP). If you introduce this kind of logical indirection, why would you restrict these chains to be used only if the interface matched ? I mean that any of available packet-filter matches (src or dst ip, proto, ports, TCP flags or even ttl...) may be used as a requirement to reach this chain. This is how the Linux NetFilter framework is designed [1]. Quote from Linux iptables(8) manual page [2] : << Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains. Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that matches. This is called a `target', which may be a jump to a user-defined chain in the same table. >> Note that I am not saying that NetFilter is better (I would be silly to do it here ;-)), but nevertheless it may have some interesting ideas to consider while talking about extending FreeBSD firewall framework, IMHO. [1] http://www.docum.org/docum.org/kptd/ [2] http://sman.informatik.htw-dresden.de/man/ALL/iptables.html#sect2 Regards, -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 23:59:14 2004 Return-Path: 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 48D8016A4CE for ; Tue, 14 Dec 2004 23:59:14 +0000 (GMT) Received: from dauntless.milewski.org (dauntless.milewski.org [64.142.38.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E5043D48 for ; Tue, 14 Dec 2004 23:59:14 +0000 (GMT) (envelope-from n6mod@milewski.org) Received: by dauntless.milewski.org (Postfix, from userid 8) id 8ECD05F158; Tue, 14 Dec 2004 15:58:43 -0800 (PST) X-Scanned-By: AMaViS at dauntless.milewski.org. Received: from [192.168.1.179] (adsl-64-142-38-164.sonic.net [64.142.38.164]) by dauntless.milewski.org (Postfix) with ESMTP id E1ADB5F15A for ; Tue, 14 Dec 2004 15:58:34 -0800 (PST) Message-ID: <41BF7E28.6050106@milewski.org> Date: Tue, 14 Dec 2004 15:58:32 -0800 From: Aleksandr Milewski User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bge(4) on BCM5751 won't do 1000BaseTX X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 23:59:14 -0000 I just built a 5.3RELEASE machine out of a Gigabyte GA-8I915P Duo Pro, which has two BCM5751 chips on board. These interfaces come up at 1000BaseTX according to the link lights on my switches, but drop back to 100BaseTX/full-duplex when the bge driver loads. ifconfig bge0 media 1000baseTX results in no carrier/no link. link0 doesn't seem to have any effect. I'm open to suggestions, the point of this was to build a gigabit Dummynet box. Some output follows. dmesg: bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfa100000 miibus0: on bge0 ukphy0: on miibus0 ukphy0: OUI 0x000818, model 0x0018, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FD X, auto bge0: bpf attached bge0: Ethernet address: 00:0f:ea:37:32:04 bge0: [MPSAFE] [snipped detecting pci3] bge1: mem 0xfa000000-0xfa0 0ffff irq 19 at device 0.0 on pci3 bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfa000000 miibus1: on bge1 ukphy1: on miibus1 ukphy1: OUI 0x000818, model 0x0018, rev. 0 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FD X, auto bge1: bpf attached bge1: Ethernet address: 00:0f:ea:37:32:05 bge1: [MPSAFE] gig# ifconfig bge0 bge0: flags=8843 mtu 1500 options=1a inet 192.168.2.90 netmask 0xffffff00 broadcast 192.168.2.255 inet6 fe80::20f:eaff:fe37:3204%bge0 prefixlen 64 scopeid 0x1 ether 00:0f:ea:37:32:04 media: Ethernet autoselect (100baseTX ) status: active gig# ifconfig bge1 bge1: flags=8843 mtu 1500 options=1a inet 192.168.3.90 netmask 0xffffff00 broadcast 192.168.3.255 inet6 fe80::20f:eaff:fe37:3205%bge1 prefixlen 64 scopeid 0x2 ether 00:0f:ea:37:32:05 media: Ethernet autoselect (100baseTX ) status: active gig# ifconfig bge1 media 1000baseTX gig# ifconfig bge1 bge1: flags=8843 mtu 1500 options=1a inet 192.168.3.90 netmask 0xffffff00 broadcast 192.168.3.255 inet6 fe80::20f:eaff:fe37:3205%bge1 prefixlen 64 scopeid 0x2 ether 00:0f:ea:37:32:05 media: Ethernet 1000baseTX status: no carrier From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 00:50:14 2004 Return-Path: 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 2CC3916A4CF for ; Wed, 15 Dec 2004 00:50:14 +0000 (GMT) Received: from dauntless.milewski.org (dauntless.milewski.org [64.142.38.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7EAB43D31 for ; Wed, 15 Dec 2004 00:50:13 +0000 (GMT) (envelope-from n6mod@milewski.org) Received: by dauntless.milewski.org (Postfix, from userid 8) id 69D505F163; Tue, 14 Dec 2004 16:50:10 -0800 (PST) X-Scanned-By: AMaViS at dauntless.milewski.org. Received: from [192.168.1.179] (adsl-64-142-38-164.sonic.net [64.142.38.164]) by dauntless.milewski.org (Postfix) with ESMTP id C0E455EF57; Tue, 14 Dec 2004 16:50:07 -0800 (PST) Message-ID: <41BF8A3D.9050502@milewski.org> Date: Tue, 14 Dec 2004 16:50:05 -0800 From: Aleksandr Milewski User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Milewski References: <41BF7E28.6050106@milewski.org> In-Reply-To: <41BF7E28.6050106@milewski.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: bge(4) on BCM5751 won't do 1000BaseTX X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 00:50:14 -0000 Answering (maybe) my own question, it looks like the changes to miidevs and brgphy didn't make the 5.3 cut, even though the changes to bge did. Will advise. Aleksandr Milewski wrote: > I just built a 5.3RELEASE machine out of a Gigabyte GA-8I915P Duo Pro, > which has two BCM5751 chips on board. > > These interfaces come up at 1000BaseTX according to the link lights on > my switches, but drop back to 100BaseTX/full-duplex when the bge driver > loads. > > ifconfig bge0 media 1000baseTX results in no carrier/no link. > > link0 doesn't seem to have any effect. > > I'm open to suggestions, the point of this was to build a gigabit > Dummynet box. > > Some output follows. > > dmesg: > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfa100000 > miibus0: on bge0 > ukphy0: on miibus0 > ukphy0: OUI 0x000818, model 0x0018, rev. 0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FD > X, auto > bge0: bpf attached > bge0: Ethernet address: 00:0f:ea:37:32:04 > bge0: [MPSAFE] > [snipped detecting pci3] > bge1: mem > 0xfa000000-0xfa0 > 0ffff irq 19 at device 0.0 on pci3 > bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfa000000 > miibus1: on bge1 > ukphy1: on miibus1 > ukphy1: OUI 0x000818, model 0x0018, rev. 0 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FD > X, auto > bge1: bpf attached > bge1: Ethernet address: 00:0f:ea:37:32:05 > bge1: [MPSAFE] > > > gig# ifconfig bge0 > bge0: flags=8843 mtu 1500 > options=1a > inet 192.168.2.90 netmask 0xffffff00 broadcast 192.168.2.255 > inet6 fe80::20f:eaff:fe37:3204%bge0 prefixlen 64 scopeid 0x1 > ether 00:0f:ea:37:32:04 > media: Ethernet autoselect (100baseTX ) > status: active > gig# ifconfig bge1 > bge1: flags=8843 mtu 1500 > options=1a > inet 192.168.3.90 netmask 0xffffff00 broadcast 192.168.3.255 > inet6 fe80::20f:eaff:fe37:3205%bge1 prefixlen 64 scopeid 0x2 > ether 00:0f:ea:37:32:05 > media: Ethernet autoselect (100baseTX ) > status: active > gig# ifconfig bge1 media 1000baseTX > gig# ifconfig bge1 > bge1: flags=8843 mtu 1500 > options=1a > inet 192.168.3.90 netmask 0xffffff00 broadcast 192.168.3.255 > inet6 fe80::20f:eaff:fe37:3205%bge1 prefixlen 64 scopeid 0x2 > ether 00:0f:ea:37:32:05 > media: Ethernet 1000baseTX > status: no carrier > > > _______________________________________________ > 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-net@FreeBSD.ORG Wed Dec 15 02:47:16 2004 Return-Path: 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 80E6E16A4CE for ; Wed, 15 Dec 2004 02:47:16 +0000 (GMT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B19243D1D for ; Wed, 15 Dec 2004 02:47:16 +0000 (GMT) (envelope-from pldrouin@pldrouin.net) Received: from [24.200.176.90] by VL-MO-MR010.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I8Q006C9SZ5NZ@VL-MO-MR010.ip.videotron.ca> for freebsd-net@freebsd.org; Tue, 14 Dec 2004 21:45:05 -0500 (EST) Date: Tue, 14 Dec 2004 21:45:05 -0500 From: Pierre-Luc Drouin To: freebsd-net@freebsd.org Message-id: <41BFA531.90001@pldrouin.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041110 Subject: TCP/IP over USB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 02:47:16 -0000 Hi, I would like to establish a TCP/IP connection over USB between my FreeBSD box and my PDA (Sharp Zaurus SL-6000L) that has a USB host port. I've read that udbp can be used for this purpose, but I have not found enough information about it to be able to use it. Could someone explain me how this can be done? Thank you! From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 03:24:15 2004 Return-Path: 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 B8C7716A4CE for ; Wed, 15 Dec 2004 03:24:15 +0000 (GMT) Received: from dauntless.milewski.org (dauntless.milewski.org [64.142.38.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D3C443D53 for ; Wed, 15 Dec 2004 03:24:15 +0000 (GMT) (envelope-from n6mod@milewski.org) Received: by dauntless.milewski.org (Postfix, from userid 8) id 317925F186; Tue, 14 Dec 2004 19:23:51 -0800 (PST) X-Scanned-By: AMaViS at dauntless.milewski.org. Received: from [192.168.1.179] (adsl-64-142-38-164.sonic.net [64.142.38.164]) by dauntless.milewski.org (Postfix) with ESMTP id C85485ED19; Tue, 14 Dec 2004 19:23:49 -0800 (PST) Message-ID: <41BFAE43.8090406@milewski.org> Date: Tue, 14 Dec 2004 19:23:47 -0800 From: Aleksandr Milewski User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Milewski References: <41BF7E28.6050106@milewski.org> <41BF8A3D.9050502@milewski.org> In-Reply-To: <41BF8A3D.9050502@milewski.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: bge(4) on BCM5751 won't do 1000BaseTX X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 03:24:15 -0000 Aleksandr Milewski wrote: > Answering (maybe) my own question, it looks like the changes to miidevs > and brgphy didn't make the 5.3 cut, even though the changes to bge did. > > Will advise. > That was it. Pulled in miidevs, brgphy.c, brgphyreg.h from HEAD bge0: gigabit link up bge1: gigabit link up And there was much rejoicing. :) From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 06:56:03 2004 Return-Path: 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 131E916A4CE for ; Wed, 15 Dec 2004 06:56:03 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A612043D1D for ; Wed, 15 Dec 2004 06:56:02 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])iBF6tuGr160254; Wed, 15 Dec 2004 01:56:01 -0500 Message-ID: <41BFDFFB.9030709@elischer.org> Date: Tue, 14 Dec 2004 22:55:55 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Pierre-Luc Drouin References: <41BFA531.90001@pldrouin.net> In-Reply-To: <41BFA531.90001@pldrouin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: TCP/IP over USB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 06:56:03 -0000 Pierre-Luc Drouin wrote: > Hi, > > I would like to establish a TCP/IP connection over USB between my > FreeBSD box and my PDA (Sharp Zaurus SL-6000L) that has a USB host port. > I've read that udbp can be used for this purpose, but I have not found > enough information about it to be able to use it. Could someone explain > me how this can be done? > > Thank you! > _______________________________________________ > 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" there are some devices that allow you to connect two host ports together.. one such is mentionned in teh udbp man page I think. Both sides need to know how to use this device. I don't think teh sharp and FreeBSD would agree on teh protocol to use.. From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 08:18:21 2004 Return-Path: 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 4955016A4CE; Wed, 15 Dec 2004 08:18:21 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6950C43D41; Wed, 15 Dec 2004 08:18:20 +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 iBF8ICjR088340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Dec 2004 11:18:13 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBF8IBwB053600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2004 11:18:12 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBF8IAa9053599; Wed, 15 Dec 2004 11:18:10 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2004 11:18:10 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041215081810.GA53509@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andre Oppermann , vova@fbsd.ru, Luigi Rizzo , freebsd-net@freebsd.org References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41BF008D.AD79C9B@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: vova@fbsd.ru cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:18:21 -0000 On Tue, Dec 14, 2004 at 04:02:37PM +0100, Andre Oppermann wrote: A> > џ ??, 14/12/2004 ? 13:54 +0100, Andre Oppermann ?????: A> > > It's about HOW to implement it. I think the ways proposed so far are A> > > hackish, too complex and outside of our framework which was very well A> > > designed and allows this kind of feature without any of the hacks and A> > > extentions discussed here. A> > > A> > > We have to properly DESIGN these feature instead of just hacking them A> > > in. A> > A> > Well, I agree, that it is about how to design it. A> > But I do not think that proposed solution is hackish, and I not alone A> > with it. A> A> It breaks the PFIL_HOOKS API. None of prototypes in pfil.h are changed. Where is API breakage? You call "API breakage" the fact that I'm going to *use* this API not the way you use it. A> > Let's imagine our firewall framework as general firewall, able to be A> > plugged on different layers, after that you can get following: A> > A> > 1. Plug firewall (dedicated chain) between netgraph nodes A> A> [Doesn't work before and after PFIL_HOOKS API breakage. You'd need a A> ipfw netgraph node for that anyway.] Yes, that would be a node holging pfil_head and registering filters on it. A> > 2. Plug firewall on any specific interface A> > 3. Plug firewall on any network packet processing input/output (current) A> > 4. Plug it into bridging code A> A> How do you represent this complexity in syntax and semantics? Haven't I described in one of yesterdays emails? A> With cloned devices you have a problem anyway. Who puts the correct A> ipfw chain head pointer into struct ifnet in your example? devd perhaps? A> A> Please enlighten me. Sorry, but the short answer is "same was as in Cisco|Juniper world". The longer description is: The cloner will. If this was sysadmin with ifconfig in his hands, then he will attach chains to interface. The same was you do it "config term" mode. If that was an interface auto created by ppp/mpd/etc, than the soft will do attach chains according to its config file, the same way as you have interface templates in router-world. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 08:45:46 2004 Return-Path: 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 542DA16A4CF; Wed, 15 Dec 2004 08:45:46 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8175A43D46; Wed, 15 Dec 2004 08:45:45 +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 iBF8jgaj089019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Dec 2004 11:45:43 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBF8jgp6053764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2004 11:45:42 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBF8jfYE053763; Wed, 15 Dec 2004 11:45:41 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2004 11:45:40 +0300 From: Gleb Smirnoff To: James Message-ID: <20041215084540.GB53509@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , James , Andre Oppermann , Luigi Rizzo , freebsd-net@freebsd.org, Max Laier References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> <41BF07A3.8F1F505E@freebsd.org> <20041214181231.GA80817@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041214181231.GA80817@scylla.towardex.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: Luigi Rizzo cc: Andre Oppermann cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:45:46 -0000 On Tue, Dec 14, 2004 at 01:12:31PM -0500, James wrote: J> The way we have approached this in the past is to install /32 host routes J> for each interface addr's and respective subnet and broadcast /32 addresses J> into the kernel RIB, destined to lo0 interface. Place your per-interface J> filter on 'lo0' interface and packets destined to router iteslf will be J> subject to loopback filter before making it onto upper layer protocol. I was thinking of this idea, too. So, it works? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 08:49:13 2004 Return-Path: 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 0380916A4E0; Wed, 15 Dec 2004 08:49:12 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFB0943D2F; Wed, 15 Dec 2004 08:49:09 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 636002F944; Wed, 15 Dec 2004 03:49:09 -0500 (EST) Date: Wed, 15 Dec 2004 03:49:09 -0500 From: James To: Gleb Smirnoff , Andre Oppermann , Luigi Rizzo , freebsd-net@freebsd.org, Max Laier Message-ID: <20041215084909.GA44268@scylla.towardex.com> References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> <41BF07A3.8F1F505E@freebsd.org> <20041214181231.GA80817@scylla.towardex.com> <20041215084540.GB53509@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041215084540.GB53509@cell.sick.ru> User-Agent: Mutt/1.4.1i Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:49:14 -0000 On Wed, Dec 15, 2004 at 11:45:40AM +0300, Gleb Smirnoff wrote: > On Tue, Dec 14, 2004 at 01:12:31PM -0500, James wrote: > J> The way we have approached this in the past is to install /32 host routes > J> for each interface addr's and respective subnet and broadcast /32 addresses > J> into the kernel RIB, destined to lo0 interface. Place your per-interface > J> filter on 'lo0' interface and packets destined to router iteslf will be > J> subject to loopback filter before making it onto upper layer protocol. > > I was thinking of this idea, too. So, it works? It works indeed. If folks want me to, I'll provide patches to ip_fastfwd.c after christmas-new-year break. (I have too much stuff on my plate right now) Just to note, the patch will _not_ touch ip_input.c. Receive path should not even exist on a host system, only on a router running hard core routing code (aka ip_fastforward() being the routing code). -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 08:58:34 2004 Return-Path: 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 9F6B716A4CE; Wed, 15 Dec 2004 08:58:34 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BF6143D31; Wed, 15 Dec 2004 08:58:34 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 515A02F944; Wed, 15 Dec 2004 03:58:34 -0500 (EST) Date: Wed, 15 Dec 2004 03:58:34 -0500 From: James To: Gleb Smirnoff , Andre Oppermann , vova@fbsd.ru, Luigi Rizzo , freebsd-net@freebsd.org Message-ID: <20041215085834.GA50426@scylla.towardex.com> References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <20041215081810.GA53509@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041215081810.GA53509@cell.sick.ru> User-Agent: Mutt/1.4.1i Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 08:58:34 -0000 On Wed, Dec 15, 2004 at 11:18:10AM +0300, Gleb Smirnoff wrote: [ snip ] > > Sorry, but the short answer is "same was as in Cisco|Juniper world". The longer > description is: > > The cloner will. If this was sysadmin with ifconfig in his hands, then he > will attach chains to interface. The same was you do it "config term" mode. > If that was an interface auto created by ppp/mpd/etc, than the soft will do > attach chains according to its config file, the same way as you have > interface templates in router-world. This is not a matter of Cisco-copy or Juniper-copy -- any properly operating router vendor with service provider featureset would implement per-interface firewall hooks (including us). I simply disagreed with the ipfw modification (btw it was my personal disagreement, not a constructive one), but not Gleb's idea. In my ideal world of things, I'd rather have per-interface hooked firewalls operating inside ip_fastforward, not inside regular ip_input functions. At least in the way we modify things for our own, we insert all router-like functionalities within the ip_fastfwd.c ; ip_input.c and others are largely untouched for regular non-router host environment. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 09:11:38 2004 Return-Path: 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 DF92C16A4CE; Wed, 15 Dec 2004 09:11:38 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFAE343D45; Wed, 15 Dec 2004 09:11:37 +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 iBF9BaOL089621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Dec 2004 12:11:36 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBF9BZHB053986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2004 12:11:36 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBF9BZdS053985; Wed, 15 Dec 2004 12:11:35 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2004 12:11:35 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041215091135.GC53509@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andre Oppermann , freebsd-net@freebsd.org References: <41BEF2AF.470F9079@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41BEF2AF.470F9079@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 09:11:39 -0000 On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote: A> d1. The PFIL_HOOKS API has one hook per direction per protocol and A> passes the interface information to the firewall package. A> d2. Should the PFIL_HOOKS API be changed and be per interface instead A> of per protocol? All firewall packages need to be modified and A> we are no longer compatible with the PFIL_HOOKS API. s/API/usage/g Andre, you are the person, who is optimizing our IP stack. Can you ask this question, please: if the interface has no filters associated with it, why the hell the packets running on it would enter firewall functions? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 09:13:32 2004 Return-Path: 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 2CAD416A4CE; Wed, 15 Dec 2004 09:13:32 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45E4B43D49; Wed, 15 Dec 2004 09:13:31 +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 iBF9DUnR089647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Dec 2004 12:13:30 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBF9DTeo054022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2004 12:13:29 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBF9DTXb054021; Wed, 15 Dec 2004 12:13:29 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2004 12:13:29 +0300 From: Gleb Smirnoff To: James Message-ID: <20041215091329.GD53509@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , James , Andre Oppermann , Luigi Rizzo , freebsd-net@freebsd.org, Max Laier References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> <41BF07A3.8F1F505E@freebsd.org> <20041214181231.GA80817@scylla.towardex.com> <20041215084540.GB53509@cell.sick.ru> <20041215084909.GA44268@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20041215084909.GA44268@scylla.towardex.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: Luigi Rizzo cc: Andre Oppermann cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 09:13:32 -0000 On Wed, Dec 15, 2004 at 03:49:09AM -0500, James wrote: J> On Wed, Dec 15, 2004 at 11:45:40AM +0300, Gleb Smirnoff wrote: J> > On Tue, Dec 14, 2004 at 01:12:31PM -0500, James wrote: J> > J> The way we have approached this in the past is to install /32 host routes J> > J> for each interface addr's and respective subnet and broadcast /32 addresses J> > J> into the kernel RIB, destined to lo0 interface. Place your per-interface J> > J> filter on 'lo0' interface and packets destined to router iteslf will be J> > J> subject to loopback filter before making it onto upper layer protocol. J> > J> > I was thinking of this idea, too. So, it works? J> J> It works indeed. If folks want me to, I'll provide patches to ip_fastfwd.c J> after christmas-new-year break. (I have too much stuff on my plate right now) Please do it. J> Just to note, the patch will _not_ touch ip_input.c. Receive path should not J> even exist on a host system, only on a router running hard core routing code J> (aka ip_fastforward() being the routing code). I agree on this point (also read your another mail about ip_fastforward). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 09:13:37 2004 Return-Path: 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 E3BBE16A4F5 for ; Wed, 15 Dec 2004 09:13:37 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BE7843D55 for ; Wed, 15 Dec 2004 09:13:37 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id iBF9DNeL080104; Wed, 15 Dec 2004 18:13:24 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id iBF9D2Ge080103; Wed, 15 Dec 2004 18:13:02 +0900 (KST) (envelope-from ssw) Date: Wed, 15 Dec 2004 18:12:57 +0900 From: Sangwoo Shim To: Pierre-Luc Drouin Message-ID: <20041215091257.GA79274@neo.redjade.org> References: <41BFA531.90001@pldrouin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <41BFA531.90001@pldrouin.net> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: TCP/IP over USB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 09:13:38 -0000 FYI, I've talked to YOPY PDA(also StrongArm-based linux PDA) using udbp + ng_eiface (with minor hack, namely, add DEVICE/VENDOR ID.) This combination seems to be compatible with linux's usbnet implementation. But I've told Zaurus doesn't use standard arm linux kernel.. I think you should hack ng_eiface to set the communication. On Tue, Dec 14, 2004 at 09:45:05PM -0500, Pierre-Luc Drouin wrote: > Hi, > > I would like to establish a TCP/IP connection over USB between my > FreeBSD box and my PDA (Sharp Zaurus SL-6000L) that has a USB host port. > I've read that udbp can be used for this purpose, but I have not found > enough information about it to be able to use it. Could someone explain > me how this can be done? > > Thank you! > _______________________________________________ > 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-net@FreeBSD.ORG Wed Dec 15 09:44:12 2004 Return-Path: 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 4853316A4CE for ; Wed, 15 Dec 2004 09:44:12 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17A1343D1D for ; Wed, 15 Dec 2004 09:44:12 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id F1E9B2F944; Wed, 15 Dec 2004 04:44:11 -0500 (EST) Date: Wed, 15 Dec 2004 04:44:11 -0500 From: James To: freebsd-net@freebsd.org Message-ID: <20041215094411.GA68129@scylla.towardex.com> References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> <41BF07A3.8F1F505E@freebsd.org> <20041214181231.GA80817@scylla.towardex.com> <20041215084540.GB53509@cell.sick.ru> <20041215084909.GA44268@scylla.towardex.com> <20041215091329.GD53509@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041215091329.GD53509@cell.sick.ru> User-Agent: Mutt/1.4.1i Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 09:44:12 -0000 On Wed, Dec 15, 2004 at 12:13:29PM +0300, Gleb Smirnoff wrote: > On Wed, Dec 15, 2004 at 03:49:09AM -0500, James wrote: > J> On Wed, Dec 15, 2004 at 11:45:40AM +0300, Gleb Smirnoff wrote: > J> > On Tue, Dec 14, 2004 at 01:12:31PM -0500, James wrote: > J> > J> The way we have approached this in the past is to install /32 host routes > J> > J> for each interface addr's and respective subnet and broadcast /32 addresses > J> > J> into the kernel RIB, destined to lo0 interface. Place your per-interface > J> > J> filter on 'lo0' interface and packets destined to router iteslf will be > J> > J> subject to loopback filter before making it onto upper layer protocol. > J> > > J> > I was thinking of this idea, too. So, it works? > J> > J> It works indeed. If folks want me to, I'll provide patches to ip_fastfwd.c > J> after christmas-new-year break. (I have too much stuff on my plate right now) > > Please do it. Roger. Will post when done. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 10:38:34 2004 Return-Path: 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 5192216A4CE; Wed, 15 Dec 2004 10:38:34 +0000 (GMT) Received: from vanity.bsd.krakow.pl (vanity.bsd.krakow.pl [62.121.132.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id B446C43D5E; Wed, 15 Dec 2004 10:38:33 +0000 (GMT) (envelope-from diavul@bsd.krakow.pl) Received: from grazer-2.bsd.krakow.pl (echo7.ceti.pl [62.121.128.47]) by vanity.bsd.krakow.pl (Postfix) with ESMTP id B28FD164829; Wed, 15 Dec 2004 11:38:42 +0100 (CET) Received: by grazer-2.bsd.krakow.pl (Postfix, from userid 666) id C1324D1BF5; Wed, 15 Dec 2004 11:38:29 +0100 (CET) Date: Wed, 15 Dec 2004 11:38:29 +0100 From: Michal Belczyk To: Heinz Knocke Message-ID: <20041215103829.GD778@grazer-2.bsd.krakow.pl> References: <003501c4e228$5f2cd780$df5561d9@ALFA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003501c4e228$5f2cd780$df5561d9@ALFA> X-GPG-Key-URL: http://www.bsd.krakow.pl/diavul.gpg User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-stable@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Marvell 88E8001 on sk0 and RELENG_5_3 - big problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 10:38:34 -0000 On Tue, Dec 14, 2004 at 11:00:40PM +0100, Heinz Knocke wrote: > b) according to the vendor's info, NIC should be able to do jumboframes. (http://www.marvell.com/products/pcconn/yukon/Yukon_88E8001_10_073103_final.pdf) > > ifconfig mtu 9000 works, but packets seems to come truncated (in both directions) > > host1% sudo ping -s 2000 host2 > PING host2 (10.10.10.2): 2000 data bytes > ^C > --- host2 ping statistics --- > 23 packets transmitted, 0 packets received, 100% packet loss > > host2% sudo tcpdump -i sk0 -c 30 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on sk0, link-type EN10MB (Ethernet), capture size 96 bytes > 22:23:23.514150 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 3 > 22:23:24.524147 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 4 > 22:23:25.534282 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 5 > 22:23:26.544280 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 6 > ^C Here's the fix: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_sk.c.diff?r1=1.51&r2=1.52 -- Michal Belczyk From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 10:50:55 2004 Return-Path: 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 73DF616A4CE for ; Wed, 15 Dec 2004 10:50:55 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EDBA43D53 for ; Wed, 15 Dec 2004 10:50:54 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 34611 invoked from network); 15 Dec 2004 10:39:37 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 10:39:37 -0000 Message-ID: <41C0170F.95449D19@freebsd.org> Date: Wed, 15 Dec 2004 11:50:55 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <20041215081810.GA53509@cell.sick.ru> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: vova@fbsd.ru cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 10:50:55 -0000 Gleb Smirnoff wrote: > > On Tue, Dec 14, 2004 at 04:02:37PM +0100, Andre Oppermann wrote: > A> > џ ??, 14/12/2004 ? 13:54 +0100, Andre Oppermann ?????: > A> > > It's about HOW to implement it. I think the ways proposed so far are > A> > > hackish, too complex and outside of our framework which was very well > A> > > designed and allows this kind of feature without any of the hacks and > A> > > extentions discussed here. > A> > > > A> > > We have to properly DESIGN these feature instead of just hacking them > A> > > in. > A> > > A> > Well, I agree, that it is about how to design it. > A> > But I do not think that proposed solution is hackish, and I not alone > A> > with it. > A> > A> It breaks the PFIL_HOOKS API. > > None of prototypes in pfil.h are changed. Where is API breakage? You call > "API breakage" the fact that I'm going to *use* this API not the way you > use it. First you change the way pfil_hooks is used in a multiprotocol incompatible way. Lets have a look at ip_input(): pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL); ^^^^^^^^^^^^^^ PFIL_HOOKS is a generic API with clear semantics. You can't just replace this inet_pfil_hook with an interface specific one. That would be INET only and you'd have to do the same for IPv6, IPX and whatever other protocols may come. Secondly the stuct ifnet would have to be extended with a pfil_head pointer for every protocol family in the system. This would be non-dynamic and would require a recompile of all drivers etc. when a protocol is added or removed. Struct ifnet is not a dynamic structure. Thirdly have the modules that are hooked into the pfil_hooks no idea that they have to register multiple times with multiple chains and so on. This means that all firewall packages in FreeBSD need to be adjusted to deal with these changes, often in a non-trivial way, to continue to function. And we lose the compatibility with NetBSD where the PFIL_HOOKS API comes from. I hope you understand now that you change the PFIL_HOOKS API not in the binary or structure way but in use and semantics. So please put the PFIL_HOOKS discussion to a rest now as it simply won't happen. There are perfect alternatives to change IPFW to fit your needs within IPFW itself and with the information supplied by the PFIL_HOOKS API. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 10:52:05 2004 Return-Path: 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 8A6BB16A4D0 for ; Wed, 15 Dec 2004 10:52:05 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A625843D45 for ; Wed, 15 Dec 2004 10:52:04 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 34631 invoked from network); 15 Dec 2004 10:40:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 10:40:47 -0000 Message-ID: <41C01755.6E352422@freebsd.org> Date: Wed, 15 Dec 2004 11:52:05 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <20041214060341.A77720@xorpc.icir.org> <41BEF746.E8362858@freebsd.org> <20041214063118.B77933@xorpc.icir.org> <41BF07A3.8F1F505E@freebsd.org> <20041214181231.GA80817@scylla.towardex.com> <20041215084540.GB53509@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Max Laier cc: Luigi Rizzo cc: James cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 10:52:05 -0000 Gleb Smirnoff wrote: > > On Tue, Dec 14, 2004 at 01:12:31PM -0500, James wrote: > J> The way we have approached this in the past is to install /32 host routes > J> for each interface addr's and respective subnet and broadcast /32 addresses > J> into the kernel RIB, destined to lo0 interface. Place your per-interface > J> filter on 'lo0' interface and packets destined to router iteslf will be > J> subject to loopback filter before making it onto upper layer protocol. > > I was thinking of this idea, too. So, it works? Yes, it works. It will work better when the ARP layer 2 information is removed from the routing table. This is expected to happen fairly soon (early next year). -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 11:04:12 2004 Return-Path: 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 CAA3B16A4CE for ; Wed, 15 Dec 2004 11:04:12 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D48C243D2D for ; Wed, 15 Dec 2004 11:04:11 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 34700 invoked from network); 15 Dec 2004 10:52:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 10:52:54 -0000 Message-ID: <41C01A2C.24104876@freebsd.org> Date: Wed, 15 Dec 2004 12:04:12 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <41BEF2AF.470F9079@freebsd.org> <20041215091135.GC53509@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 11:04:12 -0000 Gleb Smirnoff wrote: > > On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote: > A> d1. The PFIL_HOOKS API has one hook per direction per protocol and > A> passes the interface information to the firewall package. > A> d2. Should the PFIL_HOOKS API be changed and be per interface instead > A> of per protocol? All firewall packages need to be modified and > A> we are no longer compatible with the PFIL_HOOKS API. > > s/API/usage/g See my previous mail why your proposal is broken by design. > Andre, you are the person, who is optimizing our IP stack. Can you ask > this question, please: if the interface has no filters associated with it, > why the hell the packets running on it would enter firewall functions? Listen Gleb, first and formost I'm cleaning up network stack from years of bolt-on hackery to make it maintainable and easily understandable and extendable again. If there is a trade-off to be made between a few CPU cycles wasted with a clean and structured design versus some hackery pseudo-optimization I'm going to do the former. This is always the more viable choice. When looking at the BSD history one thing stands out: Wherever we had a very clean, concise and documented API (for example protocol independent sockets) things started to fly. In the network area we have the protosw structure and API which allows to add any type of network protocol very easily into the kernel. This has allowed BSD to support many different network protocols. Most recently IPv6. The price to pay for the small indirection protosw has is nothing compared to the adavantages of a good and clean API design. History tells us that sticking to certain design principals pays off very well and is worth some amount of performance tradeoffs. Feel free to ask Kirk McKusick on this lession of history. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 11:57:16 2004 Return-Path: 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 71D0E16A4CE; Wed, 15 Dec 2004 11:57:16 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B487343D31; Wed, 15 Dec 2004 11:57:15 +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 iBFBvA2f092988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Dec 2004 14:57:11 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBFBvA8O055579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2004 14:57:10 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBFBv9jS055578; Wed, 15 Dec 2004 14:57:10 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2004 14:57:09 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041215115709.GK54307@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andre Oppermann , vova@fbsd.ru, Luigi Rizzo , freebsd-net@freebsd.org References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <20041215081810.GA53509@cell.sick.ru> <41C0170F.95449D19@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41C0170F.95449D19@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: vova@fbsd.ru cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 11:57:16 -0000 On Wed, Dec 15, 2004 at 11:50:55AM +0100, Andre Oppermann wrote: A> First you change the way pfil_hooks is used in a multiprotocol incompatible A> way. Lets have a look at ip_input(): A> A> pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL); A> ^^^^^^^^^^^^^^ A> A> PFIL_HOOKS is a generic API with clear semantics. You can't just replace A> this inet_pfil_hook with an interface specific one. That would be INET A> only and you'd have to do the same for IPv6, IPX and whatever other protocols A> may come. A> A> Secondly the stuct ifnet would have to be extended with a pfil_head pointer A> for every protocol family in the system. This would be non-dynamic and A> would require a recompile of all drivers etc. when a protocol is added or A> removed. Struct ifnet is not a dynamic structure. Yes, it needs to be extended. An alternative is handling a table of interfaces vs chains inside firewalls. We are speaking a lot of design, which of above designs is better? Is it going to be easy to edit all these tables when an interface is destroyed? No. Would it be possible to know which chains/filters are used on interface via ifconfig? No. Would it be possible to avoid entering firewall functions when processing interfaces without ACLs? No. So, we are changing design in strange direction, because we don't want struct ifnet to grow? In Juniper|Cisco world, the fact that ACLs are attached in configuration of interfaces, but not firewalls, gives a strong suspection that they have it in their analog of struct ifnet. A> Thirdly have the modules that are hooked into the pfil_hooks no idea that A> they have to register multiple times with multiple chains and so on. This A> means that all firewall packages in FreeBSD need to be adjusted to deal A> with these changes, often in a non-trivial way, to continue to function. I'd like to avoid autohooking here. I'd prefer to have a userland utility which allows sysadmin to hook chain X from packet filter Y to interface fxp0 direction IN, protocol IPv4. Now we have autohooking to preserve compatibility with pre-pfil firewalls. A> And we lose the compatibility with NetBSD where the PFIL_HOOKS API comes A> from. Why? We just have more places where filters can be hooked. A> I hope you understand now that you change the PFIL_HOOKS API not in the A> binary or structure way but in use and semantics. Yes. Let's call it smth different to word API. A> So please put the PFIL_HOOKS discussion to a rest now as it simply won't A> happen. There are perfect alternatives to change IPFW to fit your needs A> within IPFW itself and with the information supplied by the PFIL_HOOKS API. Ok, "simply won't happen", is the words I was awaiting for. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 12:10:37 2004 Return-Path: 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 AF7F616A4D6; Wed, 15 Dec 2004 12:10:37 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A704843D4C; Wed, 15 Dec 2004 12:10:36 +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 iBFCAY0w093228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Dec 2004 15:10:35 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBFCAYah055681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2004 15:10:34 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBFCAXfq055680; Wed, 15 Dec 2004 15:10:33 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2004 15:10:33 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041215121033.GM54307@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andre Oppermann , freebsd-net@freebsd.org References: <41BEF2AF.470F9079@freebsd.org> <20041215091135.GC53509@cell.sick.ru> <41C01A2C.24104876@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41C01A2C.24104876@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 12:10:38 -0000 On Wed, Dec 15, 2004 at 12:04:12PM +0100, Andre Oppermann wrote: A> > On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote: A> > A> d1. The PFIL_HOOKS API has one hook per direction per protocol and A> > A> passes the interface information to the firewall package. A> > A> d2. Should the PFIL_HOOKS API be changed and be per interface instead A> > A> of per protocol? All firewall packages need to be modified and A> > A> we are no longer compatible with the PFIL_HOOKS API. A> > A> > s/API/usage/g A> A> See my previous mail why your proposal is broken by design. Probably many routers are broken by design, too? A> > Andre, you are the person, who is optimizing our IP stack. Can you ask A> > this question, please: if the interface has no filters associated with it, A> > why the hell the packets running on it would enter firewall functions? A> A> Listen Gleb, first and formost I'm cleaning up network stack from years A> of bolt-on hackery to make it maintainable and easily understandable and A> extendable again. But 4.x is more STABLE than 5.x, while it has rotten design, isn't it? Moreover some things stopped working because of better design! Now we have kern/71910, kern/73129, kern/73910, plus dozens of people who do not write PR because they see these three. But we have better design. A> If there is a trade-off to be made between a few CPU cycles wasted with a A> clean and structured design versus some hackery pseudo-optimization I'm A> going to do the former. This is always the more viable choice. A> When looking at the BSD history one thing stands out: Wherever we had a A> very clean, concise and documented API (for example protocol independent A> sockets) things started to fly. In the network area we have the protosw A> structure and API which allows to add any type of network protocol very A> easily into the kernel. This has allowed BSD to support many different A> network protocols. Most recently IPv6. The price to pay for the small A> indirection protosw has is nothing compared to the adavantages of a good A> and clean API design. A> A> History tells us that sticking to certain design principals pays off very A> well and is worth some amount of performance tradeoffs. Feel free to ask A> Kirk McKusick on this lession of history. Good. I'm trying to convince you that design of attaching filters to interfaces is not mad, and we should choose it, stick to it, and be happy. Protocol level packet filters are excellent for hosts, but not for routers. You ain't say that we are building not a router platform. We are building a multipurpose platform, that's why I suggest protocol level and per-interface filters coexist. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 12:15:21 2004 Return-Path: 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 0C1EB16A4CE; Wed, 15 Dec 2004 12:15:21 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF73243D2F; Wed, 15 Dec 2004 12:15:20 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBFCFBB8085599; Wed, 15 Dec 2004 04:15:11 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBFCFBtf085598; Wed, 15 Dec 2004 04:15:11 -0800 (PST) (envelope-from rizzo) Date: Wed, 15 Dec 2004 04:15:10 -0800 From: Luigi Rizzo To: Gleb Smirnoff , Andre Oppermann , vova@fbsd.ru, freebsd-net@freebsd.org Message-ID: <20041215041510.A85138@xorpc.icir.org> References: <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <20041215081810.GA53509@cell.sick.ru> <41C0170F.95449D19@freebsd.org> <20041215115709.GK54307@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041215115709.GK54307@cell.sick.ru>; from glebius@freebsd.org on Wed, Dec 15, 2004 at 02:57:09PM +0300 Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 12:15:21 -0000 On Wed, Dec 15, 2004 at 02:57:09PM +0300, Gleb Smirnoff wrote: > On Wed, Dec 15, 2004 at 11:50:55AM +0100, Andre Oppermann wrote: ... > A> Secondly the stuct ifnet would have to be extended with a pfil_head pointer > A> for every protocol family in the system. This would be non-dynamic and > A> would require a recompile of all drivers etc. when a protocol is added or > A> removed. Struct ifnet is not a dynamic structure. > > Yes, it needs to be extended. An alternative is handling a table of > interfaces vs chains inside firewalls. We are speaking a lot of design, > which of above designs is better? Is it going to be easy to edit all these > tables when an interface is destroyed? No. Would it be possible to know > which chains/filters are used on interface via ifconfig? No. Would it be > possible to avoid entering firewall functions when processing interfaces > without ACLs? No. gleb, andre is perfectly right here. struct ifnet should have as little protocol/module specific information as possible. The correct way to design things here is that each module (ipfw, netgraph, routing, ...) which is interested to interface-specific events (such as them being created, deleted, modified, printing the module-specific info related to the interface, etc.) should register a callback with ifconfig and be notified of the event, but store the module-specific information internally. Only in this way you can have loadable modules etc without making a mess. If you are worried about replicating the code that does the lookup from the interface-id to the module-specific info, this is a valid concern but could be worked around by providing a system-wide subsystem by which a module (e.g. a firewall) asks the system "please attach to the interface a chunk of 544 bytes with ID=0xff3022a0" and then can reply to requests such as "give me the pointer to the chunk with ID=0xff3022a0 for interface fxp12" This logically implements an extension of ifnet, but without all the disadvantages of adding fields for each new protocol/module/feature. I am not sure if the event signalling from ifconfig to the interested parties is already there, but that is trivial anyways to set up. Same for the module-specific if-related lookup. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 12:35:39 2004 Return-Path: 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 9D33316A4CE for ; Wed, 15 Dec 2004 12:35:39 +0000 (GMT) Received: from doeil.securesites.net (doeil.securesites.net [204.200.195.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A0543D31 for ; Wed, 15 Dec 2004 12:35:38 +0000 (GMT) (envelope-from aheyn@jmsent.com) Received: from AREILLPC (ns.jmsent.com [66.9.27.146]) by doeil.securesites.net (8.13.1/8.12.11) with SMTP id iBFCZFaC000622 for ; Wed, 15 Dec 2004 12:35:28 GMT From: "Andrew Heyn" To: Date: Wed, 15 Dec 2004 07:36:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Quick question about the tired ipf/ipnat/"dmz"/bridge scenario X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 12:35:39 -0000 Hi, Quoting http://www.moatware.com/support/docbook/faq-bridge.html, 10.8. Why can't hosts on a NATed interface talk to hosts on a bridged interface? This frequently happens when someone wants to bridge an interface to their WAN to use it as a DMZ, and wants to put all of the hosts on their LAN interface behind a NAT. This is actually a fairly reasonable and natural thing to want to do. The problem here is that ipnat and bridging (at least as implemented in FreeBSD) don't play well together. Packets from the LAN to the DMZ go out just fine, but in the other direction, it seems like the packets arriving on the unnumbered bridge interface don't get looked up correctly in the ipnat state tables. I've managed to convince myself that solving this is Really Really Hard (TM). The irritating thing is that there's no theoretical reason why this should be difficult...it all comes down to implementation details. Is there any way at all, even with kludges, to get this to work? I'd be extremely interested if there was any to accomplish this, as specified above. Thanks, Andrew From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 12:53:51 2004 Return-Path: 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 79F7516A4CF for ; Wed, 15 Dec 2004 12:53:51 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F1EE43D5A for ; Wed, 15 Dec 2004 12:53:50 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35392 invoked from network); 15 Dec 2004 12:42:32 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 12:42:32 -0000 Message-ID: <41C033DE.B3DE1F26@freebsd.org> Date: Wed, 15 Dec 2004 13:53:50 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <20041215081810.GA53509@cell.sick.ru> <41C0170F.95449D19@freebsd.org> <20041215115709.GK54307@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: vova@fbsd.ru cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 12:53:51 -0000 Gleb Smirnoff wrote: > > On Wed, Dec 15, 2004 at 11:50:55AM +0100, Andre Oppermann wrote: > A> First you change the way pfil_hooks is used in a multiprotocol incompatible > A> way. Lets have a look at ip_input(): > A> > A> pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL); > A> ^^^^^^^^^^^^^^ > A> > A> PFIL_HOOKS is a generic API with clear semantics. You can't just replace > A> this inet_pfil_hook with an interface specific one. That would be INET > A> only and you'd have to do the same for IPv6, IPX and whatever other protocols > A> may come. > A> > A> Secondly the stuct ifnet would have to be extended with a pfil_head pointer > A> for every protocol family in the system. This would be non-dynamic and > A> would require a recompile of all drivers etc. when a protocol is added or > A> removed. Struct ifnet is not a dynamic structure. > > Yes, it needs to be extended. An alternative is handling a table of > interfaces vs chains inside firewalls. We are speaking a lot of design, > which of above designs is better? Is it going to be easy to edit all these Handling it inside firewalls is the correct design. > tables when an interface is destroyed? No. Would it be possible to know Yes, you can subscribe to the routing socket where such information of interface arrivals, departures and changes are announced. The same way routing daemons get their information. Maybe this can be extended to provide a generic call-back handler interface to avoid duplication of the parsing code for each firewall. > which chains/filters are used on interface via ifconfig? No. Would it be Which chains/filters are used on an interface is firewall package specific anyway. IPFW, PF and IPF have different semantics and syntax for this. With Sam's recent modularization changes to ifconfig it would be possible to have a module doing that via ifconfig for each of these. > possible to avoid entering firewall functions when processing interfaces > without ACLs? No. It would go into the pfil_hook chain and the firewall code would just issue a return (0). One function call. Please remember that there can be other things besides firewalls residing in a PFIL_HOOKS chain. You can implement IPSEC via a pfil hook module. These may want to run independently of your firewall passing all traffic. > So, we are changing design in strange direction, because we don't want > struct ifnet to grow? No, I'm *designing* kernel functionality compared to bolt-on hacking it. > In Juniper|Cisco world, the fact that ACLs are attached in configuration > of interfaces, but not firewalls, gives a strong suspection that they have > it in their analog of struct ifnet. So what? Are we Cisco or Juniper? Do you jump out of the window on 13th floor if your pop idol does? No, you think first. I'm not saying what Cisco|Juniper do is bad, but neither am I saying it's the one and only truth in networking. There may be better or more clever approaches. Much of what they do is based on legacy requirements especially on Cisco. We have to look at the high-level goal first, not the specific implementation of someone else. > A> Thirdly have the modules that are hooked into the pfil_hooks no idea that > A> they have to register multiple times with multiple chains and so on. This > A> means that all firewall packages in FreeBSD need to be adjusted to deal > A> with these changes, often in a non-trivial way, to continue to function. > > I'd like to avoid autohooking here. I'd prefer to have a userland utility > which allows sysadmin to hook chain X from packet filter Y to interface > fxp0 direction IN, protocol IPv4. This is firewall package specific anyway. > Now we have autohooking to preserve compatibility with pre-pfil firewalls. > > A> And we lose the compatibility with NetBSD where the PFIL_HOOKS API comes > A> from. > > Why? We just have more places where filters can be hooked. No. Modules using PFIL_HOOKS would have to be written especially for FreeBSD to deal with your new behaviour. You can't just take a module written for NetBSD and compile it on FreeBSD and vice versa. The goal of the common PFIL_HOOKS API was to make especially that possible. > A> I hope you understand now that you change the PFIL_HOOKS API not in the > A> binary or structure way but in use and semantics. > > Yes. Let's call it smth different to word API. No. > A> So please put the PFIL_HOOKS discussion to a rest now as it simply won't > A> happen. There are perfect alternatives to change IPFW to fit your needs > A> within IPFW itself and with the information supplied by the PFIL_HOOKS API. > > Ok, "simply won't happen", is the words I was awaiting for. Good. PFIL_HOOKS case closed now? -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 13:08:40 2004 Return-Path: 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 ADB3416A4CE for ; Wed, 15 Dec 2004 13:08:40 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2DC943D49 for ; Wed, 15 Dec 2004 13:08:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35483 invoked from network); 15 Dec 2004 12:57:21 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 12:57:21 -0000 Message-ID: <41C03758.D0FAD95D@freebsd.org> Date: Wed, 15 Dec 2004 14:08:40 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <41BEF2AF.470F9079@freebsd.org> <20041215091135.GC53509@cell.sick.ru> <41C01A2C.24104876@freebsd.org> <20041215121033.GM54307@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 13:08:40 -0000 Gleb Smirnoff wrote: > > On Wed, Dec 15, 2004 at 12:04:12PM +0100, Andre Oppermann wrote: > A> > On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote: > A> > A> d1. The PFIL_HOOKS API has one hook per direction per protocol and > A> > A> passes the interface information to the firewall package. > A> > A> d2. Should the PFIL_HOOKS API be changed and be per interface instead > A> > A> of per protocol? All firewall packages need to be modified and > A> > A> we are no longer compatible with the PFIL_HOOKS API. > A> > > A> > s/API/usage/g > A> > A> See my previous mail why your proposal is broken by design. > > Probably many routers are broken by design, too? I didn't say that. I said your specific implementation approach within the FreeBSD framework is broken by design. There are other design approaches that are perfectly fine within the FreeBSD framework to achieve your goals. Unfortunatly you have refused to really consider them so far. > A> > Andre, you are the person, who is optimizing our IP stack. Can you ask > A> > this question, please: if the interface has no filters associated with it, > A> > why the hell the packets running on it would enter firewall functions? > A> > A> Listen Gleb, first and formost I'm cleaning up network stack from years > A> of bolt-on hackery to make it maintainable and easily understandable and > A> extendable again. > > > > But 4.x is more STABLE than 5.x, while it has rotten design, isn't it? EINVAL comparison. > Moreover some things stopped working because of better design! Now we have > kern/71910, kern/73129, kern/73910, plus dozens of people who do not write > PR because they see these three. But we have better design. Yes, we have better design. Whereas before the code was broken with respect to correct replies from hosts doing forwarding of local IP's. Now it does this correctly at the expense of breaking something was possible before. I agree that this is a POLA violation and I will commit a proper fix shortly. Like many of us I have only so much time for FreeBSD work and having futile disussions drains a significant portion of that as of lately. > > > A> If there is a trade-off to be made between a few CPU cycles wasted with a > A> clean and structured design versus some hackery pseudo-optimization I'm > A> going to do the former. This is always the more viable choice. > > A> When looking at the BSD history one thing stands out: Wherever we had a > A> very clean, concise and documented API (for example protocol independent > A> sockets) things started to fly. In the network area we have the protosw > A> structure and API which allows to add any type of network protocol very > A> easily into the kernel. This has allowed BSD to support many different > A> network protocols. Most recently IPv6. The price to pay for the small > A> indirection protosw has is nothing compared to the adavantages of a good > A> and clean API design. > A> > A> History tells us that sticking to certain design principals pays off very > A> well and is worth some amount of performance tradeoffs. Feel free to ask > A> Kirk McKusick on this lession of history. > > Good. I'm trying to convince you that design of attaching filters to interfaces > is not mad, and we should choose it, stick to it, and be happy. I think it is commonly accepted now that per-interface firewalling is a feature we are OK with. What is not accepted so far is your implementation approach. And I am trying (as are others on this list) to convince you to rethink your approach to avoid the PFIL_HOOKS API breakage. > Protocol level packet filters are excellent for hosts, but not for routers. Fine. But depends. I am running an ISP since 1996 and haven't found the current FreeBSD approach of one rule chain better suited to my practical needs so far. Of course, if I wanted to simply take the Cisco appoach one to one I would find it difficult. On the other hand I do see advantages in having per-interface rules chains in certain cases. > You ain't say that we are building not a router platform. We are building > a multipurpose platform, that's why I suggest protocol level and per-interface > filters coexist. Yea, fine. But without changing the PFIL_HOOKS API. Changing IPFW or any other of our firewalls is fine as long as it is properly designed into their environment, semantics, syntax and their principals agree on it. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 17:14:36 2004 Return-Path: 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 F38B416A4CE for ; Wed, 15 Dec 2004 17:14:35 +0000 (GMT) Received: from neon.webfusion.co.uk (neon.webfusion.co.uk [212.67.202.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62B1443D1F for ; Wed, 15 Dec 2004 17:14:35 +0000 (GMT) (envelope-from michael.hopkins@hopkins-research.com) Received: from 83-216-132-201.markch725.adsl.metronet.co.uk ([83.216.132.201] helo=[192.168.0.5]) by neon.webfusion.co.uk with asmtp (Exim 3.36 #1) id 1CecjS-0002M7-00 for freebsd-net@freebsd.org; Wed, 15 Dec 2004 17:14:34 +0000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 15 Dec 2004 17:14:32 +0000 From: "Michael Hopkins, Hopkins Research" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Trouble making NFS work with Mac OS X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 17:14:36 -0000 Hi all I keep reading that Mac OS X is very easy to get working other machines using open standards. This is not my current experience after two fruitless days messing about with NFS, but I am no network expert so maybe I am missing something really obvious - or maybe it's the FreeBSD box that is giving the problem? Anyway, I have tried to follow all the rules; see below. NFS server on a FreeBSD 5.3 box IP: 192.168.0.2 NFS client on a Mac OS X (10.3.6) box. IP: 192.168.0.5 I want to export the /home directory on the server to the client using NFS. My username (mwh) has the same uid (501) & gid (20) on both boxes. ************************************************ Server setup: ------------- /etc/exports ------------- /home -maproot=root 192.168.0.5 {have tried different -options, not sure which is best for this situation} /etc/rc.conf contains ---------------------- nfs_client_enable="YES" nfs_reserved_port_only="NO" nfs_server_enable="YES" rpcbind_enable="YES" rpc_statd_enable="YES" amd_enable="YES" Have restarted mountd and rebooted machine to make sure all services are operating and latest /etc/exports is being used. ****************************************************** Client setup: ------------- Firewall off. Can ping and ssh to server from client so connection is fine. My directions came from these two Googled pages: http://sial.org/howto/osx/automount/ http://www.cs.dixie.edu/ldap/mac/nfs/ First tried 'Connect to Server' from Finder Apple-K with: nfs:/192.168.0.2/home nfs:/192.168.0.2 192.168.0.2/home 192.168.0.2 ...nothing. Then used NetInfo Manager to try and stay tidy and within Mac OS X idiom. Made new entity in 'mounts': ----------------------------- vfstype nfs dir /home {& /mnt, /Network/Servers } name 192.168.0.2:/home opts -b net -P -s -T {and others} No joy - server appears in Finder but accessing it shows no files. So tried automounting manually via a file as in sial.org page. $ sudo automount -m /nfs ~/auto.nfs ...where auto.nfs contains this line: Athlon-mwh -rw,bg,intr 192.168.0.2:/home This makes server icon appear in the right place in the Finder but when you try to access it you get nowhere and this appears in the system log: Dec 15 14:22:15 localhost automount[424]: automount version 57 Dec 15 14:22:59 localhost automount[424]: mount (NFSV3) 192.168.0.2:111:/home/mwh - Permission denied Dec 15 14:23:07 localhost automount[424]: mount (NFSV3) 192.168.0.2:111:/home/mwh - Permission denied Dec 15 14:23:07 localhost kernel: nfs server automount /Users/mwh/auto.nfs [424]: not responding Dec 15 14:23:19 localhost automount[424]: mount (NFSV2) 192.168.0.2:111:/home/mwh - Permission denied Dec 15 14:23:35 localhost kernel: nfs server automount /Users/mwh/auto.nfs [424]: is alive again Dec 15 14:23:35 localhost automount[424]: mount (NFSV2) 192.168.0.2:111:/home/mwh - Permission denied Dec 15 14:23:35 localhost automount[424]: Mount /nfs/Athlon-mwh status 1 $ ls /nfs/Athlon-home gives permission denied Commands from shell on client: % rpcinfo -p 192.168.0.2 program vers proto port 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100000 4 7 111 portmapper 100000 3 7 111 portmapper 100000 2 7 111 portmapper 100005 1 udp 653 mountd 100005 3 udp 653 mountd 100005 1 tcp 856 mountd 100005 3 tcp 856 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100024 1 udp 860 status 100024 1 tcp 754 status 100021 0 udp 617 nlockmgr 100021 1 udp 617 nlockmgr 100021 3 udp 617 nlockmgr 100021 4 udp 617 nlockmgr 100021 0 tcp 698 nlockmgr 100021 1 tcp 698 nlockmgr 100021 3 tcp 698 nlockmgr 100021 4 tcp 698 nlockmgr 300019 1 tcp 963 amd 300019 1 udp 609 amd Tried NFS manager from here: http://www.bresink.de/osx/NFSManager.html ...but seems a little buggy or at least very slow. Doesnt make NFS work any better. Portscan of server from client gives: Open Port: 22 ssh Open Port: 111 sunrpc Open Port: 698 olsr Open Port: 754 tell Open Port: 856 Open Port: 963 Open Port: 2049 shilp I'm now out of ideas and still not even sure if it's the client or the server that isn't setup properly. Maybe it's both! ;o) Any suggestions on what I should try or diagnostics that I can run would be greatly appreciated. Would I be better to set up netatalk and/or afpd? I have read comments that they work faster than NFS between OS X and FreeBSD - though quite honestly ease of setup and reliability is more important to me right now. If it's a good option then any hints on setup would be appreciated there too. TIA Michael P.S. Please cc to my email address. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/_/_/ Hopkins Research Ltd _/ _/ _/ _/ _/_/_/_/ _/_/_/ http://www.hopkins-research.com/ _/ _/ _/ _/ _/ _/ _/ _/ 'touch the future' _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 18:03:36 2004 Return-Path: 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 31F7E16A4CE for ; Wed, 15 Dec 2004 18:03:36 +0000 (GMT) Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by mx1.FreeBSD.org (Postfix) with SMTP id 03E8443D49 for ; Wed, 15 Dec 2004 18:03:36 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.198.174 with login) by smtp001.bizmail.yahoo.com with SMTP; 15 Dec 2004 18:03:35 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id C2E61621F; Wed, 15 Dec 2004 12:03:34 -0600 (CST) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03172-07; Wed, 15 Dec 2004 12:03:33 -0600 (CST) Received: from www.noacks.org (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 2B806614D; Wed, 15 Dec 2004 12:03:33 -0600 (CST) Received: from 69.53.57.66 (SquirrelMail authenticated user noackjr); by www.noacks.org with HTTP; Wed, 15 Dec 2004 12:03:33 -0600 (CST) Message-ID: <7589.69.53.57.66.1103133813.squirrel@69.53.57.66> In-Reply-To: References: Date: Wed, 15 Dec 2004 12:03:33 -0600 (CST) From: "Jon Noack" To: "Michael Hopkins, Hopkins Research" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at noacks.org cc: freebsd-net@freebsd.org Subject: Re: Trouble making NFS work with Mac OS X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 18:03:36 -0000 Michael Hopkins, Hopkins Research wrote: > I keep reading that Mac OS X is very easy to get working other machines > using open standards. This is not my current experience after two > fruitless days messing about with NFS, but I am no network expert so maybe > I am missing something really obvious - or maybe it's the FreeBSD box that > is giving the problem? > > Anyway, I have tried to follow all the rules; see below. > > NFS server on a FreeBSD 5.3 box IP: 192.168.0.2 > NFS client on a Mac OS X (10.3.6) box. IP: 192.168.0.5 > > I want to export the /home directory on the server to the client using > NFS. Just a wild guess without actually reading the whole email: By default FreeBSD does not create a seperate partition for /home. /home is actually a symlink to /usr/home. From the exports(5) man page: "The pathnames must not have any symbolic links in them and should not have any "." or ".." components." Therefore you may need to export /usr/home instead of /home. This works wonderfully for me (although my clients are FreeBSD as well). Jon From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 18:11:01 2004 Return-Path: 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 898DC16A4CE for ; Wed, 15 Dec 2004 18:11:01 +0000 (GMT) Received: from hotmail.com (bay103-dav9.bay103.hotmail.com [65.54.174.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D67F43D5A for ; Wed, 15 Dec 2004 18:11:01 +0000 (GMT) (envelope-from zeno_lee@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Dec 2004 10:11:00 -0800 Message-ID: Received: from 68.236.191.168 by BAY103-DAV9.phx.gbl with DAV; Wed, 15 Dec 2004 18:10:22 +0000 X-Originating-IP: [68.236.191.168] X-Originating-Email: [zeno_lee@hotmail.com] X-Sender: zeno_lee@hotmail.com From: "Zeno Lee" To: Date: Wed, 15 Dec 2004 13:10:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 15 Dec 2004 18:11:00.0563 (UTC) FILETIME=[6EA5FA30:01C4E2D1] Subject: NAT works but port redirection does not work on IPNAT and PF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 18:11:01 -0000 It seems I've somehow didn't set up my freebsd gateway properly. I am trying to use my FreeBSD server as a NAT with port redirection. NAT works fine, but when I use port redirection to redirect requests from my external interface em0 160.79.174.98:80 the request makes it to my internal web server 192.168.1.54 but the response is not being returned back out to the requester. I've tried both PF and IPFILTER and they both have the same issue. Here is my setup: Internet ----- 24.215.185.142 (External web requester) | | em0 (160.79.174.98/29) FreeBSD 5.3 STABLE (PF, ALTQ compiled, gateway_enabled) em1 (192.168.1.55/24) | | LAN -- Web Server (192.168.1.54) | |---- NAT client (192.168.1.100) access internet fine I've done the dumps and # tcpdump -n -i em0 dst host 160.79.174.98 and tcp dst port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 12:51:57.118746 IP 24.215.185.142.1343 > 160.79.174.98.80: S 2887552006:2887552006(0) win 65535 12:52:00.153017 IP 24.215.185.142.1343 > 160.79.174.98.80: S 2887552006:2887552006(0) win 65535 12:52:06.167832 IP 24.215.185.142.1343 > 160.79.174.98.80: S 2887552006:2887552006(0) win 65535 # tcpdump -n -i em1 host 192.168.1.54 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes 12:51:57.118772 IP 24.215.185.142.1343 > 192.168.1.54.80: S 2887552006:2887552006(0) win 65535 12:51:57.118967 arp who-has 192.168.1.1 tell 192.168.1.54 12:52:00.153045 IP 24.215.185.142.1343 > 192.168.1.54.80: S 2887552006:2887552006(0) win 65535 12:52:06.167855 IP 24.215.185.142.1343 > 192.168.1.54.80: S 2887552006:2887552006(0) win 65535 I don't think my port forwarding setup in IPFILTER nor PF are the cause but I've listed it just in case /etc/pf.conf nat on em0 from em1:network to any -> (em0) rdr on em0 proto tcp from any to em0 port 80 -> 192.168.1.54 port 80 My IPFILTER rule is just as simple /etc/ipnat.conf map em0 192.168.0.0/16 -> 0.0.0.0/32 portmap tcp/udp auto rdr em0 0.0.0.0/0 port 80 -> 192.168.1.54 port 80 # ipnat -l List of active MAP/Redirect filters: rdr em0 0.0.0.0/0 port 80 -> 192.168.1.54 port 80 tcp map em0 192.168.0.0/16 -> 0.0.0.0/32 portmap tcp/udp auto List of active sessions: RDR 192.168.1.54 80 <- -> 160.79.174.98 80 [24.215.185.142 1332] From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 18:18:06 2004 Return-Path: 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 EB7D616A4CF for ; Wed, 15 Dec 2004 18:18:05 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9869C43D62 for ; Wed, 15 Dec 2004 18:18:04 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id iBFII3oA074434; Wed, 15 Dec 2004 21:18:03 +0300 (MSK) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Dec 2004 21:18:03 +0300 Date: Wed, 15 Dec 2004 21:18:07 +0300 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <881219348812.20041215211807@star-sw.com> To: "Zeno Lee" In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2004 18:18:03.0879 (UTC) FILETIME=[6AF6DF70:01C4E2D2] cc: freebsd-net@freebsd.org Subject: Re: NAT works but port redirection does not work on IPNAT and PF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 18:18:06 -0000 Hello Zeno, Check your default gateway on 192.168.1.54. It seems to be 192.168.1.1 instead of 192.168.168.55: 12:51:57.118967 arp who-has 192.168.1.1 tell 192.168.1.54 Wednesday, December 15, 2004, 9:10:21 PM, Zeno Lee wrote: ZL> It seems I've somehow didn't set up my freebsd gateway properly. I am ZL> trying to use my FreeBSD server as a NAT with port redirection. NAT works ZL> fine, but when I use port redirection to redirect requests from my external ZL> interface em0 160.79.174.98:80 the request makes it to my internal web ZL> server 192.168.1.54 but the response is not being returned back out to the ZL> requester. I've tried both PF and IPFILTER and they both have the same ZL> issue. ZL> Here is my setup: ZL> Internet ----- 24.215.185.142 (External web requester) ZL> | ZL> | ZL> em0 (160.79.174.98/29) ZL> FreeBSD 5.3 STABLE (PF, ALTQ compiled, gateway_enabled) ZL> em1 (192.168.1.55/24) ZL> | ZL> | ZL> LAN -- Web Server (192.168.1.54) ZL> | ZL> |---- NAT client (192.168.1.100) access internet ZL> fine ZL> I've done the dumps and ZL> # tcpdump -n -i em0 dst host 160.79.174.98 and tcp dst port 80 ZL> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode ZL> listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes ZL> 12:51:57.118746 IP 24.215.185.142.1343 > 160.79.174.98.80: S ZL> 2887552006:2887552006(0) win 65535 ZL> 12:52:00.153017 IP 24.215.185.142.1343 > 160.79.174.98.80: S ZL> 2887552006:2887552006(0) win 65535 ZL> 12:52:06.167832 IP 24.215.185.142.1343 > 160.79.174.98.80: S ZL> 2887552006:2887552006(0) win 65535 ZL> # tcpdump -n -i em1 host 192.168.1.54 ZL> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode ZL> listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes ZL> 12:51:57.118772 IP 24.215.185.142.1343 > 192.168.1.54.80: S ZL> 2887552006:2887552006(0) win 65535 ZL> 12:51:57.118967 arp who-has 192.168.1.1 tell 192.168.1.54 ZL> 12:52:00.153045 IP 24.215.185.142.1343 > 192.168.1.54.80: S ZL> 2887552006:2887552006(0) win 65535 ZL> 12:52:06.167855 IP 24.215.185.142.1343 > 192.168.1.54.80: S ZL> 2887552006:2887552006(0) win 65535 ZL> I don't think my port forwarding setup in IPFILTER nor PF are the cause but ZL> I've listed it just in case ZL> /etc/pf.conf ZL> nat on em0 from em1:network to any -> (em0) ZL> rdr on em0 proto tcp from any to em0 port 80 -> 192.168.1.54 port 80 ZL> My IPFILTER rule is just as simple ZL> /etc/ipnat.conf ZL> map em0 192.168.0.0/16 -> 0.0.0.0/32 portmap tcp/udp auto ZL> rdr em0 0.0.0.0/0 port 80 -> 192.168.1.54 port 80 ZL> # ipnat -l ZL> List of active MAP/Redirect filters: ZL> rdr em0 0.0.0.0/0 port 80 -> 192.168.1.54 port 80 tcp ZL> map em0 192.168.0.0/16 -> 0.0.0.0/32 portmap tcp/udp auto ZL> List of active sessions: ZL> RDR 192.168.1.54 80 <- -> 160.79.174.98 80 [24.215.185.142 1332] ZL> _______________________________________________ ZL> freebsd-net@freebsd.org mailing list ZL> http://lists.freebsd.org/mailman/listinfo/freebsd-net ZL> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 19:27:00 2004 Return-Path: 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 1286016A4CE for ; Wed, 15 Dec 2004 19:27:00 +0000 (GMT) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C7CC43D48 for ; Wed, 15 Dec 2004 19:26:59 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 9162 invoked by uid 89); 15 Dec 2004 19:24:16 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 15 Dec 2004 19:24:16 -0000 Received: from 208.4.77.15 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Wed, 15 Dec 2004 12:24:16 -0700 (MST) Message-ID: <53916.208.4.77.15.1103138656.squirrel@208.4.77.15> Date: Wed, 15 Dec 2004 12:24:16 -0700 (MST) From: "Ryan Sommers" To: freebsd-java@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-net@freebsd.org Subject: OpenNMS and RELENG_5_3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 19:27:00 -0000 Has anyone been able to get OpenNMS/java/et al. to work together on 5.3? The last mention of it I see on the lists is almost 2 years old, has anyone been able to get it working (or not) since then? Just wondering if it's worth my time to attempt it. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 19:31:35 2004 Return-Path: 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 2D85216A4CE for ; Wed, 15 Dec 2004 19:31:35 +0000 (GMT) Received: from dauntless.milewski.org (dauntless.milewski.org [64.142.38.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 006D443D54 for ; Wed, 15 Dec 2004 19:31:33 +0000 (GMT) (envelope-from n6mod@milewski.org) Received: by dauntless.milewski.org (Postfix, from userid 8) id 539DB5ECAD; Wed, 15 Dec 2004 11:31:05 -0800 (PST) X-Scanned-By: AMaViS at dauntless.milewski.org. Received: from [192.168.110.112] (unknown [63.251.235.202]) by dauntless.milewski.org (Postfix) with ESMTP id D66795ECAD for ; Wed, 15 Dec 2004 11:31:02 -0800 (PST) Message-ID: <41C090F4.1070302@milewski.org> Date: Wed, 15 Dec 2004 11:31:00 -0800 From: Aleksandr Milewski User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bge (BCM5751) maxes out at 620Mb/s TX? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 19:31:35 -0000 Having pulled in some updates from HEAD to get the BCM5751 working, I am now stuck at a maximum transmit rate of about 620Mb/s. Receive works fine, I can receive at about 950Mb/s, but transmit seems limited. Same hardware (same box) under Linux does 950Mb/s each way, no problem. This is with iperf, or a simple UDP blaster tool. Also, running iperf across the box with or without dummynet suffers the same limitation. What am I doing wrong? (If the first thing on that list is "posting to the wrong list", please steer me in the right direction.) Thanks, Zandr From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 21:24:28 2004 Return-Path: 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 DEB9616A4CE for ; Wed, 15 Dec 2004 21:24:28 +0000 (GMT) Received: from a.mx.interacesso.pt (super11.nortenet.pt [212.13.35.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 323EA43D49 for ; Wed, 15 Dec 2004 21:24:27 +0000 (GMT) (envelope-from elton.machado@norteglobal.com) Received: (qmail 15990 invoked by uid 104); 15 Dec 2004 21:22:34 -0000 Received: from elton.machado@norteglobal.com by mx0.interacesso.pt by uid 101 with qmail-scanner-1.22st Clear:RC:1(212.13.50.166):. Processed in 0.206494 secs); 15 Dec 2004 21:22:34 -0000 Received: from 50-166.dial.nortenet.pt (HELO ?192.168.123.1?) (212.13.50.166) by a.mx.interacesso.pt with SMTP; 15 Dec 2004 21:22:34 -0000 Message-ID: <41C0AB8E.6040805@norteglobal.com> Date: Wed, 15 Dec 2004 21:24:30 +0000 From: Elton Machado User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4f9c6b6d04120611206e86dcdc@mail.gmail.com> In-Reply-To: <4f9c6b6d04120611206e86dcdc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 21:24:29 -0000 NiY wrote: >Greetings! I have yet to find a definitive answer on this subject, so >I was hoping someone would let me know the official way to go about >this, or if it's even possible. > >We have two ADSL services coming into out building. We would like to >use them both on one network, using a multi-homed FreeBSD box, if >possible. So the scenario would like this. > > >ADSL1----\ / -- Host > Freebsd Load Balancer / NATD ---- Switch -- Host >ADSL2----/ \ --Host > >Can it be done? > > > I have the same problem, in my case i have this scenario ADSL (Cisco 837) ------ | ------ OpenBSD Gateway or FreeBSD -- Switchs -- LAN CABLE (USR) ------- Problem is... I'm using diferent providers in eachlink, I would like to to jump from one connection to another when one fails, in best case, I would like to share traffic between then and in case of one fail all the traffic goes by only one of then. How can you get this thing woring fine? and does it is possible? ;) Tia. Elton From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 23:00:06 2004 Return-Path: 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 4828316A4CE; Wed, 15 Dec 2004 23:00:06 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 934D243D2F; Wed, 15 Dec 2004 23:00:05 +0000 (GMT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-91-37.dsl.snfc21.pacbell.net [63.201.91.37])iBFN0AMo031268; Wed, 15 Dec 2004 18:00:10 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id 3B50375E102; Wed, 15 Dec 2004 16:01:59 -0800 (PST) Date: Wed, 15 Dec 2004 16:01:59 -0800 (PST) From: Kelly Yancey To: Gleb Smirnoff In-Reply-To: <20041214130712.GA46386@cell.sick.ru> Message-ID: <20041215154837.C46745@gateway.posi.net> References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> <20041214130712.GA46386@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Luigi Rizzo cc: Andre Oppermann cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 23:00:06 -0000 On Tue, 14 Dec 2004, Gleb Smirnoff wrote: > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > A> > Implementationwise, the kernel side is evidently trivial as the > A> > original code already supports the idea of multiple chains. All > A> > you need is to extend the struct ifnet with a pointer to the chain, > A> > or use some other trick (e.g. going through ifindex) to quickly > A> > associate a chain to the input (and possibly output) interface. > A> > A> Nonononononononononononononononononononononono. > A> > A> There MUST NOT be any firewall specific pointers or other information > A> in struct ifnet or any other non-firewall private part of the kernel. > A> Otherwise the entire independence we've gained with the nice and clean > A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again. > A> > A> The whole idea of the PFIL_HOOKS is to have independend and loadable > A> firewall modules with different approaches, internal designs and so > A> on. > > The whole idea of PFIL_HOOKS is to have independend and loadable firewall > modules, which can be attached to different parts of kernel! There is no > such requirement that, pfil hooks MUST be sticked to a single entry point > in ip_input() and ip_output(). > > Pfils attached to interface belong to interface, and thus should be stored > in struct ifnet. This is the way it is done in per-interface filters. > > A> For example a way Gleb can get his way without any bickering from us > A> is by creating his own gleb-firewall module using the PFIL_HOOKS API > A> and put it into the ports tree for easy access, provided he doesn't > A> modify the PFIL_HOOKS API (which he doesn't have to). > > I am not going to create a new firewall or change PFIL_HOOKS. I'm going > to attach *the existing* pfil_hooks to a different place, to perform > filtering with *existing* firewalls. How about a generic per-interface pfil demultiplexer? That is, a module that uses the existing pfil hooks to in turn call per-interface hooks. As Luigi suggested earlier, it would be possible to use the interface index to index an array private to the multiplexer's implementation. If each element in this array had its own pfil_head, then the demultiplexer could then call pfil_run_hooks() using that list. This would allow you to have your per-interface hooks in a generic way without changing a line of existing code. It could be entirely encapsulated in kld. Provided an API to manipulate the per-interface pfil registration, you could even run different filters on different interfaces. You'de even have a chance of back-porting it to FreeBSD 5.x since you won't be changing the ifnet structure at all. Just a thought, Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/ From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 23:14:46 2004 Return-Path: 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 134EF16A4CE for ; Wed, 15 Dec 2004 23:14:46 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24A9543D41 for ; Wed, 15 Dec 2004 23:14:45 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 40290 invoked from network); 15 Dec 2004 23:03:22 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 23:03:22 -0000 Message-ID: <41C0C565.23D7053E@freebsd.org> Date: Thu, 16 Dec 2004 00:14:45 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kelly Yancey References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214015603.A75019@xorpc.icir.org> <20041214130712.GA46386@cell.sick.ru> <20041215154837.C46745@gateway.posi.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 23:14:46 -0000 Kelly Yancey wrote: > > On Tue, 14 Dec 2004, Gleb Smirnoff wrote: > > > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > > A> > Implementationwise, the kernel side is evidently trivial as the > > A> > original code already supports the idea of multiple chains. All > > A> > you need is to extend the struct ifnet with a pointer to the chain, > > A> > or use some other trick (e.g. going through ifindex) to quickly > > A> > associate a chain to the input (and possibly output) interface. > > A> > > A> Nonononononononononononononononononononononono. > > A> > > A> There MUST NOT be any firewall specific pointers or other information > > A> in struct ifnet or any other non-firewall private part of the kernel. > > A> Otherwise the entire independence we've gained with the nice and clean > > A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again. > > A> > > A> The whole idea of the PFIL_HOOKS is to have independend and loadable > > A> firewall modules with different approaches, internal designs and so > > A> on. > > > > The whole idea of PFIL_HOOKS is to have independend and loadable firewall > > modules, which can be attached to different parts of kernel! There is no > > such requirement that, pfil hooks MUST be sticked to a single entry point > > in ip_input() and ip_output(). > > > > Pfils attached to interface belong to interface, and thus should be stored > > in struct ifnet. This is the way it is done in per-interface filters. > > > > A> For example a way Gleb can get his way without any bickering from us > > A> is by creating his own gleb-firewall module using the PFIL_HOOKS API > > A> and put it into the ports tree for easy access, provided he doesn't > > A> modify the PFIL_HOOKS API (which he doesn't have to). > > > > I am not going to create a new firewall or change PFIL_HOOKS. I'm going > > to attach *the existing* pfil_hooks to a different place, to perform > > filtering with *existing* firewalls. > > How about a generic per-interface pfil demultiplexer? That is, a module > that uses the existing pfil hooks to in turn call per-interface hooks. > As Luigi suggested earlier, it would be possible to use the interface > index to index an array private to the multiplexer's implementation. > If each element in this array had its own pfil_head, then the demultiplexer > could then call pfil_run_hooks() using that list. This would allow you > to have your per-interface hooks in a generic way without changing a line > of existing code. It could be entirely encapsulated in kld. Provided an > API to manipulate the per-interface pfil registration, you could even run > different filters on different interfaces. > You'de even have a chance of back-porting it to FreeBSD 5.x since you > won't be changing the ifnet structure at all. You'd have to change all firewall packages too. Currently they are not aware of and can't deal with multiple rule chain heads. The is the second main problem of Gleb implementation proposal so far. Nothing prevents generic routines to have the demultiplexer you describe but it's use and handling has to be inside each firewall package. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 23:34:22 2004 Return-Path: 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 DB81F16A4CE; Wed, 15 Dec 2004 23:34:22 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7525F43D5D; Wed, 15 Dec 2004 23:34:22 +0000 (GMT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-91-37.dsl.snfc21.pacbell.net [63.201.91.37])iBFNYC1s003116; Wed, 15 Dec 2004 18:34:15 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (Postfix) with ESMTP id BAEC175E102; Wed, 15 Dec 2004 16:36:12 -0800 (PST) Date: Wed, 15 Dec 2004 16:36:12 -0800 (PST) From: Kelly Yancey To: Andre Oppermann In-Reply-To: <41C0C565.23D7053E@freebsd.org> Message-ID: <20041215162028.Y46745@gateway.posi.net> References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214015603.A75019@xorpc.icir.org> <20041214130712.GA46386@cell.sick.ru><41C0C565.23D7053E@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Luigi Rizzo cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2004 23:34:23 -0000 On Thu, 16 Dec 2004, Andre Oppermann wrote: > Kelly Yancey wrote: > > > > How about a generic per-interface pfil demultiplexer? That is, a module > > that uses the existing pfil hooks to in turn call per-interface hooks. > > As Luigi suggested earlier, it would be possible to use the interface > > index to index an array private to the multiplexer's implementation. > > If each element in this array had its own pfil_head, then the demultiplexer > > could then call pfil_run_hooks() using that list. This would allow you > > to have your per-interface hooks in a generic way without changing a line > > of existing code. It could be entirely encapsulated in kld. Provided an > > API to manipulate the per-interface pfil registration, you could even run > > different filters on different interfaces. > > You'de even have a chance of back-porting it to FreeBSD 5.x since you > > won't be changing the ifnet structure at all. > > You'd have to change all firewall packages too. Currently they are not > aware of and can't deal with multiple rule chain heads. The is the > second main problem of Gleb implementation proposal so far. > > Nothing prevents generic routines to have the demultiplexer you describe > but it's use and handling has to be inside each firewall package. > Absolutely. You could only use such a demultiplexer to select which interfaces filters would apply to. The issue of implementing different behavior depending on the interface (e.g. a firewall implementing per-interface rulesets) is necessarily a matter for the filter not the framework. That said, since we have 3 firewall implementations, you could use the demultiplexer to have 3 different sets of rules, each applied to a different subset of the interfaces. :) Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com "An enlightened people, and an energetic public opinion... will control and enchain the aristocratic spirit of the government." --Thomas Jefferson From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 04:49:24 2004 Return-Path: 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 307C616A4CE for ; Thu, 16 Dec 2004 04:49:24 +0000 (GMT) Received: from kazna.ru (ns.kazna.ru [195.151.219.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EEF343D1F for ; Thu, 16 Dec 2004 04:49:23 +0000 (GMT) (envelope-from dvoinikov@kazna.ru) Received: from ns (localhost.localdomain [127.0.0.1]) by kazna.ru (Postfix) with SMTP id F376250291; Thu, 16 Dec 2004 09:49:20 +0500 (YEKT) Received: from yukon.skazna.local (host33.kazna.ru [195.151.219.33]) by kazna.ru (Postfix) with ESMTP id A0F675028C for ; Thu, 16 Dec 2004 09:49:20 +0500 (YEKT) Date: Thu, 16 Dec 2004 09:49:17 +0500 From: =?ISO-8859-1?B?xOzo8vDo6SDE4u7p7ejq7uI=?= X-Priority: 3 (Normal) Message-ID: <1716213283.20041216094917@kazna.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SpamTest-Info: Profile: Formal (174/041214) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Archiving/Rejecting (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], KAS/Release Subject: Divert sockets no longer behave like connected (SS_ISCONNECTED is removed from so->so_state) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: =?ISO-8859-1?B?xOzo8vDo6SDE4u7p7ejq7uI=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 04:49:24 -0000 Hello, I'm having this application (VPN daemon) which uses divert sockets for sending stuff http://www.targeted.org/nest/ It worked fine under 5.3-RELEASE but broke after recent upgrade to FreeBSD 5.3-STABLE. An attempt to send() via divert socket now returns EDESTADDRREQ "Destination address required". Digging up the CVS revealed this: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_divert.c Quote: > Revision 1.98.2.1 / (download) - annotate - [select for diffs], Tue Nov 23 15:30:02 2004 UTC (3 weeks ago) by glebius > Branch: RELENG_5 > - Since divert protocol is not connection oriented, remove SS_ISCONNECTED flag > from divert sockets. Also relevant is this message by Gleb Smirnoff: http://www.freebsd.org/cgi/getmsg.cgi?fetch=50544+0+/usr/local/www/db/text/2004/freebsd-net/20041121.freebsd-net Quote: > So, the real change suggested is to remove SS_ISCONNECTED from so->so_state. All > other changes are its logical consequences. > What was idea of that SS_ISCONNECTED flag always set? I can't find any problems we > can get by removing this code. Well, I'm having one - my application stopped working. Also, quote from man divert: > Packets are written as either incom- > ing or outgoing: if write(2) or send(2) is used to deliver the packet > ... skip ... > then the packet is treated as if it were outgoing My case exactly, but this no longer holds. What am I supposed to do now ? Modify my application ? Actually I already did that, by switching to sendto(), but just wanted to make sure this divert sockets semantics change is intented and not spontaneous. Sincerely, Dmitry Dvoinikov http://www.targeted.org/ From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 10:07:40 2004 Return-Path: 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 4D72416A4CE for ; Thu, 16 Dec 2004 10:07:40 +0000 (GMT) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2321043D5A for ; Thu, 16 Dec 2004 10:07:39 +0000 (GMT) (envelope-from john@veidit.net) Received: from [192.168.20.33] ([213.113.142.243] [213.113.142.243]) by mxfep01.bredband.com with ESMTP id <20041216100737.WBUH18879.mxfep01.bredband.com@[192.168.20.33]> for ; Thu, 16 Dec 2004 11:07:37 +0100 Message-ID: <41C15E0B.2050503@veidit.net> Date: Thu, 16 Dec 2004 11:06:03 +0100 From: John Angelmo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a4) Gecko/20041110 X-Accept-Language: sv, en-gb, en, en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: NAT problem with public network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 10:07:40 -0000 Hello I have a network setup like this: xl0: External:213.115.251.220 xl1: DMZ: 213.115.148.64/28 xl2: Internal: 192.168.20.0/24 Now my problem seems to be that I need to get external connection for my Internal network but not nating the DMZ To simplify it all /etc/natd.conf has this line: interface xl0 and to get nat to work I just use: ipfw add divert natd log all from any to any via xl0 but that would nat all the traffic, how should I do just to use nat for my 192.168.20.0/24 network and not the 213.115.148.64/28 network? /John From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 10:50:00 2004 Return-Path: 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 F24DB16A4DC for ; Thu, 16 Dec 2004 10:49:59 +0000 (GMT) Received: from home.dino.sk (home.dino.sk [213.215.74.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E3AC43D45 for ; Thu, 16 Dec 2004 10:49:56 +0000 (GMT) (envelope-from milan@bluegrass.sk) Received: from [127.0.0.1] ([127.0.0.1]) by home.dino.sk with esmtp; Thu, 16 Dec 2004 11:49:47 +0100 id 0000E915.41C1684F.0000561F From: Milan Obuch To: freebsd-net@freebsd.org Date: Thu, 16 Dec 2004 11:49:33 +0100 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200412161149.33838.milan@bluegrass.sk> Subject: ath driver - help needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 10:50:00 -0000 Hi, I am evaluating ath driver with Senao AR5212 chip based miniPCI card. Motherboard used is Geode based WRAP. While it works well in modes 11b and 11g, performance in 11a mode I need is suboptimal, as said in man page - even worse. However, test with newer driver, albeit with linux system, works much better. I would like to test newer driver with FreeBSD too, but I did not succeed. I spent couple of hours trying to backport newer driver to 5.3, no luck yet. Has somebody done it or could help me with this? Unfortunately I have not too much time to test, I need go into production some time soon. Regards, Milan From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 11:45:29 2004 Return-Path: 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 9295916A4CE for ; Thu, 16 Dec 2004 11:45:29 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA9743D5C for ; Thu, 16 Dec 2004 11:45:28 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id iBGBjRoT017178; Thu, 16 Dec 2004 14:45:27 +0300 (MSK) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Dec 2004 14:45:26 +0300 Date: Thu, 16 Dec 2004 14:45:26 +0300 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <671282193578.20041216144526@star-sw.com> To: John Angelmo In-reply-To: <41C15E0B.2050503@veidit.net> References: <41C15E0B.2050503@veidit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2004 11:45:26.0916 (UTC) FILETIME=[BC555440:01C4E364] cc: freebsd-net@freebsd.org Subject: Re: NAT problem with public network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 11:45:29 -0000 Hello John, You can use two ways: 1. Add 'unregistered_only yes' to your natd.conf 2. Run natd on xl2 with -reverse option If I were you I would do the first one. Thursday, December 16, 2004, 1:06:03 PM, John Angelmo wrote: JA> Hello JA> I have a network setup like this: JA> xl0: External:213.115.251.220 JA> xl1: DMZ: 213.115.148.64/28 JA> xl2: Internal: 192.168.20.0/24 JA> Now my problem seems to be that I need to get external connection for my JA> Internal network but not nating the DMZ JA> To simplify it all /etc/natd.conf has this line: JA> interface xl0 JA> and to get nat to work I just use: JA> ipfw add divert natd log all from any to any via xl0 JA> but that would nat all the traffic, how should I do just to use nat for JA> my 192.168.20.0/24 network and not the 213.115.148.64/28 network? JA> /John JA> _______________________________________________ JA> freebsd-net@freebsd.org mailing list JA> http://lists.freebsd.org/mailman/listinfo/freebsd-net JA> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 12:04:20 2004 Return-Path: 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 26BCE16A4CE for ; Thu, 16 Dec 2004 12:04:20 +0000 (GMT) Received: from northgate.starhub.net.sg (northgate.starhub.net.sg [203.117.1.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27A0643D46 for ; Thu, 16 Dec 2004 12:04:19 +0000 (GMT) (envelope-from chamaras@singnet.com.sg) Received: from smtp.starhub.net.sg (cm143.omega239.maxonline.com.sg [218.186.239.143])iBGC4H9c004707 for ; Thu, 16 Dec 2004 20:04:17 +0800 (SST) To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: KC Somaratne Date: Thu, 16 Dec 2004 19:54:01 +0800 X-MIMETrack: Serialize by Notes Client on KC Somaratne/KC Somaratne(Release 6.5.3|September 14, 2004) at 16-12-2004 07:54:09 PM, Serialize complete at 16-12-2004 07:54:09 PM Content-Type: text/plain; charset="US-ASCII" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: HP NC7170 Dual Port PCI-X 1000T Gigabit Server Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 12:04:20 -0000 Hi, Is there going to be any support for the above HP EtherNet card in FreeBSD 5.3-RELEASE? Most of the HP cards listed in the hardware notes for this relase seem to be end-of-life by HP..! thnks in adv, -kc. From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 13:07:19 2004 Return-Path: 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 6BA9A16A4CE for ; Thu, 16 Dec 2004 13:07:19 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8099B43D2F for ; Thu, 16 Dec 2004 13:07:18 +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 iBGD7GZg018520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Dec 2004 16:07:16 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iBGD7Fpi065224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Dec 2004 16:07:16 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iBGD7Fre065223; Thu, 16 Dec 2004 16:07:15 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 16 Dec 2004 16:07:15 +0300 From: Gleb Smirnoff To: dvoinikov@kazna.ru Message-ID: <20041216130715.GA65090@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , dvoinikov@kazna.ru, freebsd-net@freebsd.org References: <1716213283.20041216094917@kazna.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1716213283.20041216094917@kazna.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: freebsd-net@freebsd.org Subject: Re: Divert sockets no longer behave like connected (SS_ISCONNECTED is removed from so->so_state) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 13:07:19 -0000 On Thu, Dec 16, 2004 at 09:49:17AM +0500, ??????? ????????? wrote: ?> I'm having this application (VPN daemon) which ?> uses divert sockets for sending stuff http://www.targeted.org/nest/ ?> It worked fine under 5.3-RELEASE but broke after ?> recent upgrade to FreeBSD 5.3-STABLE. ?> ?> An attempt to send() via divert socket now returns ?> EDESTADDRREQ "Destination address required". Digging ?> up the CVS revealed this: ?> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_divert.c ?> Quote: ?> > Revision 1.98.2.1 / (download) - annotate - [select for diffs], Tue Nov 23 15:30:02 2004 UTC (3 weeks ago) by glebius ?> > Branch: RELENG_5 ?> > - Since divert protocol is not connection oriented, remove SS_ISCONNECTED flag ?> > from divert sockets. ?> ?> Also relevant is this message by Gleb Smirnoff: ?> http://www.freebsd.org/cgi/getmsg.cgi?fetch=50544+0+/usr/local/www/db/text/2004/freebsd-net/20041121.freebsd-net ?> Quote: ?> > So, the real change suggested is to remove SS_ISCONNECTED from so->so_state. All ?> > other changes are its logical consequences. ?> > What was idea of that SS_ISCONNECTED flag always set? I can't find any problems we ?> > can get by removing this code. ?> ?> Well, I'm having one - my application stopped working. I'm sorry that this change hurt you. I didn't have possibility to find all divert(4) consumers. ?> Also, quote from man divert: ?> ?> > Packets are written as either incom- ?> > ing or outgoing: if write(2) or send(2) is used to deliver the packet ?> > ... skip ... ?> > then the packet is treated as if it were outgoing Yes. sosend() catches this case before entering protocol specific send method. I should update manpage. ?> My case exactly, but this no longer holds. ?> ?> What am I supposed to do now ? Modify my application ? Actually I already ?> did that, by switching to sendto(), but just wanted to make sure this ?> divert sockets semantics change is intented and not spontaneous. It was intended. Actually the protocol is not connection-oriented and addr should be supplied with each write. This was not a-clean-up-only change. We have a kernel module - ng_ksocket, which ignores destaddr for connected sockets. This lead to some problems because in divert the address is actually required. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 13:49:59 2004 Return-Path: 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 3AE1116A4CE for ; Thu, 16 Dec 2004 13:49:59 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id A214E43D2F for ; Thu, 16 Dec 2004 13:49:58 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I8T009FMIF98Z@ms-dienst.rz.rwth-aachen.de> for freebsd-net@freebsd.org; Thu, 16 Dec 2004 14:49:57 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 16 Dec 2004 14:46:14 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92])iBGDk9eG002018; Thu, 16 Dec 2004 14:46:12 +0100 (MET) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id 7532228442; Thu, 16 Dec 2004 14:46:03 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id E6C0F2281B; Thu, 16 Dec 2004 14:46:02 +0100 (CET) Date: Thu, 16 Dec 2004 14:46:02 +0100 From: Christian Brueffer In-reply-to: To: KC Somaratne Message-id: <20041216134602.GL1122@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=C01fF7hLGvN0zd9s; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: cc: freebsd-net@freebsd.org Subject: Re: HP NC7170 Dual Port PCI-X 1000T Gigabit Server Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 13:49:59 -0000 --C01fF7hLGvN0zd9s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 16, 2004 at 07:54:01PM +0800, KC Somaratne wrote: > Hi, >=20 > Is there going to be any support for the above HP EtherNet=20 > card in FreeBSD 5.3-RELEASE? >=20 > Most of the HP cards listed in the hardware notes for this > relase seem to be end-of-life by HP..! >=20 According to the HP website this card uses the Intel 82546EB chip, which is supported by the em(4) driver. The card should work out of the box on 5.3-RELEASE. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --C01fF7hLGvN0zd9s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBwZGabHYXjKDtmC0RAiw6AKC41f69cYqlqcHJmtpcPsIbW1y48ACdHf6V zaDlHMg8tr2UYmT4Dhe9wpw= =Lsrx -----END PGP SIGNATURE----- --C01fF7hLGvN0zd9s-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 14:36:26 2004 Return-Path: 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 A747916A4CE for ; Thu, 16 Dec 2004 14:36:26 +0000 (GMT) Received: from ford.blinkenlights.nl (ford.blinkenlights.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25BDD43D53 for ; Thu, 16 Dec 2004 14:36:26 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [IPv6:2001:960:301:3:a00:20ff:fe85:fa39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id F2AF93E434; Thu, 16 Dec 2004 15:36:23 +0100 (CET) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id 7F71C285; Thu, 16 Dec 2004 15:36:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id 73C84159; Thu, 16 Dec 2004 15:36:23 +0100 (CET) Date: Thu, 16 Dec 2004 15:36:23 +0100 (CET) From: Sten Spans To: KC Somaratne In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: HP NC7170 Dual Port PCI-X 1000T Gigabit Server Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 14:36:26 -0000 On Thu, 16 Dec 2004, KC Somaratne wrote: > Hi, > > Is there going to be any support for the above HP EtherNet > card in FreeBSD 5.3-RELEASE? > > Most of the HP cards listed in the hardware notes for this > relase seem to be end-of-life by HP..! Most of the hp ethernet cards are rebadged broadcoms .... -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 14:41:27 2004 Return-Path: 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 A9CC916A4CE for ; Thu, 16 Dec 2004 14:41:27 +0000 (GMT) Received: from northgate.starhub.net.sg (northgate.starhub.net.sg [203.117.1.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E47A343D49 for ; Thu, 16 Dec 2004 14:41:25 +0000 (GMT) (envelope-from chamaras@singnet.com.sg) Received: from smtp.starhub.net.sg (cm143.omega239.maxonline.com.sg [218.186.239.143])iBGEfN9c005079; Thu, 16 Dec 2004 22:41:23 +0800 (SST) In-Reply-To: <20041216134602.GL1122@unixpages.org> To: Christian Brueffer MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: KC Somaratne Date: Thu, 16 Dec 2004 22:31:04 +0800 X-MIMETrack: Serialize by Notes Client on KC Somaratne/KC Somaratne(Release 6.5.3|September 14, 2004) at 16-12-2004 10:31:16 PM, Serialize complete at 16-12-2004 10:31:16 PM Content-Type: text/plain; charset="US-ASCII" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: HP NC7170 Dual Port PCI-X 1000T Gigabit Server Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 14:41:27 -0000 Hi, Thanks for your reply. I noticed that this indeed was using the Intel 82546EB chip after sending the e-mail to the list. Anyway I can feel a bit more comfortable in getting this now! thnks n rgds -kc. Christian Brueffer wrote on 16-12-2004 09:46:02 PM: > On Thu, Dec 16, 2004 at 07:54:01PM +0800, KC Somaratne wrote: > > Hi, > > > > Is there going to be any support for the above HP EtherNet > > card in FreeBSD 5.3-RELEASE? > > > > Most of the HP cards listed in the hardware notes for this > > relase seem to be end-of-life by HP..! > > > > According to the HP website this card uses the Intel 82546EB chip, > which is supported by the em(4) driver. > > The card should work out of the box on 5.3-RELEASE. > > - Christian > > -- > Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org > GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc > GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D > [attachment "attxqtt7.dat" deleted by KC Somaratne/KC Somaratne] From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 16:01:15 2004 Return-Path: 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 AC83416A4CE for ; Thu, 16 Dec 2004 16:01:15 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E00843D58 for ; Thu, 16 Dec 2004 16:01:14 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.13.1/8.13.1) with SMTP id iBGG12X4016101; Thu, 16 Dec 2004 16:01:02 GMT (envelope-from brian@Awfulhak.org) Date: Thu, 16 Dec 2004 16:00:58 +0000 From: Brian Somers To: Mike Tancsa Message-ID: <20041216160058.7eb73254@dev.lan.Awfulhak.org> In-Reply-To: <2vmch0phgtf3028ie4447h2hruq7vdi7ac@4ax.com> References: <200407240247.i6O2lQfJ007370@dungeon.home> <200407250144.i6P1iCPx005756@dungeon.home> <41032C09.506@elischer.org> <0pfbg01araih3qekvbse5afdshf2tjf2qr@4ax.com> <4105D6A9.5020600@elischer.org> <2vmch0phgtf3028ie4447h2hruq7vdi7ac@4ax.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on gw.lan.Awfulhak.org cc: freebsd-net@freebsd.org cc: Julian Elischer Subject: Re: PPPoE problem: "Too many LQR packets lost" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 16:01:15 -0000 On Sun, 08 Aug 2004 13:01:00 -0400, Mike Tancsa wrote: > On Mon, 26 Jul 2004 21:14:33 -0700, in sentex.lists.freebsd.net you > wrote: > > >Mike Tancsa wrote: > > > >>On Sat, 24 Jul 2004 20:42:01 -0700, in sentex.lists.freebsd.net you > >>wrote: > >> > >> > >>>>>Seriously though, mine was a very ugly hack to > >>>>>get things working again for me. Most of the DSL aggregators here > >>>>>are Juniper ERXes which do not play nice with FreeBSD's PPPoE. > >>>>> > >>>>> > >>>>> > >>>any thoughts as to why? > >>> > >>>FreeBSD's pppoe is going through a little development at the moment.. > >>>Now would be a good time to get it fixed.. > >>Hi, > >>Simple LCP echos work just fine, but when using LQR things "break". > >>There are debug logs posted in the archives when I first figured out > >>what was broken. If you need another copy I am happy to post again. > >> > > > >certainly it would be useful. rather than taking potsots at the archive > >hoping to catch it.. > > > >pppoe is tricky because the responsibility for errors os split between > >the pppoe module > > and the ppp module.. > > > Just to followup for the archives sake, the latest LQR changes do not > fix the ppp/PPPoE problem with respect to the issue below. I have a > full TCPDUMP as well as ppp debug logs that illustrate the problem for > anyone interested. > > ---Mike And for the archive's sake... ppp has now grown an ``enable echo'' command (in -current). -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 20:56:38 2004 Return-Path: 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 EA95516A4CE for ; Thu, 16 Dec 2004 20:56:38 +0000 (GMT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DC9643D45 for ; Thu, 16 Dec 2004 20:56:38 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from dc1 ([66.199.170.122]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Thu, 16 Dec 2004 20:56:31 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 41C1F67F.00007B57.bigass1.bitblock.com,dns; dc1 ([66.199.170.122]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (Bitblock)" To: "'Elton Machado'" , freebsd-net@freebsd.org Date: Thu, 16 Dec 2004 12:56:32 -0800 Organization: Bitblock Systems Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41C0AB8E.6040805@norteglobal.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcTi7HsuTPLoA6qQQAm/0k6j68AvxwAxPr/w Message-ID: Subject: RE: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 20:56:39 -0000 > NiY wrote: > > >Greetings! I have yet to find a definitive answer on this subject, so > >I was hoping someone would let me know the official way to go about > >this, or if it's even possible. > > > >We have two ADSL services coming into out building. We would like to > >use them both on one network, using a multi-homed FreeBSD box, if > >possible. So the scenario would like this. > > > > > >ADSL1----\ / > -- Host > > Freebsd Load Balancer / NATD ---- Switch -- Host > >ADSL2----/ \ - > -Host > > > >Can it be done? > > I have the same problem, in my case i have this scenario > > > ADSL (Cisco 837) ------ > | ------ OpenBSD Gateway or > FreeBSD -- Switchs -- LAN > CABLE (USR) ------- > > > Problem is... I'm using diferent providers in eachlink, I would like to > to jump from one connection to another when one fails, > in best case, I would like to share traffic between then and in case of > one fail all the traffic goes by only one of then. > > How can you get this thing woring fine? and does it is possible? ;) > > Tia. > > Elton [Mitch says:] Short answer is "Yes". For basic failover, I've used a script which monitors link status and function (by pinging or connecting to a remote host). Failover is accomplished by switching the default route. Using ipfw fwd statements, you can make both links function at the same time, using pf, you can supposedly do some sort of load sharing, but I havne't used pf yet. m/ From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 21:20:07 2004 Return-Path: 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 335EC16A4CE for ; Thu, 16 Dec 2004 21:20:07 +0000 (GMT) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 831AF43D41 for ; Thu, 16 Dec 2004 21:20:06 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO cpe000103d44c07-cm000f9f7ae88c.cpe.net.cable.rogers.com) (mikej@69.193.222.195 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 16 Dec 2004 21:20:05 -0000 Received: from 207.219.213.163 (proxying for unknown) (SquirrelMail authenticated user mikej); by cpe000103d44c07-cm000f9f7ae88c.cpe.net.cable.rogers.com with HTTP; Thu, 16 Dec 2004 16:19:58 -0500 (EST) Message-ID: <45876.207.219.213.163.1103231998.squirrel@207.219.213.163> In-Reply-To: References: <41C0AB8E.6040805@norteglobal.com> Date: Thu, 16 Dec 2004 16:19:58 -0500 (EST) From: "Mike Jakubik" To: "Mitch (Bitblock)" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-net@freebsd.org cc: 'Elton Machado' Subject: RE: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 21:20:07 -0000 Mitch (Bitblock) said: > Short answer is "Yes". > > For basic failover, I've used a script which monitors link status and > function (by pinging or connecting to a remote host). Failover is > accomplished by switching the default route. > > Using ipfw fwd statements, you can make both links function at the same > time, using pf, you can supposedly do some sort of load sharing, but I > havne't used pf yet. > Why dont you all do yourselves a favor and go out and buy one of those home dsl/cable modems that have 2 ports and provide load balancing instead. From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 21:30:14 2004 Return-Path: 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 D39BA16A4CF for ; Thu, 16 Dec 2004 21:30:14 +0000 (GMT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3700343D53 for ; Thu, 16 Dec 2004 21:30:14 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from dc1 ([66.199.170.122]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Thu, 16 Dec 2004 21:30:08 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 41C1FE60.000083CF.bigass1.bitblock.com,dns; dc1 ([66.199.170.122]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (Bitblock)" To: "'Mike Jakubik'" Date: Thu, 16 Dec 2004 13:30:08 -0800 Organization: Bitblock Systems Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <45876.207.219.213.163.1103231998.squirrel@207.219.213.163> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcTjtTKOdN+aM6JfT3meEuC++S2C9gAAMlqA Message-ID: cc: freebsd-net@freebsd.org cc: 'Elton Machado' Subject: RE: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 21:30:14 -0000 > > Why dont you all do yourselves a favor and go out and buy one of those > home dsl/cable modems that have 2 ports and provide load balancing > instead. > [Mitch says:] The only ones I've seen were rather expensive and aren't modem's - they are routers... so you have to still have your ADSL modem, your cable modem, your load balancing router, which generally does a poor job, and has all kinds of limitations... Why spend $500 bucks on a load shared with an inadequate non-open source firewall that doesn't do what I want and then have to add a firewall anyways ;-) And worse, it works in NAT mode, and probably screws up ipsec, and traffic shaping too... Is that enough reasons to try building a better mousetrap? m/ From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 22:51:51 2004 Return-Path: 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 6DBA016A4CE for ; Thu, 16 Dec 2004 22:51:51 +0000 (GMT) Received: from borgtech.ca (borgtech.ca [216.187.106.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id C423643D49 for ; Thu, 16 Dec 2004 22:51:50 +0000 (GMT) (envelope-from asegu@borgtech.ca) Received: from asegulaptop (unknown [161.53.212.202]) by borgtech.ca (Postfix) with ESMTP id 30FD954C3 for ; Thu, 16 Dec 2004 22:52:50 +0000 (GMT) From: "Andrew Seguin" To: Date: Thu, 16 Dec 2004 23:51:00 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTjwbZEQOKQzSfsScqWspCg6UGulA== Message-Id: <20041216225250.30FD954C3@borgtech.ca> Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Curiosity in IPFW/Freebsd bridge. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 22:51:51 -0000 Hello, First off, a great thanks to this list who pointed out my = hardware issue (rl series cards). I now have the bridge on two Intel Pro NICS and = I use the on-board sis card for console access, and my average ping time = is a 2ms average to the router, passing about a solid 2MB/s. =20 My current situation is that it seems IPFW is filtering by IP address, = but never matching an IP address/Port number combo (ex: =93deny ip from IP = to any=94 works, but =93deny ip from IP to any 80=94 does not work). =20 The firewall rules are as follows: #1. Allow all SSH traffic until rules are down safe. ipfw add 1 allow ip from any to LOCAL_IP 22 #ipfw add 100 TEST (either =93deny ip from any to any=94 or =93deny ip = from any to any 80=94). ipfw add 500 pipe 1 ip from any to any ipfw pipe 1 config bw 20480Kbit/s default> allow ip from any to any =20 The setup is as follows in rc.conf: Ifconfig_fxp0=3D=94up=94 Ifconfig_fxp1=3D=94up=94 Ifconfig_sis0=3D=94LOCAL_IP=85=94 =20 And in sysctl.conf: net.link.ether.bridge.enable=3D1 net.link.ether.bridge.config=3Dfxp0,fxp1 net.link.ether.bridge.ipfw=3D1 =20 Kernel has been built with IPFW and DUMMYNET. Freebsd 5.3 (RELENG_5, cvsupdated and recompiled about a week ago). =20 The server was working fine when I had it filtering between two switches (secondary to primary). I was having web/email/irc traffic bypass the = pipe, and used the pipe to limit the speed of those who use P2P. Now, I have = this situation with the firewall between the main switch and the router. I really need to get this working for this purpose again fast or else = I=92ll have a repeat of an earlier =93internal=94 DoS, so any and all tips, = comments, pointers would be greatly appreciated! =20 I wonder if it is because I haven=92t assigned an IP address on the fxp = facing the inside network=85? Haven=92t had the time to try this yet (11:50pm = local time!) since I don=92t remember which fxp card is facing = internal/external and so I will try in the morning. =20 Again, many thanks! Andrew Seguin =20 =20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =20 From owner-freebsd-net@FreeBSD.ORG Thu Dec 16 23:04:55 2004 Return-Path: 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 C363416A4CE for ; Thu, 16 Dec 2004 23:04:55 +0000 (GMT) Received: from doeil.securesites.net (doeil.securesites.net [204.200.195.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0F1E43D5C for ; Thu, 16 Dec 2004 23:04:54 +0000 (GMT) (envelope-from aheyn@jmsent.com) Received: from AREILLPC (ns.jmsent.com [66.9.27.146]) by doeil.securesites.net (8.13.1/8.12.11) with SMTP id iBGN4WsR039543 for ; Thu, 16 Dec 2004 23:04:43 GMT From: "Andrew Heyn" To: Date: Thu, 16 Dec 2004 18:05:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Subject: bridging, ipf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2004 23:04:55 -0000 Hi, Here is my setup: fxp0: no ip -> switch -> (computer with ip: 200.200.200.147, gateway 200.200.200.145) ^ | bridged | \/ fxp1: 200.200.200.146, 148, 149, 150 -> -> (internet) ^ ipf/ipnat | \/ fxp2: 192.168.1.1 -> switch -> lots of computers with 192.168.1.x addresses (all use 192.168.1.1 as gw) Computers on fxp2 have no problem accessing the internet, and neither does 200.200.200.147... I am at a loss, though, at how to get a request from 192.168.1.x to successfully be natted with th e public ip on fxp1 (200.200.200.145) and access 200.200.200.147. There's no access to the bridged computer from the natted computers, and I dont know how to make it work. It seems that http://www.moatware.com/support/docbook/faq-bridge.html documents this problem and it has to do with ipnat in processing the packets returning from 200.200.200.147 on fxp0, which has no IP. Is there a rule to ipnat I can add to make the lookups on the returning packets succcessful, or another way to make it work? Would this setup also the natted computers to access the bridged computer by its public ip? fxp0: no ip -> switch -> computer with public ip ^ | bridged | \/ fxp1: no ip -> switch -> cat5 from ISP fxp2: public ip -> connected to switch fxp1 is ^ | ipf/ipnat \/ fxp3: 192.168.1.1 -> switch -> internal computers I want all traffic to go through this one machine so accounting and other filtering/limiting can be done... all through one computer. Thanks, Andrew From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 00:25:14 2004 Return-Path: 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 E44AE16A4CF for ; Fri, 17 Dec 2004 00:25:14 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82AB043D2F for ; Fri, 17 Dec 2004 00:25:14 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so332736wra for ; Thu, 16 Dec 2004 16:25:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=pVVbLs4ulyMrMMaqAYwi9PHuWdwmePrPOm16SLOu5zNv37CctoFfdtV6DlckFY/K4Z97F8opk2ap8tOm/wwZgLIgTVvHLDXOWHecnkyooYEhpTbWXaWp+yyEGJZR/urqY5tjX5fRgm7WwTjty1720OstQ8qjaU99J2ptO2Tv1+U= Received: by 10.54.10.76 with SMTP id 76mr1525096wrj; Thu, 16 Dec 2004 16:25:10 -0800 (PST) Received: by 10.54.23.33 with HTTP; Thu, 16 Dec 2004 16:25:10 -0800 (PST) Message-ID: <7c8f279204121616256de97cfd@mail.gmail.com> Date: Thu, 16 Dec 2004 19:25:10 -0500 From: Josh Kayse To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: em0 link_state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gtg062h@mail.gatech.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 00:25:15 -0000 I was working on some test machines and using ifstated which uses the KQUEUE event to register changes in link state. I noticed that ifstated did register any events having to do with the em interfaces. Looking through the code, it doesn't appear to support the KQUEUE events. Am I correct in saying that? And if so, is anyone working on it? Thanks in advance. -josh -- Joshua Kayse Computer Engineering From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 08:29:50 2004 Return-Path: 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 3A32716A4CE for ; Fri, 17 Dec 2004 08:29:50 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36F7443D46 for ; Fri, 17 Dec 2004 08:29:49 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id iBH8TlwK056735; Fri, 17 Dec 2004 11:29:47 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 17 Dec 2004 11:29:47 +0300 (MSK) From: Maxim Konovalov To: gtg062h@mail.gatech.edu In-Reply-To: <7c8f279204121616256de97cfd@mail.gmail.com> Message-ID: <20041217112551.K56244@mp2.macomnet.net> References: <7c8f279204121616256de97cfd@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (178/041216) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking - Keywords (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: freebsd-net@freebsd.org Subject: Re: em0 link_state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 08:29:50 -0000 On Thu, 16 Dec 2004, 19:25-0500, Josh Kayse wrote: > I was working on some test machines and using ifstated which uses the > KQUEUE event to register changes in link state. I noticed that > ifstated did register any events having to do with the em interfaces. > Looking through the code, it doesn't appear to support the KQUEUE > events. Am I correct in saying that? Correct. From kqueue.2: : The EVFILT_NETDEV filter is currently only implemented for devices : that use the miibus(4) driver for LINKUP and LINKDOWN operations. : Therefore, it will not work with many non-ethernet devices. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 09:48:34 2004 Return-Path: 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 999A516A4CE for ; Fri, 17 Dec 2004 09:48:34 +0000 (GMT) Received: from borgtech.ca (borgtech.ca [216.187.106.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C4143D45 for ; Fri, 17 Dec 2004 09:48:33 +0000 (GMT) (envelope-from asegu@borgtech.ca) Received: from asegulaptop (unknown [161.53.212.202]) by borgtech.ca (Postfix) with ESMTP id E4E6054C3 for ; Fri, 17 Dec 2004 09:49:37 +0000 (GMT) From: "Andrew Seguin" To: Date: Fri, 17 Dec 2004 10:47:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTjwbZEQOKQzSfsScqWspCg6UGulAAQrbgQAASsTIAAAYilMA== Message-Id: <20041217094937.E4E6054C3@borgtech.ca> Subject: FW: Curiosity in IPFW/Freebsd bridge. [more] 802.1q VLAN at fault? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 09:48:34 -0000 My apologies: Sometimes I feel just so stupid... hitting reply replies = to me instead of the list. Ooops! -----Original Message----- From: Andrew Seguin [mailto:asegu@borgtech.ca]=20 Sent: Friday, December 17, 2004 10:16 AM To: 'Andrew Seguin' Subject: RE: Curiosity in IPFW/Freebsd bridge. [more] Ok, through all my bugging of you all, I just want to mention that I am still working at my own end to figure this out.. I've used tcpdump to capture a sample of all traffic for each nic = (tcpdump -s 1500 -i fxp1 -c 1000 -w tcpdump.fxp1), which I am now looking at in ethereal. So my initial observation: traffic flowing through the bridge doesn't filter, while on the console access nic, it does. Looking through the ethereal dumps, I have spotted one difference. Packets for the console look like this: Frame 1 (106 bytes on wire, 106 bytes captured) Ethernet II, Src: MAC1, Dst: MAC2 Internet Protocol, Src Addr: MyPC, Dst Addr: FIREWALL SSH Protocol Packets from the bridge look like this: Frame 1 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: MAC1, Dst: MAC2 802.1q Virtual LAN Internet Protocol, Src Addr: x, Dst Addr: y Transmission Control Protocol, ... So it would seem that the part "802.1q Virtual LAN" in the protocol is stopping IPFW from investigating the traffic? (At times like this I wish = I would have not studied computer engineering but networking for 4 = years!). Question then: What in IPFW is stopping it from reading into a VLAN tagged packet (if = it is such that it can be called). All help and pointers (especially to documentation) would be highly appreciated! -----Original Message----- From: Andrew Seguin [mailto:asegu@borgtech.ca]=20 Sent: Friday, December 17, 2004 8:27 AM To: 'Andrew Seguin' Subject: RE: Curiosity in IPFW/Freebsd bridge. [more] I have done a bit of further research and I have to question myself what = is going on. I set the system back up with only two nics in use, and put an IP = address up on one side only, nothing different. Back to the three nic setup: Four rules: 1 allow ip from any to LOCALIP 22 10 allow tcp from any to any 11 allow udp from any to any 100 allow log ip from any to any The counts climb very very slowly for rules 10/11 (maybe 100bytes/min?) while rule 100 increases at the rate of approximately 2-3MB/min. On the bridge, only MAC traffic is seen. looking at the logs (I put in a 1000 allow log ip from any to any) and I = saw " Accept MAC in via fxp1", "Accept MAC in via fxp0", repeated many times over. Googling I've found this unanswered post which seems to be exact same problem as for me: http://lists.freebsd.org/pipermail/freebsd-questions/2004-August/056397.h= tml This question that is only so so related (person doesn't complain about = it being a problem, only wants to log): http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2004-04/1680.ht= ml So I am wondering what am I missing? What is going on? Is this a problem in Freebsd-5, should I rebuild to freebsd 4? Well, sorry to keep buggin this list with a "simple" firewall bridge, = but the problems haven't been simple to me to date. I am very grateful for = all of you helping here! Andrew. -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Andrew Seguin Sent: Thursday, December 16, 2004 11:51 PM To: freebsd-net@freebsd.org Subject: Curiosity in IPFW/Freebsd bridge. Hello, First off, a great thanks to this list who pointed out my = hardware issue (rl series cards). I now have the bridge on two Intel Pro NICS and = I use the on-board sis card for console access, and my average ping time = is a 2ms average to the router, passing about a solid 2MB/s. =20 My current situation is that it seems IPFW is filtering by IP address, = but never matching an IP address/Port number combo (ex: =93deny ip from IP = to any=94 works, but =93deny ip from IP to any 80=94 does not work). =20 The firewall rules are as follows: #1. Allow all SSH traffic until rules are down safe. ipfw add 1 allow ip from any to LOCAL_IP 22 #ipfw add 100 TEST (either =93deny ip from any to any=94 or =93deny ip = from any to any 80=94). ipfw add 500 pipe 1 ip from any to any ipfw pipe 1 config bw 20480Kbit/s default> allow ip from any to any =20 The setup is as follows in rc.conf: Ifconfig_fxp0=3D=94up=94 Ifconfig_fxp1=3D=94up=94 Ifconfig_sis0=3D=94LOCAL_IP=85=94 =20 And in sysctl.conf: net.link.ether.bridge.enable=3D1 net.link.ether.bridge.config=3Dfxp0,fxp1 net.link.ether.bridge.ipfw=3D1 =20 Kernel has been built with IPFW and DUMMYNET. Freebsd 5.3 (RELENG_5, cvsupdated and recompiled about a week ago). =20 The server was working fine when I had it filtering between two switches (secondary to primary). I was having web/email/irc traffic bypass the = pipe, and used the pipe to limit the speed of those who use P2P. Now, I have = this situation with the firewall between the main switch and the router. I really need to get this working for this purpose again fast or else = I=92ll have a repeat of an earlier =93internal=94 DoS, so any and all tips, = comments, pointers would be greatly appreciated! =20 I wonder if it is because I haven=92t assigned an IP address on the fxp = facing the inside network=85? Haven=92t had the time to try this yet (11:50pm = local time!) since I don=92t remember which fxp card is facing = internal/external and so I will try in the morning. =20 Again, many thanks! Andrew Seguin =20 =20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =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 No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =20 --=20 No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =20 --=20 No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 =20 From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 11:22:11 2004 Return-Path: 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 7D94916A4CE for ; Fri, 17 Dec 2004 11:22:11 +0000 (GMT) Received: from orion.erdves.lt (ns2.lrtc.net [217.9.240.98]) by mx1.FreeBSD.org (Postfix) with SMTP id D541843D3F for ; Fri, 17 Dec 2004 11:22:09 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 16148 invoked from network); 17 Dec 2004 11:22:05 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (217.9.241.242) by orion.erdves.lt with SMTP; 17 Dec 2004 11:22:05 -0000 Message-ID: <005801c4e42a$a1825890$9f90a8c0@donatas> From: "Donatas" To: Date: Fri, 17 Dec 2004 13:22:02 +0200 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: vlan double tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 11:22:11 -0000 hello, i'd like to ask if there's any possibility to pass double tagged vlan = packets through freebsd 5.x routers? and....how many level1 vlans are supported on one parent device? maybe there are some solutions in netgraph sphere? thanx inadvance Donatas Gendvilas SC Lithuanian radio and Television Center Data Transfers Department Operations Center tel.: local, 8-5-2525384, +37065266772 Sausio 13-osios g. 10, 04347 Vilnius 50, Lithuania =20 From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 12:41:38 2004 Return-Path: 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 989C116A4CE for ; Fri, 17 Dec 2004 12:41:38 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F22443D1D for ; Fri, 17 Dec 2004 12:41:37 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id iBHCfVEQ078869; Fri, 17 Dec 2004 15:41:31 +0300 (MSK) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Dec 2004 15:41:30 +0300 Date: Fri, 17 Dec 2004 15:41:30 +0300 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <721371959296.20041217154130@star-sw.com> To: "Andrew Seguin" In-reply-To: <20041217094937.E4E6054C3@borgtech.ca> References: <20041217094937.E4E6054C3@borgtech.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2004 12:41:30.0719 (UTC) FILETIME=[BBBAAEF0:01C4E435] cc: freebsd-net@freebsd.org Subject: Re: FW: Curiosity in IPFW/Freebsd bridge. [more] 802.1q VLAN at fault? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 12:41:38 -0000 Hello Andrew, Friday, December 17, 2004, 12:47:46 PM, Andrew Seguin wrote: AS> Looking through the ethereal dumps, I have spotted one difference. AS> Packets for the console look like this: AS> Frame 1 (106 bytes on wire, 106 bytes captured) AS> Ethernet II, Src: MAC1, Dst: MAC2 AS> Internet Protocol, Src Addr: MyPC, Dst Addr: FIREWALL AS> SSH Protocol AS> Packets from the bridge look like this: AS> Frame 1 (64 bytes on wire, 64 bytes captured) AS> Ethernet II, Src: MAC1, Dst: MAC2 AS> 802.1q Virtual LAN AS> Internet Protocol, Src Addr: x, Dst Addr: y AS> Transmission Control Protocol, ... AS> So it would seem that the part "802.1q Virtual LAN" in the protocol is AS> stopping IPFW from investigating the traffic? (At times like this I wish I AS> would have not studied computer engineering but networking for 4 years!). AS> Question then: AS> What in IPFW is stopping it from reading into a VLAN tagged packet (if it AS> is such that it can be called). I cannot say for sure, because I do not have any 5.x filtering bridge right now. But after reading some sources I think I understand what is happening: bdg_forward in bridge.c is calling ipfw or another packet filter: /* * NetBSD-style generic packet filter, pfil(9), hooks. * Enables ipf(8) in bridging. */ if (!IPFW_LOADED) { /* XXX: Prevent ipfw from being run twice. */ if (inet_pfil_hook.ph_busy_count >= 0 && m0->m_pkthdr.len >= sizeof(struct ip) && ntohs(save_eh.ether_type) == ETHERTYPE_IP) { Note the last line: for VLAN tagged packet the field save_eh.ether_type would be ETHERTYPE_VLAN instead of ETHERTYPE_IP and no filtering will take place. That is what I think is going on. Who is the current maintainer of bridge code in FreeBSD? -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 14:28:25 2004 Return-Path: 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 CCE2416A4CE for ; Fri, 17 Dec 2004 14:28:25 +0000 (GMT) Received: from borgtech.ca (borgtech.ca [216.187.106.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C2E43D1D for ; Fri, 17 Dec 2004 14:28:25 +0000 (GMT) (envelope-from asegu@borgtech.ca) Received: from asegulaptop (unknown [161.53.212.202]) by borgtech.ca (Postfix) with ESMTP id 4E39254C3; Fri, 17 Dec 2004 14:29:30 +0000 (GMT) From: "Andrew Seguin" To: "'Nickolay A. Kritsky'" Date: Fri, 17 Dec 2004 15:28:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTkNebPBHw78bmWRqC0ykNZst/C4AAC+Fhw In-Reply-To: <721371959296.20041217154130@star-sw.com> Message-Id: <20041217142930.4E39254C3@borgtech.ca> cc: freebsd-net@freebsd.org Subject: RE: FW: Curiosity in IPFW/Freebsd bridge. [more] 802.1q VLAN at fault? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 14:28:25 -0000 Would changing over to RELENG_4 remove these headaches for me? Maybe if I patch the code you pointed out to be ETHERTYPE_VLAN instead of _IP, then ipfw will filter only VLAN traffic instead of IP traffic. This I would be willing to do until a patch became mainstream. So if the above works, I could just remove remote-console access and leave the box without an IP address, and IPFW would happily work with filters such as "deny ip from any to any $PORT"... Thank you for your help to date, I shall stay tuned to any other ideas! Andrew -----Original Message----- From: Nickolay A. Kritsky [mailto:nkritsky@star-sw.com] Sent: Friday, December 17, 2004 1:42 PM To: Andrew Seguin Cc: freebsd-net@freebsd.org Subject: Re: FW: Curiosity in IPFW/Freebsd bridge. [more] 802.1q VLAN at fault? Hello Andrew, Friday, December 17, 2004, 12:47:46 PM, Andrew Seguin wrote: ... I cannot say for sure, because I do not have any 5.x filtering bridge right now. But after reading some sources I think I understand what is happening: bdg_forward in bridge.c is calling ipfw or another packet filter: /* * NetBSD-style generic packet filter, pfil(9), hooks. * Enables ipf(8) in bridging. */ if (!IPFW_LOADED) { /* XXX: Prevent ipfw from being run twice. */ if (inet_pfil_hook.ph_busy_count >= 0 && m0->m_pkthdr.len >= sizeof(struct ip) && ntohs(save_eh.ether_type) == ETHERTYPE_IP) { Note the last line: for VLAN tagged packet the field save_eh.ether_type would be ETHERTYPE_VLAN instead of ETHERTYPE_IP and no filtering will take place. That is what I think is going on. Who is the current maintainer of bridge code in FreeBSD? -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 12/15/2004 From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 18:05:01 2004 Return-Path: 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 749D516A4CE for ; Fri, 17 Dec 2004 18:05:01 +0000 (GMT) Received: from smtp1.cistron.nl (smtp1.cistron.nl [62.216.30.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14F0C43D55 for ; Fri, 17 Dec 2004 18:05:01 +0000 (GMT) (envelope-from robert@guldan.demon.nl) Received: from cust.13.38.adsl.cistron.nl ([62.216.13.38] helo=guldan.demon.nl) by smtp1.cistron.nl with esmtp (Exim 3.36 #1 (Debian)) id 1CfMTL-0002H2-00 for ; Fri, 17 Dec 2004 19:04:59 +0100 Received: from bombur.guldan.demon.nl ([192.168.201.3] helo=localhost) by guldan.demon.nl with esmtp (Exim 4.24; FreeBSD) id 1CfMTI-000BSf-EP; Fri, 17 Dec 2004 19:04:56 +0100 Date: Fri, 17 Dec 2004 19:04:56 +0100 From: Robert Blacquiere To: freebsd-net@freebsd.org Message-ID: <20041217180456.GF64564@bombur.guldan.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Disclaimer: running FreeBSD X-Spam-Score: 0.0 (/) Subject: Ralink RT2500 wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 18:05:01 -0000 Hello, I've recently got a ralink wireless pci network card. i have been trying to get it to work with ndis but all seems to work until the first arp/ip packets are being passed over the interface. I spotted on the internet a project which produced recently a gpl driver for the rt2500 wireless card on sourceforge. Is someone working on native drivers? of how can ik fix the problems i have with ndis. By the way it is a freebsd 5.3 release install. Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there! From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 22:34:55 2004 Return-Path: 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 E611816A4CE for ; Fri, 17 Dec 2004 22:34:55 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA14E43D2F for ; Fri, 17 Dec 2004 22:34:55 +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 iBHMZJXw030550; Fri, 17 Dec 2004 14:35:19 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBHMZJ18030549; Fri, 17 Dec 2004 14:35:19 -0800 Date: Fri, 17 Dec 2004 14:35:19 -0800 From: Brooks Davis To: Donatas Message-ID: <20041217223519.GB27607@odin.ac.hmc.edu> References: <005801c4e42a$a1825890$9f90a8c0@donatas> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <005801c4e42a$a1825890$9f90a8c0@donatas> 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 Subject: Re: vlan double tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 22:34:56 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Dec 17, 2004 at 01:22:02PM +0200, Donatas wrote: > hello, > i'd like to ask if there's any possibility to pass double tagged vlan packets through freebsd 5.x routers? > and....how many level1 vlans are supported on one parent device? I don't know what happens with double tagged vlan packets. There should be no limit on the number of vlans supported, but with the current code, performance will be crap for large numbers because it searches the list of all vlans to match the tag. We need to add per-interface array of pointers to vlan interfaces instead. The number of vlans maximum allowed by the standard is small enough that blowing that memory is worth if for constant access time compared the complexity of using a balanced tree. > maybe there are some solutions in netgraph sphere? I'm not sure what you mean here? -- Brooks -- 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 --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBw18mXY6L6fI4GtQRAlMSAJ9KrwwUIx79GmhfDdkQAjlx1PMM+wCg00Da mH2HMWxK+8umN2uwKLr3yu0= =m1Ro -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 23:03:53 2004 Return-Path: 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 45F6016A4CE for ; Fri, 17 Dec 2004 23:03:53 +0000 (GMT) Received: from ack.Berkeley.EDU (ack.Berkeley.EDU [128.32.206.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17F2943D53 for ; Fri, 17 Dec 2004 23:03:53 +0000 (GMT) (envelope-from mhunter@ack.Berkeley.EDU) Received: (from mhunter@localhost) by ack.Berkeley.EDU (8.11.3/8.11.3) id iBHN3nI16107; Fri, 17 Dec 2004 15:03:49 -0800 (PST) Date: Fri, 17 Dec 2004 15:03:49 -0800 From: Mike Hunter To: Brooks Davis Message-ID: <20041217230349.GA15905@ack.Berkeley.EDU> References: <005801c4e42a$a1825890$9f90a8c0@donatas> <20041217223519.GB27607@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041217223519.GB27607@odin.ac.hmc.edu> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Donatas Subject: Re: vlan double tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 23:03:53 -0000 On Dec 17, "Brooks Davis" wrote: > On Fri, Dec 17, 2004 at 01:22:02PM +0200, Donatas wrote: > > hello, > > i'd like to ask if there's any possibility to pass double tagged vlan packets through freebsd 5.x routers? > > and....how many level1 vlans are supported on one parent device? > > I don't know what happens with double tagged vlan packets. I think what he's asking about is whether FreeBSD prevents any of the nasty hacks that can be accomplished by double-tagging frames, or if there is something he can do with netgraph to prevent such badness. Mike From owner-freebsd-net@FreeBSD.ORG Fri Dec 17 23:22:08 2004 Return-Path: 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 8F06B16A4CE for ; Fri, 17 Dec 2004 23:22:08 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6713043D5A for ; Fri, 17 Dec 2004 23:22:08 +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 iBHNMM4Z003029; Fri, 17 Dec 2004 15:22:22 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBHNMMup003028; Fri, 17 Dec 2004 15:22:22 -0800 Date: Fri, 17 Dec 2004 15:22:22 -0800 From: Brooks Davis To: Mike Hunter Message-ID: <20041217232222.GB32399@odin.ac.hmc.edu> References: <005801c4e42a$a1825890$9f90a8c0@donatas> <20041217223519.GB27607@odin.ac.hmc.edu> <20041217230349.GA15905@ack.Berkeley.EDU> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20041217230349.GA15905@ack.Berkeley.EDU> 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 cc: Donatas Subject: Re: vlan double tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2004 23:22:08 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 17, 2004 at 03:03:49PM -0800, Mike Hunter wrote: > On Dec 17, "Brooks Davis" wrote: >=20 > > On Fri, Dec 17, 2004 at 01:22:02PM +0200, Donatas wrote: > > > hello, > > > i'd like to ask if there's any possibility to pass double tagged vlan= packets through freebsd 5.x routers? > > > and....how many level1 vlans are supported on one parent device? > >=20 > > I don't know what happens with double tagged vlan packets. >=20 > I think what he's asking about is whether FreeBSD prevents any of the > nasty hacks that can be accomplished by double-tagging frames, or if there > is something he can do with netgraph to prevent such badness. My suspicion is that FreeBSD will drop the packets unless you configure a vlan interface on the vlan interface. -- 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 --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBw2otXY6L6fI4GtQRAl00AKC2s5C5KVEOsoFebOxNeAU2Q7d3dACfcHIy PGI85cX5Eh0fsoMwnSJ0llY= =x6Tp -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 18 01:01:32 2004 Return-Path: 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 D0C1F16A4CE for ; Sat, 18 Dec 2004 01:01:32 +0000 (GMT) Received: from a.mx.interacesso.pt (super11.nortenet.pt [212.13.35.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B63943D49 for ; Sat, 18 Dec 2004 01:01:29 +0000 (GMT) (envelope-from elton.machado@norteglobal.com) Received: (qmail 21029 invoked by uid 104); 18 Dec 2004 00:59:31 -0000 Received: from elton.machado@norteglobal.com by mx0.interacesso.pt by uid 101 with qmail-scanner-1.22st Clear:RC:1(212.13.50.179):. Processed in 0.086813 secs); 18 Dec 2004 00:59:31 -0000 Received: from 50-179.dial.nortenet.pt (HELO ?192.168.123.1?) (212.13.50.179) by a.mx.interacesso.pt with SMTP; 18 Dec 2004 00:59:31 -0000 Message-ID: <41C38165.1020709@norteglobal.com> Date: Sat, 18 Dec 2004 01:01:25 +0000 From: Elton Machado User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 01:01:32 -0000 Totally true and problem get worse when you already have the equipament and have to implement a solution over it. We are also using a script at this moment but it doesn't do load balance. What it only do is to check if the current provide are okay, and if not, it change the default route to the other. But it think this is not the best solution at all. What I basicly need is to have some kind of route protocol at our side that checks for the small path and choose it. Does it is much harder to implement ? Cheers Mitch (Bitblock) wrote: >>Why dont you all do yourselves a favor and go out and buy one of those >>home dsl/cable modems that have 2 ports and provide load balancing >>instead. >> >> >> >[Mitch says:] >The only ones I've seen were rather expensive and aren't modem's - they are >routers... so you have to still have your ADSL modem, your cable modem, your >load balancing router, which generally does a poor job, and has all kinds of >limitations... > >Why spend $500 bucks on a load shared with an inadequate non-open source >firewall that doesn't do what I want and then have to add a firewall anyways >;-) > >And worse, it works in NAT mode, and probably screws up ipsec, and traffic >shaping too... > >Is that enough reasons to try building a better mousetrap? > >m/ > From owner-freebsd-net@FreeBSD.ORG Sat Dec 18 03:31:25 2004 Return-Path: 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 0007316A4CE for ; Sat, 18 Dec 2004 03:31:24 +0000 (GMT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26DAC43D45 for ; Sat, 18 Dec 2004 03:31:24 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from dc1 ([66.199.170.122]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Sat, 18 Dec 2004 03:31:18 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 41C3A486.00006540.bigass1.bitblock.com,dns; dc1 ([66.199.170.122]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (Bitblock)" To: "'Elton Machado'" , freebsd-net@freebsd.org Date: Fri, 17 Dec 2004 19:31:19 -0800 Organization: Bitblock Systems Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41C38165.1020709@norteglobal.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcTknSXlGqDGd4QFQ+OFioIELuuASwAFLREg Message-ID: Subject: RE: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 03:31:25 -0000 > -----Original Message----- > Totally true and problem get worse when you already have the equipament > and have to implement a solution over it. > We are also using a script at this moment but it doesn't do load > balance. What it only do is to check if the current provide > are okay, and if not, it change the default route to the other. But it > think this is not the best solution at all. > > What I basicly need is to have some kind of route protocol at our side > that checks for the small path and choose it. > > Does it is much harder to implement ? > > Cheers > [Mitch says:] Tons - don't think you will ever get there unless you can find some way of running BGP. You could find some way of load sharing, or even balancing, but that has little to do with route optimization. m/ From owner-freebsd-net@FreeBSD.ORG Sat Dec 18 08:16:28 2004 Return-Path: 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 0753D16A4CE for ; Sat, 18 Dec 2004 08:16:28 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1E7043D39 for ; Sat, 18 Dec 2004 08:16:27 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 60F5A2FA0D; Sat, 18 Dec 2004 03:16:27 -0500 (EST) Date: Sat, 18 Dec 2004 03:16:27 -0500 From: James To: Mike Hunter Message-ID: <20041218081627.GA54494@scylla.towardex.com> References: <005801c4e42a$a1825890$9f90a8c0@donatas> <20041217223519.GB27607@odin.ac.hmc.edu> <20041217230349.GA15905@ack.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041217230349.GA15905@ack.Berkeley.EDU> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: Donatas Subject: Re: vlan double tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 08:16:28 -0000 On Fri, Dec 17, 2004 at 03:03:49PM -0800, Mike Hunter wrote: > On Dec 17, "Brooks Davis" wrote: > > > On Fri, Dec 17, 2004 at 01:22:02PM +0200, Donatas wrote: > > > hello, > > > i'd like to ask if there's any possibility to pass double tagged vlan packets through freebsd 5.x routers? > > > and....how many level1 vlans are supported on one parent device? > > > > I don't know what happens with double tagged vlan packets. > > I think what he's asking about is whether FreeBSD prevents any of the > nasty hacks that can be accomplished by double-tagging frames, or if there > is something he can do with netgraph to prevent such badness. /me thinks he's asking for q-in-q tunneling feature. -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Sat Dec 18 10:03:19 2004 Return-Path: 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 0A0E016A4CE for ; Sat, 18 Dec 2004 10:03:19 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 8F98543D3F for ; Sat, 18 Dec 2004 10:03:18 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 59009 invoked from network); 18 Dec 2004 10:03:17 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 18 Dec 2004 10:03:17 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 18 Dec 2004 04:03:11 -0600 (CST) From: Mike Silbersack To: net@freebsd.org Message-ID: <20041218033226.L28788@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1286915442-1103364191=:28788" Subject: Alternate port randomization approaches X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 10:03:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1286915442-1103364191=:28788 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed There have been a few reports by users of front end web proxies and other systems under FreeBSD that port randomization causes them problems under load. This seems to be due to a combination of port randomization and rapid connections to the same host causing ports to be recycled before the ISN has advanced past the end of the previous connection, thereby causing the TIME_WAIT socket on the receiving end to ignore the new SYN. I haven't proven it, but I imagine that part of the problem is due to the interaction of established and finished connections. Say that ports 1500 -> 1600 have established connections, and that arc4random picks port 1504 as the next one to try. Rather than picking another random port, we simply look sequentially through the rest of the ports, and will pick 1601. I had considered continuing to do random port guesses until an unused one was found, but that has the nasty property of looping an undetermined amount of time, and it would most likely not help anything anyway. The solution I've come up with that should provide a decent tradeoff between the increased security of port randomization and the realities of the problem of quick port recycling is attached. What it does is only randomize the first net.inet.ip.portrange.randomized ports assigned each second. Beyond that, it uses sequentual allocation. The default I picked, 20, is arbitrary. Initial testing by a front-end web proxy admin shows that 20 is too high to avoid problems in his case, but 1 works decently. Although this isn't a perfect fix, I think that it should be acceptable for the vast majority of systems, and I'd like to get it in before 4.11-release ships. To be conservative, I'll probably choose a value like 5, which should be fine for most systems out there. Super specialized users will always be able to lower it to 0. Since this is an important issue, I was wondering if anyone had any suggestions on how to improve this method, or how to solve the problem in another way. Remember that 4.11 ships in the next few weeks, so any solution which gets added to it must be relatively simple, we can't be doing anything like changing the TCP state machine. (Yes, I've considered removing the ISN > window requirement from the TIME_WAIT state, but that's not something to be changing on a whim.) Also note that 5.x and 6.x handle TIME_WAIT recycling in the exact same way 4.x does; the sequence number check is just now in the function tcp_timewait rather than in tcp_input. So, the same problems plagues all versions. (Despite my other modifications to sequence number generation which were attempts to fix it.) Comments appreciated, Mike "Silby" Silbersack --0-1286915442-1103364191=:28788 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="in_pcb.c-lessrandomization.patch-4" Content-Transfer-Encoding: BASE64 Content-ID: <20041218040311.P28788@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="in_pcb.c-lessrandomization.patch-4" LS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldC9pbl9wY2IuYwlUaHUgRGVj IDE2IDAzOjI2OjExIDIwMDQNCisrKyBpbl9wY2IuYwlUaHUgRGVjIDE2IDAz OjI3OjI5IDIwMDQNCkBAIC05NSw4ICs5NSwxMCBAQA0KIGludAlpcHBvcnRf aGlmaXJzdGF1dG8gPSBJUFBPUlRfSElGSVJTVEFVVE87CS8qIDQ5MTUyICov DQogaW50CWlwcG9ydF9oaWxhc3RhdXRvICA9IElQUE9SVF9ISUxBU1RBVVRP OwkJLyogNjU1MzUgKi8NCiANCi0vKiBTaGFsbCB3ZSBhbGxvY2F0ZSBlcGhl bWVyYWwgcG9ydHMgaW4gcmFuZG9tIG9yZGVyPyAqLw0KLWludAlpcHBvcnRf cmFuZG9taXplZCA9IDA7DQorLyogSG93IG1hbnkgZXBoZW1lcmFsIHBvcnQg cmFuZG9taXphdGlvbnMgc2hvdWxkIG9jY3VyIGVhY2ggc2Vjb25kPyAqLw0K K2ludAkJaXBwb3J0X21heHJwcyA9IDIwOw0KK3N0cnVjdCB0aW1ldmFsCWlw cG9ydF9sYXN0cmFuZG9tOw0KK2ludAkJaXBwb3J0X2N1cnJwczsNCiANCiAj ZGVmaW5lIFJBTkdFQ0hLKHZhciwgbWluLCBtYXgpIFwNCiAJaWYgKCh2YXIp IDwgKG1pbikpIHsgKHZhcikgPSAobWluKTsgfSBcDQpAQCAtMTM1LDcgKzEz Nyw3IEBADQogU1lTQ1RMX1BST0MoX25ldF9pbmV0X2lwX3BvcnRyYW5nZSwg T0lEX0FVVE8sIGhpbGFzdCwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywNCiAJ ICAgJmlwcG9ydF9oaWxhc3RhdXRvLCAwLCAmc3lzY3RsX25ldF9pcHBvcnRf Y2hlY2ssICJJIiwgIiIpOw0KIFNZU0NUTF9JTlQoX25ldF9pbmV0X2lwX3Bv cnRyYW5nZSwgT0lEX0FVVE8sIHJhbmRvbWl6ZWQsIENUTEZMQUdfUlcsDQot CSAgICZpcHBvcnRfcmFuZG9taXplZCwgMCwgIiIpOw0KKwkgICAmaXBwb3J0 X21heHJwcywgMCwgIiIpOw0KIA0KIC8qDQogICogaW5fcGNiLmM6IG1hbmFn ZSB0aGUgUHJvdG9jb2wgQ29udHJvbCBCbG9ja3MuDQpAQCAtMzIzLDcgKzMy NSw4IEBADQogCQkJLyoNCiAJCQkgKiBjb3VudGluZyBkb3duDQogCQkJICov DQotCQkJaWYgKGlwcG9ydF9yYW5kb21pemVkKQ0KKwkJCWlmIChpcHBvcnRf bWF4cnBzICYmDQorCSBwcHNyYXRlY2hlY2soJmlwcG9ydF9sYXN0cmFuZG9t LCAmaXBwb3J0X2N1cnJwcywgaXBwb3J0X21heHJwcykpDQogCQkJCSpsYXN0 cG9ydCA9IGZpcnN0IC0NCiAJCQkJCSAgICAoYXJjNHJhbmRvbSgpICUgKGZp cnN0IC0gbGFzdCkpOw0KIAkJCWNvdW50ID0gZmlyc3QgLSBsYXN0Ow0KQEAg LTM0Myw3ICszNDYsOCBAQA0KIAkJCS8qDQogCQkJICogY291bnRpbmcgdXAN CiAJCQkgKi8NCi0JCQlpZiAoaXBwb3J0X3JhbmRvbWl6ZWQpDQorCQkJaWYg KGlwcG9ydF9tYXhycHMgJiYNCisJIHBwc3JhdGVjaGVjaygmaXBwb3J0X2xh c3RyYW5kb20sICZpcHBvcnRfY3VycnBzLCBpcHBvcnRfbWF4cnBzKSkNCiAJ CQkJKmxhc3Rwb3J0ID0gZmlyc3QgKw0KIAkJCQkJICAgIChhcmM0cmFuZG9t KCkgJSAobGFzdCAtIGZpcnN0KSk7DQogCQkJY291bnQgPSBsYXN0IC0gZmly c3Q7DQo= --0-1286915442-1103364191=:28788 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="in_pcb.c-lessrandomization.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20041218040311.O28788@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="in_pcb.c-lessrandomization.patch" LS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldC9pbl9wY2IuYwlUaHUgTm92 IDI1IDAwOjQzOjIxIDIwMDQNCisrKyAvdXNyL3NyYy9zeXMvbmV0aW5ldC9p bl9wY2IuYwlUaHUgRGVjIDE2IDAyOjU1OjQ2IDIwMDQNCkBAIC05Nyw4ICs5 NywxMCBAQA0KIGludAlpcHBvcnRfcmVzZXJ2ZWRoaWdoID0gSVBQT1JUX1JF U0VSVkVEIC0gMTsJLyogMTAyMyAqLw0KIGludAlpcHBvcnRfcmVzZXJ2ZWRs b3cgPSAwOw0KIA0KLS8qIFNoYWxsIHdlIGFsbG9jYXRlIGVwaGVtZXJhbCBw b3J0cyBpbiByYW5kb20gb3JkZXI/ICovDQotaW50CWlwcG9ydF9yYW5kb21p emVkID0gMTsNCisvKiBIb3cgbWFueSBlcGhlbWVyYWwgcG9ydCByYW5kb21p emF0aW9ucyBzaG91bGQgb2NjdXIgZWFjaCBzZWNvbmQ/ICovDQoraW50CQlp cHBvcnRfbWF4cnBzID0gMjA7DQorc3RydWN0IHRpbWV2YWwJaXBwb3J0X2xh c3RyYW5kb207DQoraW50CQlpcHBvcnRfY3VycnBzOw0KIA0KICNkZWZpbmUg UkFOR0VDSEsodmFyLCBtaW4sIG1heCkgXA0KIAlpZiAoKHZhcikgPCAobWlu KSkgeyAodmFyKSA9IChtaW4pOyB9IFwNCkBAIC0xNDIsNyArMTQ0LDcgQEAN CiBTWVNDVExfSU5UKF9uZXRfaW5ldF9pcF9wb3J0cmFuZ2UsIE9JRF9BVVRP LCByZXNlcnZlZGxvdywNCiAJICAgQ1RMRkxBR19SV3xDVExGTEFHX1NFQ1VS RSwgJmlwcG9ydF9yZXNlcnZlZGxvdywgMCwgIiIpOw0KIFNZU0NUTF9JTlQo X25ldF9pbmV0X2lwX3BvcnRyYW5nZSwgT0lEX0FVVE8sIHJhbmRvbWl6ZWQs DQotCSAgIENUTEZMQUdfUlcsICZpcHBvcnRfcmFuZG9taXplZCwgMCwgIiIp Ow0KKwkgICBDVExGTEFHX1JXLCAmaXBwb3J0X21heHJwcywgMCwgIiIpOw0K IA0KIC8qDQogICogaW5fcGNiLmM6IG1hbmFnZSB0aGUgUHJvdG9jb2wgQ29u dHJvbCBCbG9ja3MuDQpAQCAtNDA0LDcgKzQwNiw4IEBADQogCQkJLyoNCiAJ CQkgKiBjb3VudGluZyBkb3duDQogCQkJICovDQotCQkJaWYgKGlwcG9ydF9y YW5kb21pemVkKQ0KKwkJCWlmIChpcHBvcnRfbWF4cnBzICYmDQorCSBwcHNy YXRlY2hlY2soJmlwcG9ydF9sYXN0cmFuZG9tLCAmaXBwb3J0X2N1cnJwcywg aXBwb3J0X21heHJwcykpDQogCQkJCSpsYXN0cG9ydCA9IGZpcnN0IC0NCiAJ CQkJCSAgICAoYXJjNHJhbmRvbSgpICUgKGZpcnN0IC0gbGFzdCkpOw0KIAkJ CWNvdW50ID0gZmlyc3QgLSBsYXN0Ow0KQEAgLTQyMiw3ICs0MjUsOCBAQA0K IAkJCS8qDQogCQkJICogY291bnRpbmcgdXANCiAJCQkgKi8NCi0JCQlpZiAo aXBwb3J0X3JhbmRvbWl6ZWQpDQorCQkJaWYgKGlwcG9ydF9tYXhycHMgJiYN CisJIHBwc3JhdGVjaGVjaygmaXBwb3J0X2xhc3RyYW5kb20sICZpcHBvcnRf Y3VycnBzLCBpcHBvcnRfbWF4cnBzKSkNCiAJCQkJKmxhc3Rwb3J0ID0gZmly c3QgKw0KIAkJCQkJICAgIChhcmM0cmFuZG9tKCkgJSAobGFzdCAtIGZpcnN0 KSk7DQogCQkJY291bnQgPSBsYXN0IC0gZmlyc3Q7DQo= --0-1286915442-1103364191=:28788-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 18 17:32:03 2004 Return-Path: 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 2069A16A50C for ; Sat, 18 Dec 2004 17:32:03 +0000 (GMT) Received: from orion.erdves.lt (ns2.lrtc.net [217.9.240.98]) by mx1.FreeBSD.org (Postfix) with SMTP id A16A043D54 for ; Sat, 18 Dec 2004 17:32:01 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 73251 invoked from network); 18 Dec 2004 17:32:00 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (217.9.241.242) by orion.erdves.lt with SMTP; 18 Dec 2004 17:32:00 -0000 Message-ID: <001e01c4e527$78caac10$9f90a8c0@donatas> From: "Donatas" To: Date: Sat, 18 Dec 2004 19:31:56 +0200 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: double vlans - once again. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 17:32:03 -0000 ok, i'll simplify my question - =20 we have vlan traffic, which is transfered via double tagged vlans = (nested vlans). Such functions are supported in some advanced switches = (AT-8948). The problem is - we cannot route those double-tagged vlans = using freebsd machines. Or maybe it is possible? let's say we've created vlan-1 and vlan-2, where vlan-2 parent device is = vlan-1 and vlan-1 parent device is physical network adapter. This = procedure seems impossible in freebsd. I've mentioned netgraph only as possible solution. Interesting, what = happens when freebsd get's double-tagged frame? thank you Donatas Gendvilas AB Lietuvos Radijos Ir Televizijos Centras Duomen=F9 Perdavimo Departamentas Valdymo Centras tel.: lokalus 444, 8-5-2525384, +37065266772 Sausio 13-osios g. 10, 04347 Vilnius 50, Lietuva =20 From owner-freebsd-net@FreeBSD.ORG Sat Dec 18 18:58:03 2004 Return-Path: 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 47F8D16A4CE for ; Sat, 18 Dec 2004 18:58:03 +0000 (GMT) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 1213443D2D for ; Sat, 18 Dec 2004 18:58:02 +0000 (GMT) (envelope-from misho@interbgc.com) Received: (qmail 13566 invoked from network); 18 Dec 2004 18:58:00 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(-4.9/8.0):. Processed in 0.778597 secs); 18 Dec 2004 18:58:00 -0000 X-Spam-Status: No, hits=-4.9 required=8.0 Received: from topilapi.ddns.cablebg.net (HELO misho) (213.240.205.199) by mail.interbgc.com with SMTP; 18 Dec 2004 18:57:59 -0000 Message-ID: <002501c4e533$7df445f0$c7cdf0d5@misho> From: "Mihail Balikov" To: References: <001e01c4e527$78caac10$9f90a8c0@donatas> Date: Sat, 18 Dec 2004 20:57:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" 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 Subject: Re: double vlans - once again. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mihail Balikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2004 18:58:03 -0000 I have done this 2 years ago for FreeBSD 4-STABLE in sys/net/if_vlan.c in vlan_config(), replace if (p->if_data.ifi_type != IFT_ETHER) return EPROTONOSUPPORT; with if (p->if_data.ifi_type != IFT_ETHER && p->if_data.ifi_type != IFT_L2VLAN) return EPROTONOSUPPORT; ----- Original Message ----- From: "Donatas" To: Sent: Saturday, December 18, 2004 7:31 PM Subject: double vlans - once again. ok, i'll simplify my question - we have vlan traffic, which is transfered via double tagged vlans (nested vlans). Such functions are supported in some advanced switches (AT-8948). The problem is - we cannot route those double-tagged vlans using freebsd machines. Or maybe it is possible? let's say we've created vlan-1 and vlan-2, where vlan-2 parent device is vlan-1 and vlan-1 parent device is physical network adapter. This procedure seems impossible in freebsd. I've mentioned netgraph only as possible solution. Interesting, what happens when freebsd get's double-tagged frame? thank you Donatas Gendvilas AB Lietuvos Radijos Ir Televizijos Centras Duomenu Perdavimo Departamentas Valdymo Centras tel.: lokalus 444, 8-5-2525384, +37065266772 Sausio 13-osios g. 10, 04347 Vilnius 50, Lietuva _______________________________________________ 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"