NDIS, Windows 7 and Network Monitor 3.3 RRS feed

  • Question

  • It seems that when I'm using a NDIS device (Sierra 309 in this case) under Windows 7, NmApi's function NmGetRawFrame() somehow misses the Ethernet header of the packets. The packet data starts directly with IP header. This does not occur with Windows XP. Is this a known bug or have you got any idea why this happens?

    • Edited by Coriende Friday, February 26, 2010 8:03 AM
    Monday, February 22, 2010 7:32 AM

All replies

  • Which interface are you capturing on?  (NMCap /DisplayNetworks will enumerate them for you)?

    Do you see something different when you capture on that same interface in the UI?



    Monday, February 22, 2010 6:28 PM
  • The interface is shown as "Mobile Broadband Connection (Sierra Wireless HSPA Network Adapter".
    There are no problems when capturing the interface with Network Monitor UI.

    Also, when I try to get the ethernetType of each packet through API it always returns 0.
    Tuesday, February 23, 2010 7:39 AM
  • So when you capture from the UI, you see an ethernet header, but when you capture from the API, you don't?

    If you look at the raw bytes in the API, does the ethernet header show up there?

    It possible that there are two different adatpers which show different data depending where you capture the data.  Are you capturing on the same adapter index? 


    Tuesday, February 23, 2010 5:41 PM
  • Correct.

    The raw bytes does not show the ethernet header.

    There is only one adapter visible for this device (Mobile Broadband Connection) with correct Description.

    I have tried to capture all adapters through API and then filter the data by TCP IP addresses. The filter works but Ethernet header is still missing.
    Wednesday, February 24, 2010 7:15 AM
  • We were able to test with this adapter and noticed that even in the UI, you don't get an ethernet header.  In that case the media type shows up as Wireless WAN or 0xF3.

    What media type shows up in the Frame details (can you copy and paste an example)?

    What is the output of nmcap /displaynetworks?

    Thursday, February 25, 2010 7:05 PM
  • It seems that this error happens only with this Sierra adapter. At least the others I have tried capture all frames perfectly.

    Frame details are (media type is ETHERNET, but the hex clearly shows it's actually an IP header):

      Frame: Number = 73, Captured Frame Length = 52, MediaType = ETHERNET
    - Ethernet: Etype = 0x54ea,DestinationAddress:[45-00-00-34-00-00],SourceAddress:[40-00-3C-06-92-10]
      - DestinationAddress: 450000 340000 [45-00-00-34-00-00]
         IG:  (0.......) Individual address
         UL:  (.1......) Locally Administered Address
         Rsv: (..000101)
      - SourceAddress: 40003C 069210 [40-00-3C-06-92-10]
         UL: .0...... Locally Administered Address
        EthernetType: 0x54ea, 21738(0x54ea)
    - remainder: Length = 38
        Data: Binary Large Object (38 Bytes)

    45 00 00 34 00 00 40 00 3C 06 92 10 54 EA 45 8C
    55 4D BC F0 E6 EA CF 15 DB 43 4A E6 BF A8 3B 9F
    80 12 16 D0 D4 0F 00 00 02 04 05 B4 01 01 04 02
    01 03 03 02

    NmCap output:
    Netmon Command Line Capture (nmcap) 3.3.1641.0
    0. isatap.{B38863E5-3A79-4B85-A3F9-22C25FDF7D89} (Microsoft ISATAP Adapter #4)
    1. isatap.{E4CF00BF-E079-4EC9-B2AB-1E85CA4DB95B} (Microsoft ISATAP Adapter #3)
    2. isatap.{F31579F0-656E-437F-BFFC-28061C1CBEFF} (Microsoft ISATAP Adapter #2)
    3. isatap.[deleted].com (Microsoft ISATAP Adapter)
    4. Local Area Connection (Broadcom NetXtreme 57xx Gigabit Controller)
    5. Mobile Broadband Connection (Sierra Wireless HSPA Network Adapter)
    6. NDISWANBH (WAN Miniport)
    7. Reusable Microsoft 6To4 Adapter (Microsoft 6to4 Adapter)
    8. Teredo Tunneling Pseudo-Interface (Teredo Tunneling Pseudo-Interface)
    9. Wireless Network Connection (Intel(R) PRO/Wireless 3945ABG Network Connection)
    Friday, February 26, 2010 7:58 AM
  • What is the date and driver version of teh Sierra adpater?  Perhaps we have a different verison that is properly setting the MediaType.

    Monday, March 1, 2010 5:27 PM
  • NDIS driver R6.20.0.9
    USB MUX R2.2.14.0

    Device's hardware revision is 1.0 with M2_0_11_10AP firmware.
    There seems to be no updates available.
    Tuesday, March 2, 2010 8:22 AM
  • It turns out we are using an older driver version, but we still confused as how you can see different data from the UI vs. the API.  I think we need to clarify some of your steps.  Perhaps you can answer the following questions.

    If you do a capture using NMCap using this command line, can you tell me the media type of the network data frames in the resulting capture?

    nmcap /network 5 /capture /file test.cap

    Can you also provide me the code snipit you are using get the frame data using NmGetRawFrame?

    When you collect the trace using the NMAPI, can you also write the frames to a file using NmAddFrame.  And then open that capture file and tell me what the media type is?



    Tuesday, March 2, 2010 11:05 PM
  • Those command line parameters did not work for some reason. The adapter should be correct but still it's only capturing LAN traffic and not the adapter's. Instead I captured all adapters with an IP filter. That capture file opened normally through the UI, but Wireshark did not understand it and showed the packets without Ethernet headers.

    Code for the raw frame (which works with XP with Sierra 309 and returns the Ethernet header correctly at the beginning of the buffer):

    ULONG rawFrameLength = 0;
    ULONG actFrameLength = 0;
    ret = NmGetRawFrameLength(hRawFrame, &rawFrameLength);
    unsigned char *pRawFrameBuf = new unsigned char[rawFrameLength];
    ret = NmGetRawFrame(hRawFrame, rawFrameLength, pRawFrameBuf, &actFrameLength);

    Writing frames using NmAddFrame() does not work because closing the temporary capture file handle always crashes (this is a known bug from previous threads someone already addressed). If the handle is not closed correctly, the file cannot be opened because "no packets are found", even if there are some.
    Wednesday, March 3, 2010 1:59 PM
  • Did you get an error running NMCap with the command line I provided?  If not, what was the media type of the resulting trace?

    XP uses a different driver, so the header will be different.  So that might explain the difference you see with XP.

    Using NmAddFrame in the callback should work.  Once you close the file handle and exit the program you should be abel to open the resulting trace.  The other bug mentioned (that I can find), is talking about the ability to access and move the file before the program exits.  If you are seeing another behavior let me know.

    When you call NmGetRawFrame, how are you then saving the frames to verify the media type?  Can you provide that code?  If you are somehow writing the frames, you have to maintain the mediatype for that frame in order for it to be parsed correectly later.  So you'll have to call NmGetFrameMacType, and then provide that type if you are calling NmBuildRawFrameFromBuffer.

    Wednesday, March 3, 2010 5:02 PM
  • Hi Guys,

    Win 7 mobile broadband uses RAW IP for communication. This is the reason why you do not see Eth header there. Windows XP does not follow Moblie Broadband Driver Model. This is newly introduced in Windows 7 only. :)

    Please go through


    This white paper will explain

    INF File Changes

    RAW IP Frame Processing

    Effect of Changes on Applications

    Testing Applications for Compatibility

    Vishal Jain, MSFT
    • Proposed as answer by Vishal_Jain Saturday, March 6, 2010 6:26 PM
    Saturday, March 6, 2010 6:26 PM
  • Was going through white paper and found most relevent for you :

    "Windows 7 defines a new media type: NdisMediumWirelessWan. For this media type, NDIS sends raw IP frames directly to the miniport driver and expects the miniport driver to return raw IP frames. Raw IP frames are the same as Ethernet 802.3 frames except that the raw IP frame omits the Ethernet header and starts with the IP header."

    Vishal Jain, MSFT
    • Proposed as answer by Vishal_Jain Saturday, March 6, 2010 7:51 PM
    Saturday, March 6, 2010 7:51 PM
  • Thank you! This explains it.
    Monday, March 8, 2010 7:35 AM
  • I did not get any error when running NMCap, still it didn't not capture the traffic from the adapter I selected.

    For some reason I cannot open the .cap file after programs exits. The handle is closed normally and the file has data inside, but it still says the file does not contain any packets. I will investigate this more.

    So, if I'm saving the frames 'manually' by using the buffer from raw frame, there is no way to include the Ethernet header to the packet? And this should work with NmAddFrame?
    Monday, March 8, 2010 8:05 AM
  • The ethernet header does not exist because the Wireless wan adapter doesn't use it and instead uses the NdisMeiduimWirelessWan header instead.

    Assuming the media type returned is correct, and in our tests it is, it should be fine.  When the capture is loaded in Netmon, it will detect the media type=7 and parse it correctly.  Keep in mind that Wireshark might now be able to parse because I don't believe they've updated to handle the file format changes we did inorder to support multihomed capturing. 


    Tuesday, March 9, 2010 7:47 PM
  • Queried the wireshark guys and they said they would need documentation on the new file format before they knew where to start - so took a look around technet, but found nothing useful. Is this documentation available, so I can point the wireshark guys at it?
    Monday, July 19, 2010 1:10 PM
  • Our file format along with our reassembly and wireless headers are documented in our CHM help file which is installed alongside Network Monitor.  The 3.4 RTW install has the most recently and up-to-date definitions.

    They're in the Network Monitor Overview->Capture File Format section.  If they have any questions about what's in here, please feel free to point them to this forum for answers or to contact us directly, we're always happy to help.

    Michael Hawker | Program Manager | Network Monitor
    Monday, July 19, 2010 6:59 PM