Subject: Re: Zembu Packet Classifier -- would like to put it in the mainline
To: None <itojun@iijlab.net>
From: Jason R Thorpe <thorpej@zembu.com>
List: tech-net
Date: 12/28/2000 21:48:34
On Fri, Dec 29, 2000 at 02:02:28PM +0900, itojun@iijlab.net wrote:

 > 	one quesition: how does it behave against tunnelled packet?

For network interfaces, it sees the packet just as BPF would see the
packet.  So, consider the case of a v6-in-v4 packet being tunneled
via a gif(4) interface.

The outer layer would be filtered at the "inet" filter point -- it
would see ipproto-ipv6.  Then after being decapsulated, the inner
layer would have the opportunity to be filtered at the "gif0" layer
(with the DLT_NULL header in front of the packet), and then again at
the "inet6" layer (no link header in front of the packet).

(Note, I haven't yet committed the code that adds filtering points
for network interfaces.)

 > 	I have done this with racoon, by attachking fake ethernet (or af
 > 	number like loopback) header :-)

The problem I'm having is that the save file has no way of specifying
which network interface a packet traversed, and no indication of
direction.  I'd like to put that info into the packet info header
that BPF relays down to userspace, as well as into pcap save file.

The extended packet info would be enabled via an ioctl on the BPF
device so that backwards compatibility could be maintained, if e.g.
tcpdump(8) wanted that info.  In the ZPC case, the ZPC log device
would simply use the same packet header that BPF uses, and a daemon
would be listening on the ZPC log device and record the packets that
are sent down.

Anyway, with all that info, it would be possible to grab a traffic
snapshot, and then do a replay for testing purposes (via some other
device that you could feed the log into), or even just have a very
complete log.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>