On Fri, 12 Aug 2005, Luigi Rizzo wrote:
On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote:
Hi,
I am afraid the existing code cannot help you.
The packets you see are encapsulated in 802.1q aka VLAN frames,
and since ipfw2 does not try to decapsulate the packets, you
don't get to see the IP headers.
Your most reasonable option would be to write a new ipufw2 opcode,
say something like 'vlan-decap x-y', which succeeds if the packet has
a vlan header in the range x to y, and in this case skips the VLAN header,
tries to re-parse the header fields as in the beginning of
ip_fw_chk() after the section
/*
* Collect parameters into local variables for faster matching.
*/
and then continues.
It's not a lot of code, in the worst case you can just cut&paste
the relevant 50-60 lines from the beginning of the code
(though of course it would be nice to rearrange the code to
reduce duplication).
By doing this you can do something like
ipfw add skipto 1000 vlan-decap 1-50
and then process vlans 1 to 50 at line 1000.
Maybe it is a good idea to split the vlan-id matching and the decapsulation.
Isn't it posible to cheat using vlan(4) interface ? I think it's
possible to create them in order to use its code to zap the VLAN header
and then use ipfw to filter on these vlan(4) interfaces. This isn't
more than a workaround, but it might help.
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
assuming mac-type vlan is, of course, dot1q trunk traffic.
or better still...
ipfw add 200 deny ip from any to 10.2.2.2 mac-type vlan vlan-id 400 via
em1
I'd also really like it if non-bridged interfaces kept their arp table
separate from normal interfaces -- but that's a separate issue I'm
experiencing when the management subnet (on a dedicated non-bridged nic)
also happens to be one of the vlans within the dot1q trunk.
A spanning tree daemon (user or kernelspace) wouldn't be bad either.
well it would be painful to configure, because the number of vlans is
(according to what Dan says) is large, and he would have to define
N vlan interfaces on each of the physical ones, then define
N bridges between the corresponding vlans (and i think there is
a limit on how large N can be).
It's worse than that. The device has four bridged interfaces. One up,
three down to three switches. Each switch holds 24 vlans. That QUICKLY
becomes a nightmare when bridging actually works without doing this. It's
just ipfw saying "nope, there's no possible way for me to look
Additionally demuxing incoming packets would take O(N) time.
cheers
luigi
--
"I hate Windows"
-Tigerwolf, Anthrocon 2004
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
