NDIS6x NetBufferListFrameType format

Hi
In my NDIS6x protocol driver I want to set NET_BUFFER_LIST_INFO(NetBufferList, NetBufferListFrameType) for my miniport to use.

Is there any rule or suggestion that the ether_type filed should be in network byte order etc.? I do not see any and any ways for other OOBs (like Ieee8021QNetBufferListInfo) we do not do any such.

Also does any of the OS (or other) protocols or NDIS use this NetBufferListFrameType?

Thx

For your first question, see this URL:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559110(v=vs.85).aspx

Also note that this has alternate definition as NetBufferListProtocolId.

If you have a separate NDIS protocol and separate NDIS miniport I would
avoid counting on that value being passed along correctly if there were
filter modules in between the two.

Thomas F. Divine
http://www.pcausa.com


From:
Sent: Tuesday, February 14, 2012 8:59 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] NDIS6x NetBufferListFrameType format

> Hi
> In my NDIS6x protocol driver I want to set
> NET_BUFFER_LIST_INFO(NetBufferList, NetBufferListFrameType) for my
> miniport to use.
>
> Is there any rule or suggestion that the ether_type filed should be in
> network byte order etc.? I do not see any and any ways for other OOBs
> (like Ieee8021QNetBufferListInfo) we do not do any such.
>
> Also does any of the OS (or other) protocols or NDIS use this
> NetBufferListFrameType?
>
> Thx
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

The field isn’t really used for Ethernet (media type == NdisMedium802_3). NDIS and protocols know how to parse the Ethernet/SNAP header to extract the ethertype, and generally prefer that information over the NetBufferListProtocolId.

But on non-Ethernet media (e.g., WWAN or tunneling interfaces), then NetBufferListProtocolId is used.

If you’re writing a protocol driver, be very hesitant to trust the value over an Ethernet miniport, since it’s likely that some miniports don’t bother setting it. If you’re writing a miniport driver, set it to the network byte order of the ethertype (e.g., htons(0x0800) for ipv4).

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Tuesday, February 14, 2012 6:26 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS6x NetBufferListFrameType format

For your first question, see this URL:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff559110(v=vs.85).aspx

Also note that this has alternate definition as NetBufferListProtocolId.

If you have a separate NDIS protocol and separate NDIS miniport I would avoid counting on that value being passed along correctly if there were filter modules in between the two.

Thomas F. Divine
http://www.pcausa.com


From:
Sent: Tuesday, February 14, 2012 8:59 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] NDIS6x NetBufferListFrameType format

> Hi
> In my NDIS6x protocol driver I want to set
> NET_BUFFER_LIST_INFO(NetBufferList, NetBufferListFrameType) for my
> miniport to use.
>
> Is there any rule or suggestion that the ether_type filed should be in
> network byte order etc.? I do not see any and any ways for other OOBs
> (like Ieee8021QNetBufferListInfo) we do not do any such.
>
> Also does any of the OS (or other) protocols or NDIS use this
> NetBufferListFrameType?
>
> Thx
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Thanks.

I own both the protocol driver and the miniport.
My ether_type is a not the standard or OS ones (TCP/IP etc). I do not have any filter driver in between or we do not allow as well I guess/hope (Will check).

NetBufferListProtocolId range seems disjoint with NetBufferListFrameType tange, so o.k?

I am not seeing a reason why I have to set the ether_type in newtork order (I do not do that for Ieee8021QNetBufferListInfo etc) .
Also I want to know if NDIS.sys keys off of this field any way at all.
Particualrly I want to exploit this in the RX path,

My NIC got a busrt, my miniport set each NBL ether_type (my protocol subscribed to that etc)
it also set the NdisMIndicateNBLs (…SingleEtherType flags,)…
If NDIS keys off of these fields, it can just handover the chunk to my protoocl instead of giving to everybody etc (becuase I am the only protocol subscribed to it and that is the ether_type I am subscribed as well etc)

Thx.

(my above reply was before seeing Jeff’s replyy…)

Jeff

