WHQL NDIS 2c_CheckConnections.wsf says that our card fails to receive packets but...

Discussion in 'Windows Vista Drivers' started by RonM, Oct 6, 2004.

  1. RonM

    RonM Guest

    We set a breakpoint and watch our driver call NdisMIndicateReceivePacket()
    We set a breakpoint and watch the OID_GEN_RCV_OK get called and
    we give it an ever increasing count of received packets. (do we ever reset this count?)
    But calling NdisMIndicateReceivePacket() and answering the OID seems to
    not be enough. The test says that when our wireless card is on the test server (support)
    that WHQL sees 100 packet transmitted from the UUT but no packets received
    at the server. But we can FTP browse the web, ping etc.
    What criteria is WHQL using to determine if packets and received on the server or not?
    RonM, Oct 6, 2004
    1. Advertisements

  2. Ron,

    You may want to send this question to .

    Bryan S. Burgin

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Bryan S. Burgin [MSFT], Oct 7, 2004
    1. Advertisements

  3. The 2c_CheckConnections test sends packets which contain an EtherLength in
    the 802.3 MAC header (instead of EtherType like 0x800, etc). The packet
    itself contains a snap header. If the snap header is not correctly preserved
    in the packet indicated by the receiving driver, NDISTest will reject the
    packet and you will see the no packets were received error. Does your driver
    do anything with regards to adding/removing snap headers?

    Also, do you set the correct length in packets you indicate to ndis (eg.
    using NdisAdjustBufferLength)?

    Mitesh Desai [MSFT], Oct 7, 2004
  4. RonM

    RonM Guest

    Interesting. We add SNAP headers on transmit and remove them on receive.
    We figured that if the protocol above us didn't send them on transmit it
    probably didn't want them on receive. Is there any documentation on
    SNAP headers?


    RonM, Oct 7, 2004
  5. I am not sure about documentation. But to ensure that various protocols
    (IPX, Appletalk, etc) work over your driver, you want to check the transmit
    packet for presence of snap header (eg. MAC header has EtherLength instead
    of EtherType, or ethertype is a protocol that adds a SNAP) and not add snap
    on sender and not remove it on receiver.

    Mitesh Desai [MSFT], Oct 7, 2004
  6. RonM

    RonM Guest

    Thanks for the info.
    OK let me stick my foot in it. In order to know when to add a SNAP header
    look at the type field. If it is 0x0800 then add the SNAP header else no.
    On the receive side again look at the type field and remove the SNAP
    header ONLY if the type field is 0c0800.
    Yes? Or are there other constraints?

    RonM, Oct 7, 2004
  7. That would not work for ARP, IPv6, etc which use a different EtherType.

    The correct thing to do is: If the packet for transmit from NDIS has an
    EtherType inside of it, you should add a snap header in the packet. If
    instead of EtherType, there is an EtherLength (value <= 1500) then this
    packet should already contain the snap header. You have to do nothing for
    this case. This way all 802.11 packets in the air have a snap header in
    them. On the receive side, using ether type inside SNAP header determine if
    the snap header should be stripped out or not. Plus, you need to treat IPX
    ethertype special since it can already contain SNAP header.

    Mitesh Desai [MSFT], Oct 8, 2004
  8. RonM

    RonM Guest

    Thank you for the detailed info. I believe that I understand.
    How can I test IPX packets to see if I handle them correctly.
    Are they only used for Novell? Or is there another way I can
    stimulate the use of IPX packets?


    RonM, Oct 8, 2004
  9. RonM

    Stephan Wolf Guest

    Sorry if I jump in here and add some information.

    The 16-bit field (hi-lo "big endian" format) that follows the
    destination/source address pair (DA/SA, 2x6 bytes) can be either the
    *length* of the data that follows or the protocol *type*. (MAC header
    = DA, SA, type/length = 6+6+2 = 14 bytes).

    [This is so, because the latter was introduced by DEC/Intel/Xerox
    "DIX", also known as "Ethernet II" or "Blue Book Ethernet", whereas
    the first was specified by IEEE 802.3 - note that -due to the power of
    the factual- the type field is today also specified by IEEE 802.3.]

    Since the maximum payload (data) length of a standard Ethernet frame
    is 1500 bytes, valid Ethernet length fields values are in the range
    0..1500 (0x05DC). All other values are therefore protocol type codes
    by definition (i.e., 0x05DE..0xFFFF).

    The structure or meaning of the "data" portion in a "typed" Ethernet
    frame is not specified by any Ethernet standard. The protocol
    standards define the outline of the "data" (e.g. the data for type
    0x0800 is made up of an IP header followed by other protocol headers
    (ICMP/UDP/TCP), see the respective RFCs for details).

    For non-typed Ethernet frames, i.e. frames that have a valid "length"
    field, there *must* be a 802.2 LLC (link layer control), which
    consists of 3 bytes:
    Destination Service Access Point (DSAP), Source SAP (SSAP), and
    Control (CTL).

    [One exception is DSAP=SSAP=0xff (no CTL byte!), which is "reserved"
    by Novell NetWare's ETHERNET_RAW frame type.]

    If (and only if) the DSAP/SSAP/CTL is AA-AA-03 (CTL=03 = "unnumbered
    information"), then a 5-byte SNAP header follows, which is:
    Organizational Unique Identifier (OUI[3]), Type[2].

    If the OUI is 00-00-00, then the "Type" is a standard Ethernet
    protocol type code. Note that each "organization" can use its own
    proprietary interpretation here, if the OUI is set to that of the
    organization (see the official list at
    http://standards.ieee.org/regauth/oui/oui.txt). [Note that the same
    OUI is also used in the first three bytes of the MAC address.]

    Note that there is often confusion if the SNAP header includes the LLC
    header or not. In any event, all you need to know is that LLC is 3
    bytes and LLC+SNAP is 8 bytes (3+5).

    This way, SNAP allows for the use of standard Ethernet frame data
    (i.e. whole Ethernet frame except the 14-byte MAC header) on any

    Having said this, it should be clear that Ethernet frames with a
    length field *can* but do *not necessarily* contain a SNAP header. For
    instance, Novell NetWare ETHERNET_802.2 frames do *not* have a SNAP
    header (but only an LLC header with IIRC DSAP/SSAP/CTL=E0-E0-03).

    HTH, Stephan
    Stephan Wolf, Oct 11, 2004
  10. RonM

    RonM Guest

    Wow! Thank you for jumping in. That saved me a lot of headaches
    that would have happened when our wireless card started sampling.
    As for now I have to revisit our LLC-SNAP scheme to stop
    messing up the WHQL 2c_xxx tests.


    RonM, Oct 11, 2004
  11. I dont know of any tools to simulate IPX packets. You can use ndisprot (NDIS
    protocol driver sample in the DDK) to simulate IPX packets of various
    encapsulations and using Netmon on receiver side verify that correct data
    was indicated.

    (please read Stephan Wolf's detailed mail on all the checks you will have to
    perform on the packet to send)

    Mitesh Desai [MSFT], Oct 11, 2004
  12. RonM

    Ashirwad Guest


    Thanks to all. I had created a thread "Ping works but
    2c_CheckConnections fail on wireless lan setup" which was answered. I
    have got my 2c_CheckConnections working now.

    Ashirwad, Oct 28, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.