----- Original Message -----
From: "Lennert Buytenhek" <[EMAIL PROTECTED]>
To: "zheng chuanbo" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, November 01, 2001 10:07 PM
Subject: Re: [Bridge] can i use brctl on
bridge-nf-0.0.1-against-2.4.13-ac3.diff

Hello

<snip>
> (Bart: can we add a return code like 'ROUTE' to ebtables? It would
> be similar in spirit to 'ACCEPT', but it would cause the packet to
> be passed up the stack on the original interface (say eth0) instead
> of on the bridge interface (say br0).  This would make it possible
> to do a route-protocol-A-but-bridge-protocol-B hack as done here.
> Preferred way of hooking into the bridge code:
net/core/dev.c:net_rx_action.
>
> old:
>
>                         if (skb->dev->br_port != NULL &&
>                             br_handle_frame_hook != NULL) {
>                                 handle_bridge(skb, pt_prev);
>                                 dev_put(rx_dev);
>                                 continue;
>                         }
>
> new (something along the lines of):
>
>                         if (skb->dev->br_port != NULL &&
>                             br_handle_frame_hook != NULL &&
>     ebtables_verdict(skb) == IP_BRIDGE) {
>                                 handle_bridge(skb, pt_prev);
>                                 dev_put(rx_dev);
>                                 continue;
>                         } else {
> // ebtables_verdict is IP_ROUTE; do nothing
> }
Ah, this would be cool.
I think it can be integrated in ebtables without making things ugly.
I can make a new table (currently there is the 'filter' and 'nat' table),
maybe call it 'what2bridge'.
meaning of the possible decisions:
BRIDGE: let the bridge handle the packet
ROUTE: don't let the bridge handle the packet
LOG && CONTINUE: same behaviour as in the other tables
Using ebtables we could then say something like this:

ebtables -t what2bridge -A PRE_ROUTING -p IPV4 -d $my_ip_address -j ROUTE
ebtables -t what2bridge -P BRIDGE

to only route ip packets that were sent to the bridge box and bridge all
other packets (including the left-over ip packets).
We probably need only 1 chain and PRE_ROUTING seems like the best name for
it.
I can map ROUTE and BRIDGE on DROP and ACCEPT in the userspace program. So
the kernel still uses NF_DROP and NF_ACCEPT (keeps everything more
goodlooking, I think). So then the code in net_rx_action() would use
something like
'ebtables_verdict(skb) == NF_ACCEPT'
I will put this on my todo list :-)

Any comments?

cheers,
Bart
>
>
> cheers,
> Lennert
>

_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge

Reply via email to