From owner-freebsd-net Thu May 3 5:50:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from CPE-61-9-164-106.vic.bigpond.net.au (CPE-61-9-166-240.vic.bigpond.net.au [61.9.166.240]) by hub.freebsd.org (Postfix) with ESMTP id 2648337B423 for ; Thu, 3 May 2001 05:50:15 -0700 (PDT) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by CPE-61-9-164-106.vic.bigpond.net.au (8.11.0/8.11.0) id f43CnvL25802; Thu, 3 May 2001 22:49:57 +1000 (EST) From: Darren Reed Message-Id: <200105031249.WAA24767@avalon.reed.wattle.id.au> Subject: Re: (KAME-snap 4633) Re: The future of ALTQ, IPsec & IPFILTER playing together ... In-Reply-To: <20010502172647.D21020@dr-evil.shagadelic.org> from Jason R Thorpe at "May 2, 1 05:26:47 pm" To: thorpej@zembu.com Date: Thu, 3 May 2001 22:49:37 +1000 (EST) Cc: snap-users@kame.net, gunther@aurora.regenstrief.org, darrenr@reed.wattle.id.au, julian@elischer.org, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some email I received from Jason R Thorpe, sie wrote: > On Thu, May 03, 2001 at 10:01:18AM +1000, Darren Reed wrote: > > > > BPF "expressions" are literally BPF bytecodes. > > > > Well, one of the goals of IPFilter is it can parse (as rules) a textual > > representation of what's currently loaded into the kernel. At the moment > > that means collecting hex output, as the bytecode instructions are less > > suited to being displayed all on the one line. > > For BPF bytecodes, that's problematic -- the optimizer often turns what > you originally had into something almost totally non-decompilable :-) Well, that's why I output hex, means I don't try decompile it. But only because I don't want to have to parse this: pass in { ld [12]; jeq #0x1020304; jt 4; jf 2; ld [16]; jeq #0x1020304; jt 4; jf 5; ret #68; ret #0; } although the current output would be this: pass in { 0x0020000 0x0000000c 0x00150400 0x01020304 0x00200000 0x0000000e 0x00150001 0x01020304 0x00060000 0x00000068 0x00060000 0x00000000 } That's using an original input of: pass in { host 1.2.3.4 } The output doesn't recognisably match the input, but it is a representation and you could (if sadistic enough) write the rules using hex too. I apologize if I didn't convey this in my original message, as was intended. Darren p.s the bytecodes might be wrong, this is just meant to be illustrative. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message