From: Patrick McHardy <kaber@trash.net>
To: David Miller <davem@davemloft.net>
Cc: j.neuner@networkharbor.com, netdev@vger.kernel.org
Subject: Re: IGMP sent to Foreign VLAN
Date: Wed, 08 Oct 2008 01:53:27 +0200 [thread overview]
Message-ID: <48EBF677.1060602@trash.net> (raw)
In-Reply-To: <20081007.160702.189194318.davem@davemloft.net>
David Miller wrote:
> From: Jarod Neuner <j.neuner@networkharbor.com>
> Date: Mon, 6 Oct 2008 14:51:47 -0500
>
>
>> 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.
>>
>
> Interesting.
>
Indeed.
> Patrick, any opinion?
>
I don't like a /proc flag very much, but I believe it should be
configurable. To make this behaviour consistent there also needs
to be some indication to drivers to disable hardware filters, so
we really should have an explicit action from the user first.
We've been talking about an IFF_ALLVLAN flag on netdev a while
ago, which would disable VLAN hardware filters, similar to
IFF_ALLMULTI. An additional flag on the ethernet device could
indicate that it should receive unknown VLANs directly. That
would introduce some possible inconsistencies however since the
flag could be set without the VLAN code even loaded, in which
case it would not have any effect.
Another possibility would be to use a catch-all VLAN device with
VID 0xfff (reserved for implementation use). This would allow
to configure priority mappings, header reordering etc. and have
separate statistics. The drivers could just use the magic VID
as an indication to disable filtering, but I would still suggest
to add the IFF_ALLVLAN flag because its useful on its own.
>> 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;
>>
This can't be right though, the packet needs to be passed
up the stack. The same change will also be needed in
__vlan_hwaccel_rx().
next prev parent reply other threads:[~2008-10-07 23:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-06 19:51 IGMP sent to Foreign VLAN Jarod Neuner
2008-10-07 23:07 ` David Miller
2008-10-07 23:53 ` Patrick McHardy [this message]
2008-10-08 23:34 ` Jarod Neuner
2008-10-09 12:31 ` Patrick McHardy
2008-10-09 16:18 ` Jarod Neuner
2008-10-10 16:28 ` Patrick McHardy
2008-10-10 22:45 ` Benny Amorsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48EBF677.1060602@trash.net \
--to=kaber@trash.net \
--cc=davem@davemloft.net \
--cc=j.neuner@networkharbor.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).