> 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. so, if and only if the out dev is bond to a bridge dev would this side effect happen, right?
>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... as source mac address match is a basic function of netfilter(not in patch-o-matic), it would be better to have a note in the man page. Regards, Zeng Yu _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
