5.4 -- bridging, ipfw, dot1q

[Julian Elischer]

Dan Mahoney, System Admin wrote:
should be in -net not -hackers

cc's changed accordingly..

> 
> After all, the demuxing is nothing more than ignoring a few extra bits 
> at the beginning of the packet.  Which all my BPF stuff is doing nicely. 
> Snort, trafshow, etc all work fine and don't seem to choke on the extra 
> frames.
> 
> I'd personally just be happy if ipfw was smart enough to know that if I 
> was using ip-type rules on something that's not ip...that it would 
> handle the demuxing automagically.
> 
> i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan via em1
> 
> or maybe
> 
> i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan-as-inet 
> via em1
> 
>
Hi Dan.

What it comes down to is just that no-one who has worked in ipfw
has had your particular problem to solve. O/S gets done when people
have a particular problem to solve.

As for demultiplexing, well, you COULD pass it out to a netgraph
node that strips off the header
and stores the info in a tag, and then passes it back to ipfw, but
I don't know how the details would work. (I haven't been in ifpw since
it was rewritten). Alternatively you could use netgraph bridging and
tehnetgraph vlan node type to achieve some sort of stripping..
(Once again, I'm just pointing you in this direction, not providing a
full answer.)
In 6.x netgraph has more options for this sort of thing with
a direct interface between ipfw and netgraph.

So, if you want to fix it, you could either
do some work on ipfw or do some work on netgraph,
but either way
you'll probably need to do some work.

Julian