From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 07:32:45 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D4A16A41F for ; Mon, 19 Sep 2005 07:32:45 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9162E43D46 for ; Mon, 19 Sep 2005 07:32:44 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id BAA00256; Mon, 19 Sep 2005 01:32:34 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919010035.07dfc448@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 01:32:33 -0600 To: Luigi Rizzo From: Brett Glass In-Reply-To: <20050918235659.B60185@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Sep 2005 07:32:45 -0000 At 12:56 AM 9/19/2005, Luigi Rizzo wrote: >[see long original request below] > >Bret, you want a block structured ipfw control language, but >ipfw is an assembly language. You have to live with that. >Your only way out is >A. write a translator from high level to low level language > (many people do use sh scripts to generate ipfw configurations) I've tried this. Alas, it quickly gets out of hand because objects in IPFW (for example pipes) aren't named. You wind up literally having to build a symbol table to keep track of rule numbers, pipe numbers, etc. Yes, you can do it, but it's very awkward. >B. write the sequential blocks of instructions you need, > and connect them through skipto. It can be tedious, but generally > ipfw configurations are not so complex, _and_ when they are > is not terribly complex to generate this through scripts. Unfortunately, this requires inverting the sense of rules. And in IPFW's very simplistic language, you can't invert a single rule with more than one condition into another single rule because you can only negate each individual criterion and not the whole rule. Thus, when you do the NAND->OR conversion (DeMorgan's Theorem), you will find yourself with an explosion in the number of rules. What's more, the inversion can't be easily automated (there are quite a lot of IPFW options, and some are not directly invertable). So, every time you add a rule you have to write its inverse manually as multiple rules, with skipto's whose targets may change if you ever edit the rule set. It's total spaghetti. It occurs to me that there might be a simpler way. What if one could add an IPFW option called "resume" to a rule, with the following syntax and semantics? pipe 25 ip from 0.0.0.1 to any in via tun* resume 5000 The semantics would be as follows: If the rule was matched and the packet was sent off to a Dummynet pipe (or queue), a "skipto 5000" would be executed when the packet was re-injected into IPFW. This would skip you around the other bandwidth throttling rules. Problem solved. The same option might also be useful if you wanted to combine some other action that doesn't terminate the search (e.g. logging) with a "skipto". It wouldn't be valid if the action terminated the search. I believe that there's a field that goes along with a packet into Dummynet which carries information about where to reinject the packet if ip.fw.one_pass is set to 0. Thus, adding this option might just be a simple matter of modifying that field. I've looked at the source and it's fragmented and virtually undocumented, so I'd probably spend a long time blundering around trying to add this and get it right (and also have the rules display correctly, etc.). I seem to recall (correct me if I'm wrong here) that you've hacked on both IPFilter and IPFW. How hard would this be to add? --Brett Glass