locked
WireShark shows packets, Netmon 3.4 does not, Win7 x64 with Intel 82566DC adapter RRS feed

  • Question

  • I've been trying to comprehend the behavior of a failing print server on my home network. To this end, I added an ethernet switch (GS105E) with port mirroring between the home router and the offending print server, and connected one of the network interfaces on my PC to the mirroring output port.

    The first tool I attempted to use was NetMon 3.4, but quickly some traffic between the home router and printserver was not showing up. Broadcast traffic from either party was visible but little else. The adapter was selected in the Netmon capture settings and P-Mode was selected (pressed after the interface was selected to enable promiscuous mode). This produced no change.

    I downloaded the current version of Wireshark 1.4.2 and it worked immediately. All traffic was visible. Furthermore, I was able to de-select all providers associated with the interface in the Local Area Connection properties associated with the interface (including  Client for Microsoft Networks, IPv4, etc...) and the interface works beautifully as a completely passive observer of traffic.

    With Netmon, the network interface appears to need IPv4/IPv6 enabled to even receive traffic at all.

    I've repeated the experiments with Wireshare and Winpcap uninstalled and this makes no difference. The thinking being if both were installed then the winpcap filter might be discarding the packets before the netmon filter saw them.

    I've tried changing the order of selecting the network interface in Netmon and pressing the p-mode button to no avail.

    This seems like a simple enough scenario and I'm wondering why Wireshark is able to capture the packets promiscuously and Netmon 3.4 does not appear to be able to?

    [In case the question arises, the backing store disk for the capture is ~60% full. ]

    Saturday, January 8, 2011 2:14 PM

Answers

  • Okay, found the issue. It appears to be caused by having the VirtualBox network adapter installed. Uninstalling VirtualBox fixed the problem. Presumably this is something to do with the positioning in the driver stack of where the VirtualBox network driver sits, where the Netmon filter goes, and whether the WinPcap goes (?).
    • Marked as answer by Paul E Long Tuesday, July 16, 2013 4:06 PM
    Saturday, January 8, 2011 2:17 PM

All replies

  • Okay, found the issue. It appears to be caused by having the VirtualBox network adapter installed. Uninstalling VirtualBox fixed the problem. Presumably this is something to do with the positioning in the driver stack of where the VirtualBox network driver sits, where the Netmon filter goes, and whether the WinPcap goes (?).
    • Marked as answer by Paul E Long Tuesday, July 16, 2013 4:06 PM
    Saturday, January 8, 2011 2:17 PM
  • Network Monitor usually should sit at the bottom of the stack; however, in 3.4 you can change this behavior.  From the Capture Options help topic:


    Driver Capture Location: You can configure the driver capture location for all adapters (system wide) by changing the registry value \HKLM\System\CurrentControlSet\Services\nm3\LoadUpperLayers. A non-zero DWORD value for the key indicates the driver will capture first, above other NDIS Lightweight Filter (LWF) drivers. If the key does not exist or a zero DWORD value is set for the key, Network Monitor will capture below all other NDIS LWF drivers before the network traffic is sent to the wire. This is the default behavior.

    When you use the alternate Driver Capture Location in combination with WiFi adapters, they will not capture Wireless Metadata and Monitor Mode for those adapters is disabled.


    Not sure why VirtualBox was getting in the way, but not too familiar with that software.  Glad you were able to solve the issue, thanks for posting your find here.


    Michael Hawker | Program Manager | Network Monitor
    Monday, January 10, 2011 7:12 PM
  • The Netmon Driver is an nonmodifying NDIS Lightweigh Filter Driver.  This means it inserts itself in the NDIS stack and NDIS sends a copy (or maybe a reference) to each frame that it receives.  This means Network Monitor can capture any traffic from any NDIS level network driver, which is the standard way network interface drivers are written.

    WinPCap, which is the driver wireshark uses, installs as a protocol driver.  Assuming it's inserted first in the stack, then it can see any traffic even for non-NDIS interface drivers.  My guess is that the VirtualBox driver is not an NDIS driver, and that is why Network Monitor cannot see this traffic.

    Paul

    Wednesday, January 12, 2011 4:54 PM
  • I am implementing an "NDIS Lightweigh Filter Driver" and I would like to know how to choose where to insert it in the driver stack and how to do that. I started from the sample in the driver kit.

    J.P Samson

    Friday, June 21, 2013 1:58 PM