From patchwork Mon Oct 6 19:51:47 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jarod Neuner X-Patchwork-Id: 2979 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 0CE8ADDDF6 for ; Tue, 7 Oct 2008 07:01:43 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752589AbYJFUBh (ORCPT ); Mon, 6 Oct 2008 16:01:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752664AbYJFUBh (ORCPT ); Mon, 6 Oct 2008 16:01:37 -0400 Received: from 75-150-216-245-Illinois.hfc.comcastbusiness.net ([75.150.216.245]:16473 "EHLO mx.networkharbor.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752387AbYJFUBh (ORCPT ); Mon, 6 Oct 2008 16:01:37 -0400 X-Greylist: delayed 587 seconds by postgrey-1.27 at vger.kernel.org; Mon, 06 Oct 2008 16:01:36 EDT X-IronPort-AV: E=Sophos;i="4.33,368,1220245200"; d="scan'208";a="19348" Received: from mailbucket.nh.local ([10.254.0.12]) by mx.networkharbor.com with ESMTP; 06 Oct 2008 14:51:48 -0500 Received: from deepthought.nh.local (10.254.0.162) by mailbucket.nh.local (10.254.0.12) with Microsoft SMTP Server id 8.1.291.1; Mon, 6 Oct 2008 14:56:01 -0500 Subject: IGMP sent to Foreign VLAN From: Jarod Neuner To: Date: Mon, 6 Oct 2008 14:51:47 -0500 Message-ID: <1223322707.24688.46.camel@deepthought.nh.local> MIME-Version: 1.0 X-Mailer: Evolution 2.6.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org I noticed a problem where the kernel is not responding to IGMP Queries from several Level-3 network switches. This behavior is caused by these switches using VLAN tags on IGMP messages. At first I thought the switches were out of spec, but every other network stack I've checked delivers packets with unconfigured VLAN assignments directly to the incoming interface. This patch corrects my problem, but I'm still interested in discussion about whether or not this should be a parameter in /proc/sys/net or even if this policy change should be applied elsewhere in the the network stack. --- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c index 4bf014e..b65a8fd 100644 --- a/net/8021q/vlan_dev.c +++ b/net/8021q/vlan_dev.c @@ -158,9 +158,13 @@ int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev, rcu_read_lock(); skb->dev = __find_vlan_dev(dev, vlan_id); if (!skb->dev) { - pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n", + pr_debug("%s: WARNING: Forwarding VID: %u to dev: %s\n", __func__, vlan_id, dev->name); - goto err_unlock; + skb->dev = dev; + skb_pull_rcsum(skb, VLAN_HLEN); + vlan_set_encap_proto(skb, vhdr); + rcu_read_lock(); + return 0; } skb->dev->last_rx = jiffies;