Re: IPFW2 layer2 support broken.

[Gary Allan <dragonfly@xxxxxxxxxxxxxxx>]

Daimao wrote:
> I thought it was net.link.ether.bridge_ipfw=1 to enable IPFW at the
> data link layer.  That and running it both on the data link layer and
> network layer just seems like a bad idea, I usually disable IPFW at
> the network layer when I do bridging (DUMMYNET).  Though I probably
> misunderstood you completely and there's nothing but decaf in the
> house right now T

This is taken from the ipfw man pages and explains the meaning of the 
various sysctl tunables.

^     to upper layers	 V
|			 |
+----------->-----------+
^			 V
[ip_input]	    [ip_output]   net.inet.ip.fw.enable=1
|			 |
^			 V
[ether_demux]    [ether_output_frame]  net.link.ether.ipfw=1
|			 |
+-->--[bdg_forward]-->--+	  net.link.ether.bridge_ipfw=1
^			 V
|	to devices	 |


I've tested in a bridge configuration and everything appears to work 
fine. The reason I run with net.link.ether_ipfw=1 is to perform MAC 
filtering on wi0. (This is the same IPFW2 config that I use on FreeBSD 
machines. I am aware of the limitations of MAC filtering!)

I mentioned it because it is similar to another problem I'm having with 
ipfw2 and divert sockets in that certain tcp packets disappear after 
being processed and accepted. (Received divert traffic from natd).

I've looked through the code but I don't understand any of it enough to 
find whats wrong. The ipfw(v1) code works with natd without issue but 
lacks a lot of ipfw2's features.

I'm looking at DragonFly because I think it's interesting and a possible 
upgrade path once BSD 4.11 is depreciated. OpenBSD's pf is looking a 
nice alternative to ipfw2 but I don't think anyone has ported the 
ability to tag packets in the OpenBSD bridge module based on MAC address 
to any of the other BSDs. (Maybe an good excuse to revamp all of my 
firewalls.)

Regards
G.Allan