Promiscuous vs Monitoring mode

While speaking with network professionals about the new Debookee Wi-Fi Monitoring module, I’ve discovered that promiscuous mode is commonly confused with monitoring mode, although they operate on different media, layers & protocols.

To simplify, I’ll only speak about Ethernet as lowest protocol in packet capture, but prehistorical procotols like Token Ring, FDDI… can be seen, although I’ve no idea how they work!


Promiscuous mode

Promiscuous mode is not a packet capture mode, it’s an option of Ethernet packet capture.

Using Wireshark, the capture interface options shows that you could capture Ethernet packets with or without promiscuous mode.

Wireshark capture options. Promiscuous mode is usually supported and enabled by default. See the link-layer set to Ethernet and monitor mode disabled
SIP packet captured in non-promiscuous mode. Ethernet at the top, after pseudo header “Frame” added by Wireshark

In non-promiscuous mode, you’ll capture:
* Packets destined to your network interface
* Broadcasts
* Multicasts
So, you won’t see packets sent to another MAC address on your network if you sniff with a hub or a tap

In promiscuous mode:
* All packets of non-promiscuous mode
* Packets destined to another layer 2 network interface

Typically, Debookee NA module must put the interface in promiscuous mode to see intercepted packets from other devices like an iPhone because the destination MAC address is the iPhone’s one, not our own MAC address.

With or without promiscuous mode, Ethernet packet capture works with:
* Available media: Wire / Wireless
* Connection state: Wire: cable plugged (!) / Wireless: associated to an Access Point or ad-hoc network
* Lowest protocol seen: Ethernet (IEEE 802.3)
* OSI model level: Data Link Layer (Mac)
* Packets seen: depends off the promiscuous mode
* Packets not seen: Bad FCS packets: dropped by the network interface before the capture library can be aware of them


Monitoring mode

Monitoring mode works specifically for Wi-Fi, allowing to capture packets at the 802.11 radio level, not at the Ethernet level anymore.

Wireshark capture options. Monitor mode is enabled, link-layer header is now 802.11 & a pseudo radiotap header added by Wireshark
Encrypted 802.11n data packet captured in monitoring mode on Channel 116.

In monitoring mode: 
* Available media: Wireless
* Connection state: Must be disassociated of any network, but configured with a specific channel & channel width (20 – 160MHz)
* Lowest protocol seen: IEEE 802.11
* OSI model level: Physical (PHY) Layer + Data Link Layer (Mac)

Packets seen in monitoring mode:

  • All valid 802.11 packets heard by the radio on the frequency, encrypted or not
  • All bad FCS 802.11 packets are seen, as long as the 802.11 preamble is valid
  • Packets of an adjacent channel can be heard.
    Ex: a packet sent on channel 10 can be captured by monitor mode in channel 11

Packets not seen:

  • Malformed packets at the 802.11 preamble level (due to interference, low signal or bad antenna position)
  • Packets sent on multiple streams but one or more streams can’t be decoded
  • Packets sent on multiple streams if your monitoring wireless interface has lower number of radio
    Ex: A 802.11n data packet sent on 3 streams at 450Mb/s won’t be seen if your 802.11n monitoring interface has only 2 Rx radios (very common with Windows machine or Airpcap dongles. Pro tip!)
  • Packets sent by a 802.11 protocol your interface doesn’t support
    Ex: A 802.11ac packet won’t be seen by your 802.11n monitoring interface

Enjoy packet capture!

And if you have a Mac, both promiscuous and monitoring mode can easily be tested with the free trial of Debookee.