> > What Ethernet adapter are you using (chipset or linux module name)? > > The kernel module seems to be e1000 > > occ3-devb:~# dmesg | grep eth2 > e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection > e1000: eth2: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex > > My kernel version (in the case it would be needed) is 2.6.14.2. I think what you want to do is create a bridge containing eth2 and whatever else, and then create vlans on the bridge, eg create a br0.200 interface, and therefore never invoke the bridge logic on the e1000. The problem is, as was suspected earlier, that the e1000 contains hardware vlan acceleration which does indeed appear to filter out the vlans you don't care about. Re: ebtables, the linux packet flow looks like this: #1. Packet received on physical interface #2. Packet routed to bridge interface #3. Packet routed to vlan interface If the interface is a bridge port then the packet will never get to #3, which is where ebtables comes in. You can create a rule on ebtables that can add some criteria to what happens at #2, and either route a packet to a bridge or leave it available to the vlan code. If you want to trunk all vlans to your bridge then you don't need to fuss with ebtables at all. If you wanted to trunk only vlan1 (native vlan) to the bridge then you'd need an ebtables rule to DROP all 802.1q packets from the routing table (leaving them to the vlan code), or you could drop only specific vlans. The thing is though, once you have vlan and bridge active in the kernel, you can either let the bridge code have the packet, or let the vlan code have the packet, you can't do both (and it would indeed be nice if you could!) Unfortunately, once you turn on vlanning on the physical e1000 interface, the hardware acceleration will come into play and you won't see the ones you aren't subscribing to anyway. Assuming there isn't already a way and I just can't see it, in order to work around the above problem you'd need to: . patch the vlan kernel module to optionally not use hw acceleration even if it is available, via a parameter to one of the ioctls . patch the vconfig code to add a command line option to make use of the above option Ben would be the best one to comment on how useful the above might be. I could probably put a patch together, but you'd have to test it :) hth James
