On Mon, Jun 19, 2006 at 10:04:46AM -0700, Ben Greear wrote: > Alex Zeffertt wrote: > >Frederik Deweerdt wrote: > > >IMHO, raw sockets *should* always tag, rather than tag or not tag > >depending on whether the > >frame is already tagged. It just seems more logical and consistent. > > If a program is clever enough that it thinks it can send raw packets, > I think it can send vlan tags too. But, we have to be able to remain > backwards compat allowing sending raw ether frames to a vlan and have > the vlan encapsulate. I would expect a raw socket to be no different from an IPv4 socket. If the socket is bound to an interface, the socket should expect an ethernet packet and that packet should be sent out the interface without interference: packet on socket on eth0 = no tag on packet on wire packet on socket on eth0.1 = VLAN1 tag on packet on wire packet on socket on eth0.1.2 = VLAN2 tag on VLAN1 tag on packet on wire The above should hold true regardless of packet contents: VLAN3 tag on packet on socket on eth0 : VLAN3 tag on packet on wire VLAN3 tag on packet on socket on eth0.1 : VLAN1 tag on VLAN3 tag on packet on wire VLAN3 tag on packet on socket on eth0.1.2 : VLAN2 tag on VLAN1 tag on VLAN3 tag on packet on wire Likewise for qinq (and qinqinq, etc) on socket: VLAN4 tag on VLAN3 tag on packet on socket on eth0 : VLAN4 tag on VLAN3 tag on packet on wire VLAN4 tag on VLAN3 tag on packet on socket on eth0.1 : VLAN1 tag on VLAN4 tag on VLAN3 tag on packet on wire VLAN4 tag on VLAN3 tag on packet on socket on eth0.1.2 : VLAN2 tag on VLAN1 tag on VLAN4 tag on VLAN3 tag on packet on wire In short: Sending on a physical interface will never add tags. Sending on a VLAN interface will only ever add one or more tags. > However, I don't think we have to allow sending a vlan frame to a > vlan device and have it double-encapsulate. I would indeed expect qinq here. It's more work but I don't see any other reason for a compromise. Let it take longer to finish rather than being broken. :p > Perhaps the check could be: I say no check at all, if possible without breaking backwards compatibility. > I think that will work in all currently supported cases, except > where user-space sends a frame for a different VID to a VLAN. I > believe bridging could do this currently, so we would have to fix > bridging somehow. > > There would need to be a global config, either run-time or compile > time, that would make the behaviour act like it does currently in > case we need to work around any user-space or other kernel module > issues. Agreed, we must be backwards-compatible. If need be q(inq)+ can require explicit enabling with vconfig. //Peter
