From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guillaume Gaudonville Subject: Re: VLAN packets silently dropped in promiscuous mode Date: Mon, 25 Oct 2010 15:48:41 +0200 Message-ID: <4CC58AB9.4090903@6wind.com> References: <20100929113757.GA23755@core.hellgate.ch> <20100930080703.GA10827@core.hellgate.ch> <4CB81BF1.1050906@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Roger Luethi , netdev@vger.kernel.org, Patrick McHardy To: Jesse Gross Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:41572 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164Ab0JYNvf (ORCPT ); Mon, 25 Oct 2010 09:51:35 -0400 Received: by wyf28 with SMTP id 28so3426726wyf.19 for ; Mon, 25 Oct 2010 06:51:34 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Jesse Gross wrote: > On Fri, Oct 15, 2010 at 2:16 AM, Guillaume Gaudonville > wrote: > =20 >> Jesse Gross wrote: >> =20 >>> On Thu, Sep 30, 2010 at 1:07 AM, Roger Luethi wrot= e: >>> >>> =20 >>>> On Wed, 29 Sep 2010 10:44:26 -0700, Jesse Gross wrote: >>>> >>>> =20 >>>>> On Wed, Sep 29, 2010 at 4:37 AM, Roger Luethi wr= ote: >>>>> >>>>> =20 >>>>>> I noticed packets for unknown VLANs getting silently dropped eve= n in >>>>>> promiscuous mode (this is true only for the hardware accelerated= path). >>>>>> netif_nit_deliver was introduced specifically to prevent that, b= ut the >>>>>> function gets called only _after_ packets from unknown VLANs hav= e been >>>>>> dropped. >>>>>> >>>>>> =20 >>>>> Some drivers are fixing this on a case by case basis by disabling >>>>> hardware accelerated VLAN stripping when in promiscuous mode, i.e= =2E: >>>>> >>>>> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.gi= t;a=3Dcommit;h=3D5f6c01819979afbfec7e0b15fe52371b8eed87e8 >>>>> >>>>> However, at this point it is more or less random which drivers do >>>>> this. It would obviously be much better if it were consistent. >>>>> >>>>> =20 >>>> My understanding is this. Hardware VLAN tagging and stripping can = always >>>> be >>>> enabled. The kernel passes 802.1Q information along with the strip= ped >>>> header to libpcap which reassembles the original header where nece= ssary. >>>> Works for me. >>>> >>>> =20 >>> Sorry, I misread your original post as saying that the VLAN header >>> gets dropped, rather than the entire packet. I agree that this is = how >>> it should work but not necessarily how it does work (again, dependi= ng >>> on the driver). Here's the problem that I was talking about: >>> >>> Most drivers have a snippet of code that looks something like this >>> (taken from ixgbe): >>> >>> if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK)) >>> vlan_gro_receive(napi, adapter->vlgrp, tag, skb); >>> else >>> napi_gro_receive(napi, skb); >>> >>> At this point the VLAN has already been stripped in hardware. If >>> there is no VLAN group configured on the device then we hit the sec= ond >>> case. The VLAN header was removed from the SKB and the tag variabl= e >>> is unused. It is no longer possible for libpcap to reconstruct the >>> header because the information was thrown away (even the fact that >>> there was a VLAN tag at all). >>> >>> There are a couple ways to fix this: >>> >>> * Turn off VLAN stripping when in promiscuous mode (as done by the = ixgbe >>> driver) >>> >>> =20 >> This is not totally true: if changing the MTU ixgbe_change_mtu will = call: >> ixgbe_reinit_locked--> ixgbe_up --> ixgbe_configure: >> --> ixgbe_set_rx_mode: flag IFF_PROMISC is tested >> ixgbe_vlan_filter_enable is not called >> --> ixgbe_restore_vlan --> ixgbe_vlan_rx_register: fl= ag >> IFF_PROMISC is not tested ixgbe_vlan_filter_enable >> will be called. >> >> In fact it should happen each time we configure something which need= s a >> reset of the device. Why don't add a test >> on flag promiscuous directly in ixgbe_vlan_filter_enable? Or do it o= n each >> call, if we want to allow a device in promiscuous >> mode to enable this feature. >> >> What do you think? >> =20 > > I can believe that there are paths that lead to this not working > correctly. That was actually my larger point: this is something that > is commonly not implemented correctly in drivers. Rather than try to > study every driver my goal is to just avoid the problem completely by > handling vlan acceleration centrally in the networking core. I sent > out an RFC patch series a few days ago that should solve this problem= : > > http://marc.info/?l=3Dlinux-netdev&m=3D128700022614170&w=3D3 > -- > 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 > =20 Thank you, I'm going to check these patches and try to apply them in ou= r=20 kernel. Best Regards, --=20 Guillaume Gaudonville 6WIND Software Engineer Tel: +33 1 39 30 92 63 Mob: +33 6 47 85 34 33 =46ax: +33 1 39 30 92 11 guillaume.gaudonville@6wind.com www.6wind.com Join the Multicore Packet Processing Forum: www.multicorepacketprocessi= ng.com Ce courriel ainsi que toutes les pi=E8ces jointes, est uniquement desti= n=E9 =E0 son ou ses destinataires. Il contient des informations confide= ntielles qui sont la propri=E9t=E9 de 6WIND. Toute r=E9v=E9lation, dist= ribution ou copie des informations qu'il contient est strictement inter= dite. Si vous avez re=E7u ce message par erreur, veuillez imm=E9diateme= nt le signaler =E0 l'=E9metteur et d=E9truire toutes les donn=E9es re=E7= ues This e-mail message, including any attachments, is for the sole use of = the intended recipient(s) and contains information that is confidential= and proprietary to 6WIND. All unauthorized review, use, disclosure or = distribution is prohibited. If you are not the intended recipient, plea= se contact the sender by reply e-mail and destroy all copies of the ori= ginal message.