Determining the presence of wireshark
in [Linux Networking]
|
Prev: how to inform pppd Session-Timeout value using radius
Next: Network traffic monitor - tip from expert
From: Rick Jones on 9 Mar 2010 16:35 In comp.os.linux.networking Lew Pitcher <lpitcher(a)teksavvy.com> wrote: > Note that this will present false positives if the NICs in question > are running with "user set" MAC addresses. > With "user set" MAC addresses, the NIC cannot use it's builtin > comparison logic to find frames addressed to the NIC. The OS NIC > driver logic has to match the MAC address on /all/ "on the wire" > packets to the "user set" MAC address, and extract those that > match. This requires that the NIC run in promiscuous mode, to permit > the driver access to all the network traffic. Are there really NICs still common today which cannot put the user-override MAC address into its filter table(s)? rick jones -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: David Schwartz on 9 Mar 2010 17:04 On Mar 9, 1:35 pm, Rick Jones <rick.jon...(a)hp.com> wrote: > Are there really NICs still common today which cannot put the > user-override MAC address into its filter table(s)? No, but I think there are still some somewhat common NICs that will go into promiscuous mode in many not-atypical multicasting scenarios. DS
From: Pascal Hambourg on 10 Mar 2010 06:46 Hello, DanS a �crit : > > I'm sure it's OS specific. For instance, a Windows box will not reply to a > broadcast ping, but a Linux box will. Linux reply to a broadcast ping has been disabled by default since version 2.6.14 (sysctl net.ipv4.icmp_echo_ignore_broadcasts=1 by default).
From: Pascal Hambourg on 10 Mar 2010 06:52 Lew Pitcher a �crit : > On March 9, 2010 12:40, in comp.os.linux.networking, jeffl(a)cruzio.com wrote: > >> Look for NIC cards and wireless devices running in promiscuous mode. > > Note that this will present false positives if the NICs in question are > running with "user set" MAC addresses. > > With "user set" MAC addresses, the NIC cannot use it's builtin comparison > logic to find frames addressed to the NIC. The OS NIC driver logic has to > match the MAC address on /all/ "on the wire" packets to the "user set" MAC > address, and extract those that match. This requires that the NIC run in > promiscuous mode, to permit the driver access to all the network traffic. IIUC what you wrote, the hardware controller operates in promiscuous mode but the software driver filters incoming frames and passes only those with the user set MAC address to the upper layer (ARP, IP). So the interface as a whole (hardware controller + software driver) still operates in normal (non-promiscuous) mode, doesn't it ?
From: David Schwartz on 10 Mar 2010 09:06
On Mar 10, 3:52 am, Pascal Hambourg <boite-a-s...(a)plouf.fr.eu.org> wrote: > IIUC what you wrote, the hardware controller operates in promiscuous > mode but the software driver filters incoming frames and passes only > those with the user set MAC address to the upper layer (ARP, IP). So the > interface as a whole (hardware controller + software driver) still > operates in normal (non-promiscuous) mode, doesn't it ? It will depend on the implementation of the driver. But with the most natural implementation, the net effect will be the same as if the interface wasn't in promiscuous mode -- packets the interface shouldn't have received will be dropped at a very low level. You almost have to do this because minimizing the cost of such packets would be a top priority. However, you could imagine a stack that had a few checks prior to the MAC check. If you get a packet to slip through one of those checks and get responded to, you might be able to detect this case. It's obviously going to have to check for multicast/broadcast first. If that's not precisely the same check the hardware would use, you might squeeze something through. DS |