Is it possible to push all packets received at NIC to the TCP/IP stack even if their ethernet address doesn't match my ethernet address? In other words I want to process all incoming packets at my NIC. Can anyone mention a possible scenario for changing network interface driver code?how could I check the operation of driver code?
-
1I'm sure such promiscuous listening is possible, but you may need a special driver and a NIC that supports it. Such a mode would probably be 'exclusive use only' for one process/thread and would also probably disallow transmission. – Martin James Dec 02 '13 at 13:41
-
I know it is possible by setting IFF-PROMISCUOUS flag but in this mode driver doesn't send packets to the TCP/IP stack! Is it possible to change drive code? – MSH Dec 02 '13 at 17:29
-
1They may not be TCP/IP segments - the NIC does not know, it only knows MAC addresses. Even if they were, it is not sane to supply data buffers to a TCP stack that has had no part in initiating or managing the connections. – Martin James Dec 02 '13 at 20:43
-
Am unsure exactly how to, but my .2: Perhaps using a raw socket would help? And/or check if tcpdump can do so? – kaiwan Dec 03 '13 at 02:26
-
@kaiwan. By using tcpdump or raw socket, the packets are sending to user layer directly but I want to send them to TCP/IP stack. – MSH Dec 03 '13 at 17:31
-
It could be possible to push them to the IP layer, but TCP? Forget it! How would you `accept()` an already existing connection? What socket would you use? – Guido Dec 03 '13 at 17:39
-
@Guido. I don't understand your words,please explain more. – MSH Dec 04 '13 at 06:10
-
@Martin James. tcpdump sets this mode for device driver but even in this mode we can send request to the server and get response from it so packets should be sent to TCP/IP stack and response packets be gotten from it. – MSH Dec 04 '13 at 13:42
1 Answers
In the typical system, this already happens. That is, all you have to do is put the interface into promiscuous mode. The driver then sends all packets it receives to the TCP/IP stack. Check any ordinary network driver, you'll see that in processing received packets, there is no comparison of the MAC (or ethernet) address with the device's MAC address.
Simplifying considerably:
What normally happens is that when you don't have promiscuous mode enabled, the driver configures the device such that it filters on a specific MAC address, only delivering frames that have a matching address or a broadcast address (or occasionally a multicast address, which may or may not also be filtered). When you enable promiscuous mode, the driver simply tells the device not to filter on MAC address but to deliver all frames. The driver then will receive all frames and deliver them to the stack. In linux, this typically happens through a call to netif_receive_skb() or a variant thereof.
The TCP/IP stack itself doesn't care about the MAC address. It will instead look for packets that have an IP address matching one of its own. Any packets received that don't have an IP address belonging to this box are simply discarded -- unless there's a user-mode program trying to receive raw packets (such as tcpdump). [In the latter case, it's still discarded after being delivered to tcpdump.]
If it matches on the IP address, it's then passed up the stack to TCP or UDP [etc] -- where it could also be discarded if it doesn't correspond to a session / port that anything on the box cares about.
But typically packets destined for a MAC address not matching one assigned to this device will not be packets that this machine cares about. Hence, promiscuous mode is usually only enabled for debugging, troubleshooting, forensics (i.e. tcpdump, wireshark, etc). The rest of the time, it's a waste of processing resources since the packets will just be discarded.

- 11,973
- 28
- 51