Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 May 2001 22:49:37 +1000 (EST)
From:      Darren Reed <darrenr@reed.wattle.id.au>
To:        thorpej@zembu.com
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
Subject:   Re: (KAME-snap 4633) Re: The future of ALTQ, IPsec & IPFILTER playing    together ...
Message-ID:  <200105031249.WAA24767@avalon.reed.wattle.id.au>
In-Reply-To: <20010502172647.D21020@dr-evil.shagadelic.org> from Jason R Thorpe at "May 2, 1 05:26:47 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105031249.WAA24767>