Hello,

> 
> 3. If I were going to register the packet filter for real (ll. 322 ff.),
>    what values would be most appropriate for pfil_type and pfil_af, given
>    that the filter is supposed to filter at least two (and probably four)
>    different protocols?

I thought about doing this, but found that there are only two possible
values for ph_type: PFIL_TYPE_AF and PFIL_TYPE_IFNET. First works for
higher-level protocols (like IP). AFAIK "raw" ethernet frames doesn't
correspond to any address family, so this type is IMHO not suitable for
bridging. The second type means that the second argument is not an
address family or any other specification of protocol type, but a
pointer to a network interface. This could theoretically be used, but
you would have to know what interfaces are present, what of them are
bridged, and register a pfil_hook for each of them. (And update the
hooks if the interfaces change). This is not easy.
(See sys/net/pfil.h for this information, the pfil(9) man page is
obsolete).

The best way would probably be adding a new ph_type (something like
PFIL_DLT) and the second argument would be the data link type.

There is another problem: the ph_type and ph_un parameters uniquely
determine a filtering point. So you cannot tell if your filter is called
as a part of bridge processing or on other occasion. This problem is
also manifested by IPF: you cannot tell if the packet being processed
will be passed to the local host, will be routed or bridged. You only
know if it's in or out and on which interface.

When I wanted to have a filtering bridge, I took a patch made by Adam
Lebsack <adam at lebsack.com> (see his mail to tech-net:
http://mail-index.netbsd.org/tech-net/2002/12/16/0000.html and my reply:
http://mail-index.netbsd.org/tech-net/2003/01/17/0001.html).
It doesn't register a new filter. It simply passes the IP packets to
inet_pfil_hook (which normally filters them through IPF).
I corrected soome bugs in it 
(see http://mail-index.netbsd.org/tech-net/2003/01/28/0000.html).

This soulution isn't as generic as your approach, but it works. It
doesn't filter other packets than IPv4 (IPv6 could be added easily), it
lets them go. If you implement something better, it would be great, but
it will probably invove changes to the generic packet filter interface.

(If I underestimated the capabilities of current packet filter interface, 
I apologize to its developers).

Bye	Pavel