DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ben Magistro <koncept1@gmail.com>
To: dev@dpdk.org, "Kaur, Arshdeep" <arshdeep.kaur@intel.com>,
	 Stephen Hemminger <stephen@networkplumber.org>
Cc: ben.magistro@trinitycyber.com
Subject: dumpcap, interfaces, and promiscuous mode
Date: Tue, 27 Dec 2022 09:26:14 -0500	[thread overview]
Message-ID: <CAKx8PBgWFvyOqOPWmycpmoNnBTPFqyt2g6F9_yaK1D+xOSEq0g@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

I'd like to start out by saying what I believed to be a simple change
(a8dde09 ("app/dumpcap: allow help/version without primary process")) seems
to have had more ripples than I anticipated.  I'd like to just get a
conversation going here before developing/submitting a patch.  I think this
will likely need to be at least two patches just to keep scope in check.

With regard to interface selection, the most recent patch (7f3623a
("app/dumpcap: fix select interface")) breaks capturing on
multiple interfaces.  You can still specify the `-i` option as many times
as you would like but only the last entry is used in the capture selection
as each entry just overwrites the previous entry.  I believe this needs to
be flipped to an array or similar structure that can have entries
appended to it as the arguments are processed.  Selecting all interfaces
with the asterisk seems to be unaffected but could also result in capturing
traffic on unnecessary interfaces.

With regard to promiscuous mode, there are two areas of concern here.  The
first is this flag is global and not per interface.  I can envision a
scenario where you might want to capture on one interface in promiscuous
mode and on a second not in promiscuous mode.  My first thought is to make
this option follow the interface parameter then when parsing arguments so
that it can be associated with a specific interface.  The second is that if
I run a capture in promiscuous mode and then stop the capture, it will also
disable promiscuous mode.  Generally I think I would agree with this
behavior as it follows how a typical call to tcpdump should behave.  The
concern here though is that that the main process may have been
started/running with promiscuous mode and stopping a capture would change
that mode for the main process.  My first thought here is to query the
initial state and check that when quitting to know if it should disable
promiscuous mode or not.  This brings me to another aspect here and I don't
think changing the behaviour of the `-p` flag is appropriate, but can see
maybe adding an option to inherit the main process's promiscuous state(s)
when starting.

Happy to try and work on some of these changes but want to talk through the
issues first so we can try to address all of them.

Cheers,

Ben Magistro

[-- Attachment #2: Type: text/html, Size: 2492 bytes --]

             reply	other threads:[~2022-12-27 14:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-27 14:26 Ben Magistro [this message]
2022-12-27 16:43 ` Stephen Hemminger
2022-12-28 14:12   ` Ben Magistro
2022-12-28 17:10     ` Stephen Hemminger

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=CAKx8PBgWFvyOqOPWmycpmoNnBTPFqyt2g6F9_yaK1D+xOSEq0g@mail.gmail.com \
    --to=koncept1@gmail.com \
    --cc=arshdeep.kaur@intel.com \
    --cc=ben.magistro@trinitycyber.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.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).