Alex Zeffertt wrote: > Ben wrote: > >>If a packet with VID of 6 is to be transmitted on a vlan device with >>VID 7, we change the VID to match the vlan device. This makes bridging >>work, I believe. > > > Hmmm, why does it do this? This doesn't make sense to me. > > Anyway, I've got Q in Q to work now but it's a complete hack and you probably won't like it much. > I'm attaching the patch anyway in case anybody wants to look at it. > > I've tested that pinging between devices terminating singly tagged frames works > > (machine1: machine2) > eth0.16 <---- ping ----> eth0.16 > eth0 eth0 > > I've also tested that pinging between devices terminating doubly tagged frames works > > > (machine1: machine2) > eth0.16.5 <---- ping ----> eth0.16.5 > eth0.16 eth0.16 > eth0 eth0 > > And I've tested bridging still works in the following scenario > > > (machine0 machine1 machine2) > br0 > eth0 <------- eth1 eth0.16.5 --------- ping ----------> eth0.16.5 > eth0.16 eth0.16 > eth0 eth0 > > > I *haven't* tested how this interacts with hardware acceleration or the REORDER_HEADER flag though. > I'm not really sure how to go about that! > > The change is to simply use the real_dev's rebuild_header and hard_header, and *always* > add the 4 byte tag on transmit. > > I'd appreciate any comments regarding how this should be done properly. From a brief glance at the code, I bet that a program opening a raw socket and passing a pre-constructed VLAN packet to the VLAN device will cause double encapsulation, which is not what I would want to happen. If we do not add the additional 4 byte header when the VIDs are the same, I believe that would fix that problem. It would create a small problem for your device in that the users could not use the VLANs that your box uses internally. I'm glad to see that bridging works...the bridge code must be smart enough to strip the tags before sending the packet to the new vlan device. Thanks, Ben > > Alex -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com
