Message-ID: <c25bca517739ada31d698235c3a4d045@dondevamos.com>
Date:	Sun, 13 Jun 2010 21:20:03 +0200
From:	Pedro Garcia <pedro.netdev@...devamos.com>
To:	<netdev@...r.kernel.org>
Subject: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)

Hi,

I am using kernel 2.6.26 in a linux box, and I have another box in the
network using 802.1p (priority tagging, but no VLAN).

Without the 8021q module loaded in the kernel, all 802.1p packets are
silently discarded (probably as expected, as the protocol is not loaded in
the kernel).

When I load 8021q module, these packets are forwarded to the module, but
they are discarded also as VLAN 0 is not configured.

I think this should not be the default behaviour, as VLAN 0 is not really
a VLAN, so it should be treated differently.

I could define the VLAN 0 (ip link add link eth0 name eth0.dot1p type vlan
id 0), but then I have a lot of issues with the ARP table entries, as to
ping the other box, outgoing traffic goes through eth0, but incoming arp
reply ends up in eth0.dot1p. In the end this means I can not communicate
with the box using 802.1p unless I use 802.1p tagging for all traffic in
the network (the linux box and all other), which is not a must of the spec.

I have developed a patch for vlan_dev.c which makes VLAN 0 to be just
reintroduced to netif_rx but with no VLAN tagging if VLAN 0 has not been
defined, so the default behaviour is to ignore the VLAN tagging and accept
the packet as if it was not tagged, and one can still define something
different for VLAN 0 if desired (so it is backwards compatible).

=======================================================================
*** linux-source-2.6.26/net/8021q/vlan_dev.c    2008-07-13
23:51:29.000000000 +0200
--- vlan_patch/net/8021q/vlan_dev.c     2010-06-13 20:24:46.000000000
+0200
*************** int vlan_skb_recv(struct sk_buff *skb, s
*** 151,156 ****
--- 151,157 ----
        struct vlan_hdr *vhdr;
        unsigned short vid;
        struct net_device_stats *stats;
+       struct net_device *vlan_dev;
        unsigned short vlan_TCI;
  
        skb = skb_share_check(skb, GFP_ATOMIC);
*************** int vlan_skb_recv(struct sk_buff *skb, s
*** 165,176 ****
        vid = (vlan_TCI & VLAN_VID_MASK);
  
        rcu_read_lock();
!       skb->dev = __find_vlan_dev(dev, vid);
!       if (!skb->dev) {
                pr_debug("%s: ERROR: No net_device for VID: %u on dev:
%s\n",
                         __func__, (unsigned int)vid, dev->name);
                goto err_unlock;
        }
  
        skb->dev->last_rx = jiffies;
  
--- 166,191 ----
        vid = (vlan_TCI & VLAN_VID_MASK);
  
        rcu_read_lock();
!       vlan_dev = __find_vlan_dev(dev, vid);
!       if(vlan_dev) {
!               skb->dev = vlan_dev;
!       }
!       else if(vid) {
                pr_debug("%s: ERROR: No net_device for VID: %u on dev:
%s\n",
                         __func__, (unsigned int)vid, dev->name);
                goto err_unlock;
        }
+       else {
+               /* 2010-06-13: Pedro Garcia
+                  The packet is VLAN tagged, but VID is 0 and the user
has
+                  not defined anything for VLAN 0, so it is a 802.1p
packet.
+                  We will just netif_rx it later to the original
interface,
+                  but with the skb->proto set to the wrapped proto, so we
do 
+                  nothing here. */
+ 
+               pr_debug("%s: INFO: VLAN 0 used as default VLAN on dev:
%s\n",
+                        __func__, dev->name);
+       }
  
        skb->dev->last_rx = jiffies;
=======================================================================

I do not really have much experience in touching the kernel so maybe I
have done it totally wrong..., but there are no major changes applied, and
this way the 8021q module is more transparently similar to the expected
behaviour of 802.1p (VLAN 0 means no VLAN).

Regards,
Pedro

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists