Talk:Promiscuous mode

Network adapters match IP address and MAC address?

Inside each packet is a hardware (MAC) address. When a computer receives a particular packet, it checks the hardware address in it to see if the packet is addressed to it. If not, then the network card normally drops the packet. When in promiscuous mode, the network card doesn't drop the packet, thereby enabling it to read all packets.

I have understand that NIC checks packet against both given IP or MAC depending on protocol. Since MAC address cannot be used to send packets to outside of local network. So if I'm correct, this section of the article is little misleading..? 195.163.176.146 11:33, 18 April 2007 (UTC)

No, network adapters don't check against an IP address. If hosts A and B are not on the same LAN segment, and host A wants to send an IP packet (or a packet for any other routable protocol, such as IPX) to host B, and there's a third host, host C, which is a router that has a network adapter connected to the LAN segment host A is on and another network adapter connected to the LAN segment host B is on, host A will send that packet by sending the packet to host C, which will receive it and then send it to host B. When the packet is sent from host A to host C, the destination IP address is that of host B, but the destination MAC address is of host C; when the packet is sent from host C to host B, the source IP address is that of host A but the source MAC address is that of host C. Guy Harris 17:51, 18 April 2007 (UTC)

Sending?

I checked many places, but there's always just meantioned the listening part. But what about sending? Especially when using virtual machines, don't they depend on the NIC beeing able to switch the MAC for sending also? Is that not related to promiscuous mode? Is it done? How? Samorost1 (talk) 07:51, 14 June 2018 (UTC)

Presumably by "switch the MAC for sending" you mean "change the source MAC address in the packet being transmitted.

At least as I read the Intel 82575EB Gigabit Ethernet Controller Software Developer’s Manual and EEPROM Guide (section 5.1.1 "Transmit Data Flow"), the adapter does *not* set the source address in the MAC header, it's set by the host. The host doesn't have to put the adapter into a special mode in order to "fake" the source MAC address.

So this isn't even a mode on the adapter, and is thus obviously not related to promiscuous mode on the adapter (which is an adapter mode or, at least on that adapter, two separate modes, unicast and multicast promiscuous mode - see section 5.3.1 "Packet Address Filtering").

At least with the Berkeley Packet Filter (BPF) mechanism for capturing and injecting packets, there's a BIOCSHDRCMPLT ioctl that causes the BPF software on the host to, for that BPF "device", not set the source MAC address in the header of transmitted packets to the source address of the adapter on which the packet is being transmitted. That's what needs to be turned on in order to change the MAC for sending.

I don't know offhand whether other OS's mechanisms for sending raw link-layer packets ever overwrite the source MAC address with the adapter's MAC address or, if they do, what's necessary to disable that host software function. Guy Harris (talk) 17:36, 14 June 2018 (UTC)

Modern Application?

Modern virtualization NICs filter IP and/or MAC address depending on the installed virtual machines and applications. When would the term "promiscuous mode" apply to such a NIC? In backwards-compatibility situations only?

For example, suppose a NIC is implementing a node-assisted IP multicast. The MAC address is useless in that application. Does that make it promiscuous? — Preceding unsigned comment added by 108.18.250.35 (talk • contribs) 17:56, 15 August 2012 (UTC)

NIC Passes Traffic to NIC Driver Rather than CPU

In the opening paragraph (my emphasis added):

In computer networking, promiscuous mode or promisc mode is a mode for a wired network interface controller (NIC) or wireless network interface controller (WNIC) that causes the controller to pass all traffic it receives to the central processing unit (CPU) rather than passing only the frames that the controller is intended to receive.

I believe this would be more accurate if it described passing traffic to the driver, network stack or sniffing application rather than to the CPU. The CPU does do the processing, but the traffic is passed from the NIC to the driver to the network protocol stack or sniffer. Dave Braunschweig (talk) 15:44, 6 November 2012 (UTC)

Both are accurate. From the hardware point of view, the NIC transfers the packet data to a buffer in the CPU's memory (well, there might be other architectures, but that's the typical one) and may deliver to the CPU a "packet has arrived" or "packets have arrived" indication (e.g., a per-packet interrupt, or a per-group-of-packets interrupt, if the CPU isn't just doing time-based polling to batch packets up). From the software point of view, a driver is signaled as a result of the indication or polling and starts processing the packet, passing it on to other software to further process. Guy Harris (talk) 18:29, 6 November 2012 (UTC)

Use of word CPU seems misleading

The use of word CPU would be more accurate when the processor in question is specifically programmed for the purpose or is a special purpose processor. Normally the processors in such switches are general purpose processors and the processing unit is fabricated for switching purposes alone. The use of word CPU puts me to think as if processor processes the packets and NOT the software instructions that are run by processor.

Things become worse when someone follows the link attached to CPU (central processing unit) because the link talks about general purpose processors which is completely off-topic. — Preceding unsigned comment added by Ripunjaytripathi (talk • contribs) 14:09, 29 November 2012 (UTC)

No. "CPU" is a term that's been used for general-purpose processors for ages, and, in fact, that's exactly what we're talking about - a system with a processor usually running a general-purpose operating system (whether a personal computer or an "embedded" system with a general-purpose OS) and with a network adapter, wherein the software running on the CPU puts the network adapter into promiscuous mode so that unicast packets not sent to the adapter's MAC address will be received by the adapter and delivered to the CPU. We're not talking about network processors in switches - switches are only relevant in this article because promiscuous mode doesn't, by default, help on a switched network, so you need a "mirror port" or whatever the switch vendor calls it, but that's different from promiscuous mode. Guy Harris (talk) 20:01, 29 November 2012 (UTC)

List of Network Adapters that have "Promiscuous Mode" Capability?

Am I correct in my belief that some have "promiscuous mode" and some do not? If so, I think it would be helpful to include a list of those network adapters that have this ability, or at least provide a means for people to determine it for themselves. I assume it's a technical specification that may not explicitly say "promiscuous mode capable".Jonny Quick (talk) 01:46, 23 July 2014 (UTC)

Just about every Ethernet adapter on the planet supports promiscuous mode. (Note that promiscuous mode is not sufficient on a switched network; see the Wireshark Wiki page on Ethernet capturing for the painful details.) I don't know about Token Ring or FDDI.

I'm not sure whether any Wi-Fi adapters usefully support promiscuous mode; you usually need monitor mode on Wi-Fi networks.

Adapters for point-to-point network segments obviously don't support promiscuous mode, as there are only two hosts on the network segment. ATM networks are switched; I don't know whether any ATM switches supported or supported "port mirroring" along the lines of what some Ethernet switches support and, if so, I don't know whether any ATM adapters could run in "VPI/VCI promiscuous" mode. Guy Harris (talk) 02:00, 23 July 2014 (UTC)

Broadcast domain vs collision domain

A non-routing node in promiscuous mode can generally only monitor traffic to and from other nodes within the same broadcast domain (for Ethernet and IEEE 802.11)

Should this say “collision domain”? The rest of the paragraph mentions using switches to limit malicious use of promiscuous mode, but a switch only limits the collision domain not broadcast domain as I understand things. Neil.E.Madden (talk) 20:31, 19 October 2019 (UTC)

A non-routing node in promiscuous mode can generally only monitor traffic that actually appears on the input wires/fibers/antenna for the adapter on which it's capturing traffic.

For non-switched Ethernet, that means "traffic from any host attached to the same wire, as well as hosts on other wires that are bridged in a way that forwards every packet" (i.e. no selective bridging).

For switched Ethernet, that normally means "traffic on the port into which I'm plugged" - but some switches support configuring a port as a "span port" or "mirror port" or whatever the vendor calls it, in which case all traffic through the switch is sent out on that port (or discarded, as you're not going to shove 40 GB of traffic from 4 ports onto a single 10 GB port).

For Token Ring, I'm guessing from the description at Token ring#Access control that it means "any host on the ring", as packets don't disappear from the ring once the receiver gets them, they just copy the packet and change the token to 0.

For 802.11, it means "traffic on the channel on which I'm listening", possibly with additional PHY-dependent requirements. (That doesn't mean the node can decrypt the packets, but that's another matter.)

So the answer is "it's complicated". I'm not sure how to phrase it. Guy Harris (talk) 20:50, 19 October 2019 (UTC)

If you look at the full context here (2nd sentence of 3rd paragraph in lead) it is clear that changing from broadcast domain to collision domain is a clear improvement. I have made the change. As Guy points out there are some wrinkles here and possible room for improvement but we should resist the urge to be super pedantic in the lead. ~Kvng (talk) 14:49, 22 October 2019 (UTC)

I’m not sure if this change got lost in the intervening years, but it was still reading as broadcast domain, so I have changed it to collision domain again. Neil.E.Madden (talk) 10:48, 9 April 2024 (UTC)