My miniport servcies some custom protocols as well. All are written by me.
I want to avoid NDisQueryMDL calls in that TX speed-path. That’s why I am trying to use NetBufferListFrameType). I will not use it for IP* etc, only for my custom protocols and LLDP as well.

O.k. will set it in network order in my protocol before calling NDISMSendNBLs().

Also please can you answer my SINGLE_ETHER_TYPE question that if NDIS anyways keys of that OOB[NetBufferListFrameType] while indicating pkts to protocols.

Also I am still a protocol over ethernet.

My suggestion is that you should never count on this info being correct.
Assume that a NDIS filter may be between your protocol and your mini port
and it injects its own nbls without setting the info.

Of course, if there is no possibility of a filter between your protocol and
mini port then this is not an issue.
On Feb 14, 2012 9:57 PM, wrote:

> (my above reply was before seeing Jeff’s replyy…)
>
> Jeff
>
> My miniport servcies some custom protocols as well. All are written by me.
> I want to avoid NDisQueryMDL calls in that TX speed-path. That’s why I am
> trying to use NetBufferListFrameType). I will not use it for IP* etc, only
> for my custom protocols and LLDP as well.
>
> O.k. will set it in network order in my protocol before calling
> NDISMSendNBLs().
>
> Also please can you answer my SINGLE_ETHER_TYPE question that if NDIS
> anyways keys of that OOB[NetBufferListFrameType] while indicating pkts to
> protocols.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

If you’re not Ethernet mediatype, then NDIS will use the NetBufferListFrameType on the RX path to match against the protocol’s FrameTypeArray. Exception: if your protocol has an empty FrameTypeArray, then *all* packets will be delivered to the protocol. (If you have multiple protocols, you may want to avoid setting all your protocols to this promiscuous mode, since the most efficient design has NDIS sort packets for you. If you have only a single protocol, it’s probably better to just put that protocol into promiscuous mode and do the sorting yourself, since you’d have to double-check NDIS’s sorting anyway.)

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas Divine
Sent: Tuesday, February 14, 2012 7:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS6x NetBufferListFrameType format

My suggestion is that you should never count on this info being correct. Assume that a NDIS filter may be between your protocol and your mini port and it injects its own nbls without setting the info.
Of course, if there is no possibility of a filter between your protocol and mini port then this is not an issue.
On Feb 14, 2012 9:57 PM, wrote:
(my above reply was before seeing Jeff’s replyy…)

Jeff

My miniport servcies some custom protocols as well. All are written by me.
I want to avoid NDisQueryMDL calls in that TX speed-path. That’s why I am trying to use NetBufferListFrameType). I will not use it for IP* etc, only for my custom protocols and LLDP as well.

O.k. will set it in network order in my protocol before calling NDISMSendNBLs().

Also please can you answer my SINGLE_ETHER_TYPE question that if NDIS anyways keys of that OOB[NetBufferListFrameType] while indicating pkts to protocols.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

O.k. I will do below (Since I own both the protocol/miniport over ethernet and also do not have/allow any filters in between. My protocol subscribes to one custom ether_type. My miniport services all protocols - IPV*, and my custom protocols (2 of them))

  1. In protocol TX path set oob[NetBufferListFrameType] = htons(ether_type)
    My miniport has to parse my custosm protocol PKts. So it can just check this OOB slot and skip NdisQueryMdl (which can fail as well under extreme conditions)

  2. Will ask my miniport to set it in network order as well during RX, since it indicates up ip* packets as well apart from my custom protocol packets (converged adapter etc)

A) Also does TCPIP.sys sets any of below in any of NDIS6x version?

I ask becuase under certain miniport NDIS versions we pkt parse for user-prirority if the ether_type is not one of my custom_protocols, i.e. then we still have to NdisQueryMdl and check for IPV*.

If I knwo all the exhaustive cases where and what OOB fields TCP/IP sets (basically I am interested in ether_type and Ieee8021QNetBufferListInfo). I can exploit those.

I observed for a NDIS63 miniport TCP/IP was setting protocolID instead.
In