more on pfil and bridging

The more I look at this the more I think that it is broken.

Instead of the bridge registering a separate filter queue
for itself,
it is using the queues set up by the IP stack.

It should register its own stack and each filter type should
register their own filter functions for that level on the
stack.

is there a reason that this is not done? If the answer is
simply
ENOTIME then I will volunteer to go through it and do it
properly.

suggested changes:

I propose to create filter queues for if_ethersubr.c and
if_bridge.c
distinguished by slightly different keys. I also propose to
rename
inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks).

I would also look at following the documentation by seeing
whether
we shouldn't be using a DLT/KEY instead of PFIL_AF and
AF_INET
as the key type/key.

The Direction argument should be expanded to be a generic
'flags'
argument where two of the flags are direction.
Other flags can be:
WAIT_OK:	(It's already defined to be there)
HOST_ORDER:	Fields in the header have been swapped to host
order.

The ipfw code would supply different entry points for bridge
and Ethernet supplied packets.

the ipfw args struct should grow a 'flags' field that can
indicate (for example) that the IP header fields have not
been
put in host order (or have) and that the packet is from a
bridge
rather than just being layer2.

ipfw would grow a 'bridge' keyword to check that flag.




Julian

_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

On Saturday 21 October 2006 03:28, Julian Elischer wrote:
> The more I look at this the more I think that it is
broken.
>
> Instead of the bridge registering a separate filter
queue for itself,
> it is using the queues set up by the IP stack.
>
> It should register its own stack and each filter type
should
> register their own filter functions for that level on
the stack.
>
> is there a reason that this is not done? If the answer
is simply
> ENOTIME then I will volunteer to go through it and do
it properly.

I guess so.

> suggested changes:
>
> I propose to create filter queues for if_ethersubr.c
and if_bridge.c
> distinguished by slightly different keys. I also
propose to rename
> inet_pfil_hook to be inet_pfil_head (or
inet_pfil_hooks).
>
> I would also look at following the documentation by
seeing whether
> we shouldn't be using a DLT/KEY instead of PFIL_AF and
AF_INET
> as the key type/key.

I think if_ethersubr.c and if_bridge.c should pass to the
same pfil hook.  
And I'd vote for the current - very sophisticated -
if_bridge.c filtering 
to stay, at least as opt-in.  Otherwise it will be tricky to
support 
stateful filtering in pf on transparent bridges.

> The Direction argument should be expanded to be a
generic 'flags'
> argument where two of the flags are direction.
> Other flags can be:
> WAIT_OK:	(It's already defined to be there)
> HOST_ORDER:	Fields in the header have been swapped to
host order.
>
> The ipfw code would supply different entry points for
bridge
> and Ethernet supplied packets.
>
> the ipfw args struct should grow a 'flags' field that
can
> indicate (for example) that the IP header fields have
not been
> put in host order (or have) and that the packet is from
a bridge
> rather than just being layer2.
>
> ipfw would grow a 'bridge' keyword to check that flag.

I don't think that is necessary.  Right now we also have a
mode to pass 
bridged packets as "normal" L2 packets.  ipfw
doesn't discriminate 
between packets from if_ethersubr.c and if_bridge.c - and I
don't see why 
it should.  If discrimination is required one can still fall
back on the 
L3decap in if_bridge.c - see above.

-- 
/"  Best regards,                      | mlaierfreebsd.org
 /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.l
ove2party.net/  | mlaierEFnet
/   ASCII Ribbon Campaign              | Against HTML Mail
and News

Max Laier wrote:
> On Saturday 21 October 2006 03:28, Julian Elischer
wrote:
>> The more I look at this the more I think that it is
broken.
>>
>> Instead of the bridge registering a separate filter
queue for itself,
>> it is using the queues set up by the IP stack.
>>
>> It should register its own stack and each filter
type should
>> register their own filter functions for that level
on the stack.
>>
>> is there a reason that this is not done? If the
answer is simply
>> ENOTIME then I will volunteer to go through it and
do it properly.
> 
> I guess so.
> 
>> suggested changes:
>>
>> I propose to create filter queues for
if_ethersubr.c and if_bridge.c
>> distinguished by slightly different keys. I also
propose to rename
>> inet_pfil_hook to be inet_pfil_head (or
inet_pfil_hooks).
>>
>> I would also look at following the documentation by
seeing whether
>> we shouldn't be using a DLT/KEY instead of PFIL_AF
and AF_INET
>> as the key type/key.
> 
> I think if_ethersubr.c and if_bridge.c should pass to
the same pfil hook.  
> And I'd vote for the current - very sophisticated -
if_bridge.c filtering 
> to stay, at least as opt-in.  Otherwise it will be
tricky to support 
> stateful filtering in pf on transparent bridges.

Ather and bridge need to be distinguishable.
Believe me. I do this in a product  and I need to tell them
apart.

> 
>> The Direction argument should be expanded to be a
generic 'flags'
>> argument where two of the flags are direction.
>> Other flags can be:
>> WAIT_OK:	(It's already defined to be there)
>> HOST_ORDER:	Fields in the header have been swapped
to host order.
>>
>> The ipfw code would supply different entry points
for bridge
>> and Ethernet supplied packets.
>>
>> the ipfw args struct should grow a 'flags' field
that can
>> indicate (for example) that the IP header fields
have not been
>> put in host order (or have) and that the packet is
from a bridge
>> rather than just being layer2.
>>
>> ipfw would grow a 'bridge' keyword to check that
flag.
> 
> I don't think that is necessary.  Right now we also
have a mode to pass 
> bridged packets as "normal" L2 packets.  ipfw
doesn't discriminate 
> between packets from if_ethersubr.c and if_bridge.c -
and I don't see why 
> it should.  If discrimination is required one can still
fall back on the 
> L3decap in if_bridge.c - see above.

I really need to distinguish between the two cases.

> 
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"