You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While speaking with network professionals about Debookee Wi-Fi Monitoring (WM) module, I’ve discovered that promiscuous mode is commonly confused with monitoring mode, although they operate on different media, layers & protocols.
Promiscuous mode is not a packet capture mode, it’s an option of Ethernet packet capture.
Using Wireshark, the capture interface options show 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
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 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
And if you have a Mac, both promiscuous and monitoring mode can easily be tested with the free trial of Debookee.
The text was updated successfully, but these errors were encountered: