Dylan Hall wrote:
I've been trying to get vlan stacking (q in q) going and have produced a
small patch that seems to make it work for me:
diff -Naur linux-2.6.20.4/net/8021q/vlan_dev.c
linux-2.6.20.4-qinq/net/8021q/vlan_dev.c
--- linux-2.6.20.4/net/8021q/vlan_dev.c 2007-03-24 07:52:51.000000000 +1200
+++ linux-2.6.20.4-qinq/net/8021q/vlan_dev.c 2007-07-30
11:50:49.000000000 +1200
@@ -445,7 +445,6 @@
* OTHER THINGS LIKE FDDI/TokenRing/802.3 SNAPs...
*/
- if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) {
int orig_headroom = skb_headroom(skb);
unsigned short veth_TCI;
@@ -474,7 +473,6 @@
if (orig_headroom < VLAN_HLEN) {
VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++;
}
- }
#ifdef VLAN_DEBUG
printk(VLAN_DBG "%s: about to send skb: %p to dev: %s\n",
The patch is against 2.6.20.4.
My test setup looked something like:
vconfig set_name_type DEV_PLUS_VID_NO_PAD
ip link set eth1 up
vconfig add eth1 100
ip link set eth1.100 up
vconfig add eth1.100 50
ip link set eth1.100.50 up
ip a add 10.100.50.1/24 dev eth1.100.50
ip link set eth1.100.50 mtu 1500
followed by pinging an imaginary device on the same subnet and using
tcpdump to observe what is sent.
What I was seeing is the above would produce packets with vlan id 50
(inner vlan) but the outer tag wasn't being inserted. These tests were
carried out using an e100 and a natsemi interface.
I repeated the tests with an e1000 which has hardware accelerated vlan
support. This second test did work, with the caveat that tcpdump on the
sender doesn't show the second tag, but tcpdump on a remote machine does.
This struck me as a little odd, so I had a poke around at the kernel
source. It would appear that the routine vlan_dev_hard_start_xmit, which
does the actual tag insertion for non-hardware accelerated interfaces
only inserts the tag if one is not already present. Removing this check
(e.g. always insert the tag) seems to work nicely for me :)
So my questions are:
What might I break be removing this test?
Bridges with multiple vlan interfaces (same VID) where the REORDER flag
has be unset (default is set).
Is there a smarter/better way of doing this?
Can this, or a similar fix be made part of the code for future kernel
releases?
We've discussed this before. Try following this thread:
http://osdir.com/ml/linux.drivers.vlan/2005-07/msg00046.html
BTW, this works for us!
Alex
Thanks,
Dylan
------------------------------------------------------------------------
_______________________________________________
Vlan mailing list
Vlan@xxxxxxxxxxxxxxx
http://www.candelatech.com/mailman/listinfo/vlan
_______________________________________________
Vlan mailing list
Vlan@xxxxxxxxxxxxxxx
http://www.candelatech.com/mailman/listinfo/vlan
