On Thu, Nov 08, 2001 at 06:33:01PM +0100, Bart De Schuymer wrote:
> > > 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). > > > > I don't think we would have 'left-over' ip packets when routing? Besides, > > I don't think we should make decisions like 'route this packet because the > > bridge doesnt want it'. We have to do the selection in ebtables, and > stick > > with that selection. > > Well, if you don't want any ip packets dropped, then you need to send the ip > packets with MAC destination other than the bridge to the bridge code. > The ip stack will drop those packets in net/ipv4/ip_input.c:ip_rcv(). OK, I understand now. Your point is that all ROUTE packets will have an ethernet destination address that is identical to the bridge interface's address, while BRIDGE packets will have a destination address that is different, no? > > > 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' This makes more sense now, in the light of the above. So what you say is: - Have the decision of whether or not the bridge processes the packet depend on ebtables' 'bridge' verdict. - Have the decision of whether the protocol module processes the packet depend on the protocol module in question (e.g. ip_rcv in case op IPv4). Yes? No? If so, can't we just modify the bridge hook to always pass packets up, and to the relevant bridge filtering before the regular ebtables mangling/filtering in PF_BRIDGE/PRE_ROUTING? cheers, Lennert _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
