Date: Mon, 27 Apr 1998 10:28:35 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: julian@whistle.com (Julian Elischer) Cc: hackers@FreeBSD.ORG Subject: Re: RFC: IPFW/DIVERT change suggestion. Message-ID: <199804270828.KAA24696@labinfo.iet.unipi.it> In-Reply-To: <Pine.BSF.3.95.980427001717.21604K-100000@current1.whistle.com> from "Julian Elischer" at Apr 27, 98 00:38:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
> When we write the DIVERT facility we made a rather foolish design decision > and I'd like to suggest a change that would alter the semantics > of DIVERT/IPFW to fix it.. same conclusion here... > What can we do about this? i think the most reasonable view of the "divert" process is to see it as a graph where a pkt is forwarded. So we need to associate a set of rules to each node of the graph, and a matching rule also needs to specify the 'destination' node where to restart processing. So i would add a parameter to divert-like rules where you specify the next rule to continue processing. In a sense, this is similar to the first approach you propose, except that the 'destination' can be interpreted as a "jump". (there is no need to modify simple actions like allow/deny since the decision is final.) > would be that it might be possible to store a 'stack' for each packet > so that we could add 'gosub' (heh) to ipfw.. (just seeing if you're > reading) don't like the idea of 'subroutines' very much, i doubt it would be of much use in practice, and lot of work to implement it. cheers 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804270828.KAA24696>