Ok, here's a puzzle if you have time. I've used the old bridging stuff on a 2.2 kernel JUST doing bridging and filtering with no trouble. I then moved to the 2.4 kernels on newer hardware and all was well. I recently added a couple of NICs to the machine that does the bridging to run a couple of 'fake' subnets on 192.168.0.0/24 and 192.168.1.0/25 (long story, don't ask). The general idea was to NAT the fake subnets onto the IP of the bridge (I've got the 2 bridging cards without IPs and the virtual br0 interface with one). Well, I put wireless on one of the new interfaces and wanted to filter it in the FORWARD chain (just like I do on the bridging interface - and how I do at home though it doesn't bridge) based on MAC addresses of 'approved' cards rather than something like destination IP, etc. I put the MACs of the wireless cards in question into my iptables script and it won't match them. It just fails out of the iptables checks like it isn't one of those MACs. Well crap. So I play for a long time tryi! ng different things and I finally luck out and figure out that if I allow the MAC of the bridge interface (which it grabs from the eth0 card in the bridge) it matches. So, all my packets from the 2 non-bridged NICs are getting their MACs rewritten BEFORE the FORWARD chain checks. Bug? Feature?
Basically, am I missing something or does that sounds right to your design of the hooks in the kernel? If so, is there a way to fix this or is this the way it has to be for some other reason since I'd guess this is a fairly rare need compared to the desire for an invisible filter without an IP. Thanks for your time. Logan Freeman '00 Network Administrator The Association of Former Students Texas A&M University (979) 845-7514 www.AggieNetwork.com Solution to all network problems: sed -e 's/windows/linux/g' -e 's/novell/linux/g' _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
