All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: andrei radulescu-banu <iubica2@yahoo.com>
Cc: Ben Greear <greearb@candelatech.com>,
	Patrick McHardy <kaber@trash.net>,
	Krzysztof Halasa <khc@pm.waw.pl>,
	linux-kernel@vger.kernel.org,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: Linux, tcpdump and vlan
Date: Thu, 19 Jul 2007 20:28:10 +0100	[thread overview]
Message-ID: <20070719202810.4d9ee230@oldman> (raw)
In-Reply-To: <839334.9648.qm@web56605.mail.re3.yahoo.com>

On Thu, 19 Jul 2007 11:20:43 -0700 (PDT)
andrei radulescu-banu <iubica2@yahoo.com> wrote:

> > [Ben] If tcpdump and/or bridging needs to disable the hw-accel, then it can 
> explicitly do so by some API.  That is better than overloading
> the promisc flag in my opinion.  
> 
> I guess I could be persuaded in the end. But let me still play devil advocate. The semantics of 'promiscuous', in my opinion, mean 'receive everything', including vlan.
> 
> > [Ben] This is especially true since promisc 
> is not easily readable by user-space and things like tcpdump
> cannot have full control of promisc (if a mac-vlan has the NIC in 
> promisc mode, for instance, then tcpdump can never disable it.)
> 
> I agree with all the above. For example when you run 'ifconfig' during 'tcpdump', the interface does not have the promiscuous flag set!! 

In kernel it is a nice atomic counter, no problem.

> 
> This confused me for a while, until I realized that tcpdump's packet socket was using an obscure packet_dev_mc() API (af_packet.c) to get the interface in promiscuous mode. The reason for this is that packet_mc_add() implements a reference counted mechanism for promiscuous. So that:
> - starting tcpdump instance 1 sets promiscuous mode
> - starting tcpdump instance 2 bumps the ref count in packet_mc_add()
> - killing tcpdump instance 1 bumps down the ref count, the interface stays promiscuous
> - killing tcpdump instance 2 truly clear promiscuous mode.
> 
> The trick here is that when you kill tcpdump, the kernel clears the packet socket, and in process bumps down the ref count. Had tcpdump manually set/cleared the promisc flag, the interface would have stayed promisc after tcpdump was killed.
> 
> (The mac-vlan driver must have this corner problem as well. If a mac-vlan interface is disabled while tcpdump runs, it may yank promiscuousness from under tcpdump.)

The kernel has no such problem

> So if you want to create an ethtool API to set vlan-promiscuous mode, one problem to grapple is that we need a similar mechanism to the above, so you can run two concurrent tcpdump's (or tcpdump while bridging vlans) and the vlan-promiscuous mode gets set correctly each time.  For tcpdump at least, the new ethtool API needs to be called from packet_mc_add().

  reply	other threads:[~2007-07-19 19:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-19 18:20 Linux, tcpdump and vlan andrei radulescu-banu
2007-07-19 19:28 ` Stephen Hemminger [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-07-19 21:38 andrei radulescu-banu
2007-07-19 23:38 ` Ben Greear
2007-07-20 20:19   ` Krzysztof Halasa
2007-07-19 17:46 andrei radulescu-banu
2007-07-19 16:02 andrei radulescu-banu
2007-07-20 19:58 ` Krzysztof Halasa
2007-07-20 20:34   ` Ben Greear
2007-07-21 11:32     ` Krzysztof Halasa
2007-07-21 17:57       ` Ben Greear
2007-07-21 21:15         ` Krzysztof Halasa
2007-07-19 15:47 andrei radulescu-banu
2007-07-19 16:21 ` Stephen Hemminger
2007-07-19 16:33 ` Patrick McHardy
2007-07-19 16:47 ` Ben Greear
2007-07-18 19:34 andrei radulescu-banu
2007-07-18 22:57 ` Patrick McHardy
2007-07-18 23:22   ` Ben Greear
2007-07-18 23:34     ` Patrick McHardy
2007-07-19  0:01       ` Ben Greear
2007-07-19  0:19         ` Patrick McHardy
2007-07-19 13:28   ` Krzysztof Halasa
2007-07-19 13:41     ` Stephen Hemminger
2007-07-19 14:00       ` Patrick McHardy
2007-07-19 14:23       ` Krzysztof Halasa
2007-07-19 15:00         ` Stephen Hemminger
2007-07-19 15:45           ` Krzysztof Halasa
2007-07-19 15:20         ` Stephen Hemminger
2007-07-20 10:50 ` Florian Lohoff

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=20070719202810.4d9ee230@oldman \
    --to=shemminger@linux-foundation.org \
    --cc=greearb@candelatech.com \
    --cc=iubica2@yahoo.com \
    --cc=kaber@trash.net \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.