From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 5 11:06:55 2009 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1E110656C0 for ; Mon, 5 Oct 2009 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 02F9A8FC26 for ; Mon, 5 Oct 2009 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n95B6sPF088712 for ; Mon, 5 Oct 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n95B6sfi088709 for freebsd-ipfw@FreeBSD.org; Mon, 5 Oct 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Oct 2009 11:06:54 GMT Message-Id: <200910051106.n95B6sfi088709@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 63 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 7 20:14:35 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E9461065676 for ; Wed, 7 Oct 2009 20:14:35 +0000 (UTC) (envelope-from apauljoe@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF038FC14 for ; Wed, 7 Oct 2009 20:14:34 +0000 (UTC) Received: by qyk11 with SMTP id 11so4496309qyk.13 for ; Wed, 07 Oct 2009 13:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=Az409DgaLUhyuxCtsbo/7xzwqxhAY/EMXMi8eIa+MJU=; b=vo+ERXiTU4YL/pbb3Mr8i9kuCdgFmrew8U62ycOr0CqoJ5CFJHIQFSpLUVCxZQxvob WwXd9PVyqbv28XmuPfM3LEm3cVZGaHOKzAxDq3mwKUWsIoiRKdnfSIP1S4dN3aHfx+Bs GCqau9gkLJQFDf84qdjnCMtF5qzVBg4/Gmi5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=OZUl0auS1McdzQpjSk0BdgGpgLBChae1Yqs/k1CMt6ew2dSV5B9G0JQCdNPuKgrvhU IsT6IlTRAzXmqgAllS5mrNnLg556+I2zpq0vn8MYliwm6bvSQ7O2JKuwYAhfJs3+X/xy 7Zox7QaxvkBvZA9P9VSYDO1F/1qLW/fCRWvqg= MIME-Version: 1.0 Received: by 10.224.121.80 with SMTP id g16mr362853qar.316.1254944786118; Wed, 07 Oct 2009 12:46:26 -0700 (PDT) Date: Wed, 7 Oct 2009 12:46:24 -0700 Message-ID: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> From: Joe R To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: julian@elischer.org Subject: Extension of dummynet/ipfw to support userspace packet classification X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:14:35 -0000 We at ironport have a requirement to do bandwidth management, but the traffic classification (and selection of bandwidth pipes) is done in userspace. The reason classification is done in userspace is because the traffic classifications are something like streaming audio traffic, video traffic, based on website categories etc. Our appliance is based on FreeBSD, and so we decided to look at dummynet to support our requirement. We could not use dummynet as such because it uses ipfw for packet classification, where packet classification (and pipe selection) is done in kernel based on tcp/ip parameters like IP and port. So we decided to extended dummynet/ipfw to support packet classification in userspace. Our idea is to extended socket structure to have a pipe number and have a setsockoption to associate the pipe number to a socket structure. Then have a new ipfw target (mappedpipe), which will pass the packet to dummynet (similar to pipe target) but with the pipe number in the socket structure if it is non-zero. I would like to know your comments on this proposal and if people are interested, I will be happy to submit a patch on this. Thanks, Joe. From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 7 21:55:23 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F0A106568B for ; Wed, 7 Oct 2009 21:55:23 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.isupark.org [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF648FC1E for ; Wed, 7 Oct 2009 21:55:23 +0000 (UTC) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n97LFNAY095985; Wed, 7 Oct 2009 16:15:23 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Received: from GuysMBP.local (cetus.palisadesys.isupark.org [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n97LFHJU094967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2009 16:15:17 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <4ACD04E5.50806@palisadesys.com> Date: Wed, 07 Oct 2009 16:15:17 -0500 From: Guy Helmer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Joe R References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> In-Reply-To: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Wed, 07 Oct 2009 16:15:17 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-ipfw@freebsd.org, julian@elischer.org Subject: Re: Extension of dummynet/ipfw to support userspace packet classification X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:55:23 -0000 Joe R wrote: > We at ironport have a requirement to do bandwidth management, but the > traffic classification (and selection of bandwidth pipes) is done in > userspace. The reason classification is done in userspace is because the > traffic classifications are something like streaming audio traffic, video > traffic, based on website categories etc. > > > > Our appliance is based on FreeBSD, and so we decided to look at dummynet to > support our requirement. We could not use dummynet as such because it uses > ipfw for packet classification, where packet classification (and pipe > selection) is done in kernel based on tcp/ip parameters like IP and port. > > > > So we decided to extended dummynet/ipfw to support packet classification in > userspace. > > Our idea is to extended socket structure to have a pipe number and have a > setsockoption to associate the pipe number to a socket structure. Then have > a new ipfw target (mappedpipe), which will pass the packet to dummynet > (similar to pipe target) but with the pipe number in the socket structure if > it is non-zero. > > > > I would like to know your comments on this proposal and if people are > interested, I will be happy to submit a patch on this. > > I think it would be a very useful capability to apply a dummynet pipe to a stream. My thinking was that it would be nice to be able to build a dynamic table of connections in ipfw and then ipfw could pass packets that matched the dynamic connections list through a specified dummynet pipe. I think that is different than your design, though -- as I understand it, your design would apply dummynet to packets written to a socket. Guy From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 7 22:40:31 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF4461065672 for ; Wed, 7 Oct 2009 22:40:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id D30EB8FC0C for ; Wed, 7 Oct 2009 22:40:31 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C9DA6B98A1; Wed, 7 Oct 2009 15:40:31 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E54C12D6012; Wed, 7 Oct 2009 15:40:30 -0700 (PDT) Message-ID: <4ACD18E1.3040901@elischer.org> Date: Wed, 07 Oct 2009 15:40:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Guy Helmer References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> <4ACD04E5.50806@palisadesys.com> In-Reply-To: <4ACD04E5.50806@palisadesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Joe R Subject: Re: Extension of dummynet/ipfw to support userspace packet classification X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:40:32 -0000 Guy Helmer wrote: > Joe R wrote: >> We at ironport have a requirement to do bandwidth management, but the >> traffic classification (and selection of bandwidth pipes) is done in >> userspace. The reason classification is done in userspace is because the >> traffic classifications are something like streaming audio traffic, video >> traffic, based on website categories etc. >> >> >> >> Our appliance is based on FreeBSD, and so we decided to look at >> dummynet to >> support our requirement. We could not use dummynet as such because it >> uses >> ipfw for packet classification, where packet classification (and pipe >> selection) is done in kernel based on tcp/ip parameters like IP and port. >> >> >> >> So we decided to extended dummynet/ipfw to support packet >> classification in >> userspace. >> >> Our idea is to extended socket structure to have a pipe number and have a >> setsockoption to associate the pipe number to a socket structure. Then >> have >> a new ipfw target (mappedpipe), which will pass the packet to dummynet >> (similar to pipe target) but with the pipe number in the socket >> structure if >> it is non-zero. >> >> >> >> I would like to know your comments on this proposal and if people are >> interested, I will be happy to submit a patch on this. >> >> > I think it would be a very useful capability to apply a dummynet pipe to > a stream. > > My thinking was that it would be nice to be able to build a dynamic > table of connections in ipfw and then ipfw could pass packets that > matched the dynamic connections list through a specified dummynet pipe. > I think that is different than your design, though -- as I understand > it, your design would apply dummynet to packets written to a socket. > > Guy What they want to do is what I was going to do before I "left" there .. which is to allow a userland process (e.g. proxy) classify the session using some un-named method , assign some session key to the socket that can be attached to the mbufs in some way as they are generated. an in-kernel flow control module (e.g. dummynet) could then be left to enforce the bandwidth usage by that session. When I originally laid this out I thought we'd need the following parts working to allow this to happen: * ioctl to add value to a new field in the socket. * a place to store a copy of the field in the mbuf, OR a way to reference the one in the socket. * a way to get such packets to the right dummynet pipe. e.g. a new ipfw rule type. * A frontend to set up the pipes (not our problem). From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 7 22:48:09 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E00F5106566B for ; Wed, 7 Oct 2009 22:48:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 65E668FC12 for ; Wed, 7 Oct 2009 22:48:09 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3A556730DA; Thu, 8 Oct 2009 00:54:52 +0200 (CEST) Date: Thu, 8 Oct 2009 00:54:52 +0200 From: Luigi Rizzo To: Joe R Message-ID: <20091007225452.GA37005@onelab2.iet.unipi.it> References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, julian@elischer.org Subject: Re: Extension of dummynet/ipfw to support userspace packet classification X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:48:10 -0000 On Wed, Oct 07, 2009 at 12:46:24PM -0700, Joe R wrote: > We at ironport have a requirement to do bandwidth management, but the > traffic classification (and selection of bandwidth pipes) is done in > userspace. The reason classification is done in userspace is because the > traffic classifications are something like streaming audio traffic, video > traffic, based on website categories etc. > > > > Our appliance is based on FreeBSD, and so we decided to look at dummynet to > support our requirement. We could not use dummynet as such because it uses > ipfw for packet classification, where packet classification (and pipe > selection) is done in kernel based on tcp/ip parameters like IP and port. > > > > So we decided to extended dummynet/ipfw to support packet classification in > userspace. > > Our idea is to extended socket structure to have a pipe number and have a > setsockoption to associate the pipe number to a socket structure. Then have > a new ipfw target (mappedpipe), which will pass the packet to dummynet > (similar to pipe target) but with the pipe number in the socket structure if > it is non-zero. > > > > I would like to know your comments on this proposal and if people are > interested, I will be happy to submit a patch on this. i think the feature is useful. However I would implement it as an ipfw 'option' called "sockarg" (or similar) as follows: ipfw pipe tablearg sockarg where 'sockarg' succeeds ONLY if the packet is associated to a socket for which the special setsockoption has been issued, and in this case sets the 'tablearg' to the value of the setsockopt. This is somewhat similar to the 'uid' and 'gid' options (except for setting tablearg). This way the mechanism can be very general (not limited to pipes) and the implementation is probably simpler than the one you propose. In terms of runtime costs, we can look at check_uidgid() function, and there are two ways to implement this feature: - as in check_uidgid() , actively lookup for a matching socket if one is not available. This is expensive but would allow the feature to match also incoming packets; - only match if the args->inp parameter is non-null, otherwise do not call in_pcblookup_hash(). This is cheaper but clearly only works for locally generated packets. Perhaps we could use an argument for 'sockarg' so we can decide whether to call or not the in_pcblookup_hash() on a case-by-case basis. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 7 23:02:27 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 451611065670 for ; Wed, 7 Oct 2009 23:02:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C06118FC29 for ; Wed, 7 Oct 2009 23:02:26 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D8AB373106; Thu, 8 Oct 2009 01:09:09 +0200 (CEST) Date: Thu, 8 Oct 2009 01:09:09 +0200 From: Luigi Rizzo To: Joe R Message-ID: <20091007230909.GB37005@onelab2.iet.unipi.it> References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> <20091007225452.GA37005@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091007225452.GA37005@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, julian@elischer.org Subject: Re: Extension of dummynet/ipfw to support userspace packet classification X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 23:02:27 -0000 On Thu, Oct 08, 2009 at 12:54:52AM +0200, Luigi Rizzo wrote: > On Wed, Oct 07, 2009 at 12:46:24PM -0700, Joe R wrote: > > We at ironport have a requirement to do bandwidth management, but the > > traffic classification (and selection of bandwidth pipes) is done in > > userspace. The reason classification is done in userspace is because the > > traffic classifications are something like streaming audio traffic, video > > traffic, based on website categories etc. > > > > > > > > Our appliance is based on FreeBSD, and so we decided to look at dummynet to > > support our requirement. We could not use dummynet as such because it uses > > ipfw for packet classification, where packet classification (and pipe > > selection) is done in kernel based on tcp/ip parameters like IP and port. > > > > > > > > So we decided to extended dummynet/ipfw to support packet classification in > > userspace. > > > > Our idea is to extended socket structure to have a pipe number and have a > > setsockoption to associate the pipe number to a socket structure. Then have > > a new ipfw target (mappedpipe), which will pass the packet to dummynet > > (similar to pipe target) but with the pipe number in the socket structure if > > it is non-zero. > > > > > > > > I would like to know your comments on this proposal and if people are > > interested, I will be happy to submit a patch on this. > > i think the feature is useful. However I would implement it as an > ipfw 'option' called "sockarg" (or similar) as follows: > > ipfw pipe tablearg sockarg > > where 'sockarg' succeeds ONLY if the packet is associated to a socket > for which the special setsockoption has been issued, and in this > case sets the 'tablearg' to the value of the setsockopt. This is > somewhat similar to the 'uid' and 'gid' options (except for setting > tablearg). This way the mechanism can be very general (not limited > to pipes) and the implementation is probably > simpler than the one you propose. > > In terms of runtime costs, we can look at check_uidgid() function, > and there are two ways to implement this feature: > - as in check_uidgid() , actively lookup for a matching socket if one > is not available. This is expensive but would allow the feature to > match also incoming packets; > - only match if the args->inp parameter is non-null, otherwise do not > call in_pcblookup_hash(). This is cheaper but clearly only works > for locally generated packets. > Perhaps we could use an argument for 'sockarg' so we can decide > whether to call or not the in_pcblookup_hash() on a case-by-case > basis. To complete the analysis, I must say that I don't know how intrusive is the setsockopt that can attach a classification tag to the socket. This is my main concern for merging your proposal into the system (and i am only concerned about the socket part, the ipfw change is trivial). Also for completeness, there is also another possible approach to address your problem, which is more general and fully contained in ipfw (so less intrusive for the OS): add a 'hashtable' structure to ipfw, which works in a way similar to the 'table' with the difference that entries would be the whole 5-tuple of the packet. There is already a hash table in ipfw (used for dynamic rules) so it would be only a matter of adding the necessary glue to manipulate the hash table from /sbin/ipfw. An additional bonus of this approach is that one could use this new code to 'prime' the dynamic rule table after a reboot, which is a feature that people ask from time to time. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 8 03:18:50 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 911E7106566B for ; Thu, 8 Oct 2009 03:18:50 +0000 (UTC) (envelope-from me@sharktooth.org) Received: from onyx.sharktooth.org (166-70-186-42.ip.xmission.com [166.70.186.42]) by mx1.freebsd.org (Postfix) with ESMTP id 70A718FC08 for ; Thu, 8 Oct 2009 03:18:50 +0000 (UTC) Received: from localhost.sharktooth.org ([::1] helo=users.sharktooth.org) by onyx.sharktooth.org with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MvixV-000NU9-Ns; Wed, 07 Oct 2009 20:42:28 -0600 Received: from 71.199.19.70 (SquirrelMail authenticated user me@sharktooth.org) by users.sharktooth.org with HTTP; Wed, 7 Oct 2009 20:42:25 -0600 (MDT) Message-ID: <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> In-Reply-To: <4AC52918.2020705@smartt.com> References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> Date: Wed, 7 Oct 2009 20:42:25 -0600 (MDT) From: "Jason Lewis" To: "Chris St Denis" User-Agent: SquirrelMail/1.4.16 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: me@sharktooth.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on onyx.sharktooth.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on onyx.sharktooth.org) Cc: freebsd-ipfw@freebsd.org, Freddie Cash Subject: Re: ipfw: install_state: entry already present, done X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 03:18:50 -0000 Did you try a check_state? I am using this same rule structure on BSD6 without a problem. Thanks, Jason http://jasonlewis.yaritz.net > Freddie Cash wrote: >> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis wrote: >> >> >>> Haven't gotten any response on -questions so trying here. I've also >>> opened >>> a PR (kern/139226) but it's gotten no replies so I figured I should try >>> here >>> since I'm not certain if it's a bug or not. Regardless I am hoping for >>> at >>> least a work-around -- a few extra rules or settings to keep my console >>> from >>> being flooded by errors. So far only option I found is commenting out >>> the >>> error display line in the kernel source which is far from optimal. >>> >>> I'm trying to setup a stateful firewall for my server such that any >>> traffic >>> can go out, and it's reply come back -- a fairly typical workstation >>> setup. >>> However I'm getting the error message "ipfw: install_state: entry >>> already >>> present, done" repeated many times in my logs (tho the rules seemed to >>> work >>> fine otherwise). >>> >>> I stripped down the rules to the minimum I could and discovered the >>> line >>> causing it is "allow udp from me to any keep-state". >>> >>> Only seems to happen when I have bind running as a slave dns server >>> (not >>> publicly listed, just the zone replication traffic causes the error) >>> but I >>> assume any other large source of UDP traffic would also do it. >>> >>> Full firewall rules: >>> >>> dns2# ipfw list >>> 00100 allow ip from any to any via lo0 >>> 00200 deny ip from any to 127.0.0.0/8 >>> 00300 deny ip from 127.0.0.0/8 to any >>> 00400 allow udp from me to any keep-state >>> 65535 deny ip from any to any >>> >>> >>> >> If you add "out xmit em0" to the udp rule, do the errors stop > I added that and restarted bind (thus generating a bunch of UDP traffic) > and the error still floods the console. > > Current rule set: > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00400 allow udp from me to any out xmit em0 keep-state > 00500 allow ip from any to any > 65535 deny ip from any to any > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 9 19:47:08 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC2CC106566B for ; Fri, 9 Oct 2009 19:47:08 +0000 (UTC) (envelope-from chris@smartt.com) Received: from mailout3.smartt.com (mailout3.smartt.com [69.67.187.28]) by mx1.freebsd.org (Postfix) with ESMTP id C06AE8FC17 for ; Fri, 9 Oct 2009 19:47:08 +0000 (UTC) Received: from [69.31.174.220] (unknown [69.31.174.220]) by mailout3.smartt.com (Postfix) with ESMTPA id C780610E6A0; Fri, 9 Oct 2009 12:47:06 -0700 (PDT) Message-ID: <4ACF9341.2040406@smartt.com> Date: Fri, 09 Oct 2009 12:47:13 -0700 From: Chris St Denis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jason Lewis References: <4AC51F18.5050703@smartt.com> <4AC52918.2020705@smartt.com> <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> In-Reply-To: <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org, Freddie Cash Subject: Re: ipfw: install_state: entry already present, done X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:47:08 -0000 check_state doesn't help. The error is also generated from the rc.conf firewall_type="workstation" rule set which includes check_state among several other rules. I made a copy of this server (it's a virtual server under WMware) and downgraded it to 6.4-RELEASE-p7 and I no longer get the error. I downgraded another copy to 7.2-RELEASE (no patches) by copying the generic kernel off the CD. Still gets errors. Downgraded it to 7.0-RELEASE and the message stopped. I'm going to try going to 7.1 and see which behavior it has. Looks like there may have been a regression in 7.2 (or maybe 7.1 pending the results of my further testing) Jason Lewis wrote: > Did you try a check_state? I am using this same rule structure on BSD6 > without a problem. > > Thanks, > Jason > http://jasonlewis.yaritz.net > > >> Freddie Cash wrote: >> >>> On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis wrote: >>> >>> >>> >>>> Haven't gotten any response on -questions so trying here. I've also >>>> opened >>>> a PR (kern/139226) but it's gotten no replies so I figured I should try >>>> here >>>> since I'm not certain if it's a bug or not. Regardless I am hoping for >>>> at >>>> least a work-around -- a few extra rules or settings to keep my console >>>> from >>>> being flooded by errors. So far only option I found is commenting out >>>> the >>>> error display line in the kernel source which is far from optimal. >>>> >>>> I'm trying to setup a stateful firewall for my server such that any >>>> traffic >>>> can go out, and it's reply come back -- a fairly typical workstation >>>> setup. >>>> However I'm getting the error message "ipfw: install_state: entry >>>> already >>>> present, done" repeated many times in my logs (tho the rules seemed to >>>> work >>>> fine otherwise). >>>> >>>> I stripped down the rules to the minimum I could and discovered the >>>> line >>>> causing it is "allow udp from me to any keep-state". >>>> >>>> Only seems to happen when I have bind running as a slave dns server >>>> (not >>>> publicly listed, just the zone replication traffic causes the error) >>>> but I >>>> assume any other large source of UDP traffic would also do it. >>>> >>>> Full firewall rules: >>>> >>>> dns2# ipfw list >>>> 00100 allow ip from any to any via lo0 >>>> 00200 deny ip from any to 127.0.0.0/8 >>>> 00300 deny ip from 127.0.0.0/8 to any >>>> 00400 allow udp from me to any keep-state >>>> 65535 deny ip from any to any >>>> >>>> >>>> >>>> >>> If you add "out xmit em0" to the udp rule, do the errors stop >>> >> I added that and restarted bind (thus generating a bunch of UDP traffic) >> and the error still floods the console. >> >> Current rule set: >> 00100 allow ip from any to any via lo0 >> 00200 deny ip from any to 127.0.0.0/8 >> 00300 deny ip from 127.0.0.0/8 to any >> 00400 allow udp from me to any out xmit em0 keep-state >> 00500 allow ip from any to any >> 65535 deny ip from any to any >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses"