From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938048AbXGSPVH (ORCPT ); Thu, 19 Jul 2007 11:21:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756905AbXGSPUv (ORCPT ); Thu, 19 Jul 2007 11:20:51 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:45340 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762596AbXGSPUt (ORCPT ); Thu, 19 Jul 2007 11:20:49 -0400 Date: Thu, 19 Jul 2007 16:20:08 +0100 From: Stephen Hemminger To: Krzysztof Halasa Cc: Patrick McHardy , andrei radulescu-banu , linux-kernel@vger.kernel.org, Linux Netdev List Subject: Re: Linux, tcpdump and vlan Message-ID: <20070719162008.7c94bcaa@oldman.hamilton.local> In-Reply-To: References: <878246.51044.qm@web56608.mail.re3.yahoo.com> <469E9AC8.3090603@trash.net> <20070719144131.0c230c8f@oldman.hamilton.local> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Jul 2007 16:23:48 +0200 Krzysztof Halasa wrote: > Stephen Hemminger writes: > > > 1) non-accelerated device > > * all frames show in promiscious mode > > * tag is part of the frame that shows up > > in tcpdump, and then gets stripped by the 8021q module. > > Sure. It's IMHO good and working, modulo the tag being removed > on the master device (optional cloning or something, IIRC). > > > 2) rx tag stripping device > > * all frames show in promiscious mode > > * tag is in skb but NOT passed to tcpdump > > 3) rx vlan acceleration > > * only frames that for vlan's that are registered show up > > in promisicous mode > > * tag is in skb but NOT passed to tcpdump > > I wasn't aware of devices doing 3. Aren't we able to tell them > to receive all packets anyway (even unknown VLANs#)? See NETIF_F_HW_VLAN_FILTER (e1000, etc). > > Unfortunately, the tag is lost as part of the VLAN acceleration process > > so it is not a simple matter of changing code in AF_PACKET receive > > to restore the tag. > > I'm not sure if we really want it. If needed we can disable > acceleration, can't we? While accelerated we can see the packets > (without tags) on logical devices. Not at runtime, acceleration is always on if you compile kernel with vlan support. That is a design mistake as far as I can tell. > However seeing unknown tags on master device (with tcpdump etc) > would certainly be useful. Only in promiscuous mode. In some sense tag is part of the mac address.