> To make things more clear, I tried another test. > > A<--->eth0--brg0--eth1<--->B > > eth0 and eth1 are bond to make a bridge device brg0, host A connects > linux box through eth0, host B connects through eth1. > > if A's default gw set to B, thus the linux box working in bridging mode, > there's no problem, > $iptables -A FORWARD -m mac --mac-source MAC_ADDR_OF_A > matching packets as expected. > But, changing A's default gw to the linux box, thus make it working in > routing mode, the bug appears.
OK, I think I understand the mystery now. If you would check on the MAC address of the bridge instead of the one of computer A you would get a match. Why? Because the FORWARD table is traversed when the packet is already in the bridge code. The ip code will have changed the MAC source address to that of the bridge. As the ip code is executed before the traversal of the FORWARD chain you get this strange side effect. Note that this behaviour is purely the doing of the br-nf patch. Why is the br-nf patch postponing the traversal of the FORWARD chain until it's in the bridge code? Because that's why one is able to use the bridge ports in filter rules using the -o option in the FORWARD chain. I suggest using the PREROUTING chain for rules needing these MAC source addresses, if possible. Yes, that's dirty :-(. Getting rid of this bug (or feature ;)) would need an ugly hack and I don't know if it's worth it... Lennert? cheers, Bart _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
