From owner-freebsd-net Tue May 19 10:07:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA27665 for freebsd-net-outgoing; Tue, 19 May 1998 10:07:38 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA27638; Tue, 19 May 1998 10:07:22 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA09734; Tue, 19 May 1998 17:23:37 +0200 From: Luigi Rizzo Message-Id: <199805191523.RAA09734@labinfo.iet.unipi.it> Subject: Re: struct ifnet handling... To: eivind@yes.no (Eivind Eklund) Date: Tue, 19 May 1998 17:23:37 +0200 (MET DST) Cc: kjc@csl.sony.co.jp, current@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <19980519185349.49553@follo.net> from "Eivind Eklund" at May 19, 98 06:53:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm referring to the implementation of the recv, xmit and 'via' rules. > They're implemented by running the _entire_ ruleset once when the > packet arrive, and once when it leave. oh, yes; but in this case, different rules might match the packet on the way in and out, and this is a lesser problem with properly implemented SKIPTO rules (i have them in the current dummynet code). you see, i have been beating this code for the last 10 days or so when i integrated dummynet with the firewall code -- see http://www.iet.unipi.it/~luigi/ip_dummynet/ if you have missed the announcement. I think the problem with our ipfw code is still in the way rules are defined. Probably they were designed not thinking too much to possible implementations, but just to be as generic as possible. This is why you can, for instance, say that a rule applies to "all interfaces named ed" which does not seem to make much sense to me (well it can be useful, but all you need to do is replicate some of the rules if you really need to). > One way is to look at a packet (including flags etc) as a series of > bits which can be masked against. This is fairly tractable - rules good idea implementation-wise: then each instruction becomes an offset, length, mask and match value. I only have a problem with JUMP rules: i am not sure if the old firewall code allowed backward jumps, but if you do then you must be careful to avoid loops... probably it is better to not allow backward jumps at all ? > I have code to do some of these transforms available somewhere; if you > want to play with this to look at different optimization models, you > can have a copy. don't have the time now, maybe in a couple of weeks. Do you mean that you have some kind of rewriting code that takes current firewall specification and compiles in lower-level instructions ? luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message