Project

General

Profile

Actions

Feature #13653

closed

Failing to enable promiscuous mode should not be a fatal error in snoop(1M)

Added by Jason King 9 months ago. Updated 8 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
cmd - userland programs
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

Currently in snoop(1M), the the process to setup the desired interface for capture is (very) roughly:

if (!PFlg) { /* no -P flag given */ 
    if (dlpi_promiscon(dh, DL_PROMISC_PHYS) != DLPI_SUCCESS)
        exit(FAILURE)
} else {
    if (dlpi_promiscon(dh, DL_PROMISC_MULTI) != DLPI_SUCCESS)
        exit(FAILURE)
}

dlpi_promiscon(dh, DL_PROMISC_SAP)

Some interfaces may not support (or may have disabled) support for either the physical or multicast promiscuous mode (e.g. a hypervisor may disallow vioif to enable promiscuous mode for security reasons), though the final dlpi_promiscon(DL_PROMISC_SAP) still works

Instead of fatally existing, it can still be useful to be able to capture whatever traffic is available via the use of DL_PROMISC_SAP. We should change the fatal errors into warnings and proceed. An operator can then choose to cancel the capture if they want.


Related issues

Related to illumos gate - Feature #13637: Support promiscuous mode on vioif interfacesClosedJason King

Actions
Actions #1

Updated by Jason King 9 months ago

  • Related to Feature #13637: Support promiscuous mode on vioif interfaces added
Actions #2

Updated by Jason King 9 months ago

  • Description updated (diff)
Actions #3

Updated by Joshua M. Clulow 9 months ago

Perhaps add a strict mode flag to get the old hard failure back, in case people need that for some reason (e.g., running snoop programmatically)

Actions #4

Updated by Jason King 9 months ago

.. or I suppose a flag to tell snoop not to treat a 'not supported' failure as fatal would be another way to do it.

Is there any precedence for either method (in terms of flags used) that might be useful to follow (for consistency purposes)? I could see -f to mean "proceed even if dlpi_promiscon(...) calls fail" (ala rm -f) if you squint a bit, but nothing is immediately coming to mind for a 'strict mode' (and both -s and -S are already used) -- so I wonder if maybe providing the functionality that way might be better. Thoughts?

Actions #5

Updated by Jason King 9 months ago

However it appears there's an undocumented -f flag, so that won't work..

Actions #6

Updated by Electric Monk 8 months ago

  • Gerrit CR set to 1364
Actions #7

Updated by Jason King 8 months ago

Doing a bit more research, the -f flag appears to have been added in 1992 for compatibility for some unknown utility and was deliberately never documented.

As such, and given that it appears no one is even aware of the existance of the flag despite its age nor of what it was supposed to be compatible with (the usage was -f src:dst and was equivalent to snoop .... src dst), it seems safe to re-use this since it seems the best available flag with a meaning analogous to other utilities.

As such, snoop -f will force snoop to treat dlpi_promiscon() failures as non-fatal (and emit a warning). For fatal errors, we will include mention of the -f flag.

Actions #8

Updated by Jason King 8 months ago

To test this, for the snoop(1M) changes, I viewed the resulting man page and made sure the additional content was present and appeared to be formatted appropriately.

For the changes to the program itself, I first tried to run snoop against a physical interface (igb device). I saw the expected traffic, and no warnings (as expected since the driver implements promiscuous mode).

I then tried the snoop binary against an vioif interface on a VM running under bhyve on SmartOS (which does not have promiscuous mode support). The current vioif driver silently ignores all requests for promiscuous mode, and so no warnings were seen (or expected).

I then booted a VM w/ the vioif control queue/promiscous support on the same hypervisor -- where the vioif driver will return an error if the host does not support/allow the vioif interface to use promiscuous mode. Running snoop failed with an error that setting promiscuous mode failed (as expected). Running snoop -f returned a warning as expected, and the traffic looked similar to what was seen with the unmodified vioif driver. I repeated the same test with the -P flags (snoop -P/snoop -Pf) with similar results.

Just for completeness, I also booted a VM w/ the modified vioif driver under VirtualBox setup to allow promiscuous mode, and snoop ran as expected (without warnings).

Actions #9

Updated by Electric Monk 8 months ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit a7792e7bce645a8015cc7d0eda87b7a21f380874

commit  a7792e7bce645a8015cc7d0eda87b7a21f380874
Author: Jason King <jason.king@joyent.com>
Date:   2021-03-24T20:52:43.000Z

    13653 Failing to enable promiscuous mode should not be a fatal error in snoop(1M)
    Reviewed by: C Fraire <cfraire@me.com>
    Reviewed by: Andy Fiddaman <andy@omniosce.org>
    Reviewed by: Gordon Ross <gordon.w.ross@gmail.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Actions

Also available in: Atom PDF