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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
