ProtocolDriver Receive Callbacks (ProtocolReceive vs ProtocolReceivePacket)

NTDEV
1

All

I have a protocol driver whose protocol type is not IP (also the ethertype will not be 802.3). The miniport indicates multiple packets and hence full packets (I have verbally conformed this from my miniport team - that they indicate multiple packets whenever possible and hence full pkts). But in my protocol driver the callback is ProtocolReceive instead of ProtocolReceivePacket.

  1. Is that because our protocol type is not IP and ether is not 802.3 (Maybe Ndis.sys is interjecting and only providing look-ahead data to all bound protocols to optimize the order in which it hands over the pkts to bound protocols in future. !!!. But always we get partial pkts i.e. ProtocolReceive never full packets i.e. ProtocolReceivePacket).

  2. If it is because of any of the reasons above, can miniport change the protocol/ethertypes to IP/802.3 temporarily and force ndis to handover full pkts ( but also only to my protocol driver (if that is feasible and makes sense)).

  3. Also why doesn’t we have a NDIS function for protocol drivers to receive full packets i.e. ProtocolReceivePacketS() or ProtocolReceivePacket(…, ndis_paket, count) etc. when the miniport indicates array of packets. Why do protocol drivers sill get called back only for single packet (at least looking at the protocol driver RX callback signatures)

Basically I want to know how I can make NDIS.sys to handover full pkts in to my protocol driver (at this time assuming my miniport is indicating pkt lists and hence full pkts).

Please let me know of any info that can guide towards answers to above.

thanks.

2

One of the reasons why you receive packet indications with the
ProtocolReceive handler only is that there are intermediate drivers in the
stack. Please remember that in general the network stack is (from top to
bottom)

  • protocol driver
  • zero or more IM drivers
  • miniport driver

(This is a simplification that doesn’t account for MUX IM drivers that
complicate things a lot).

An IM driver is free to notify packets up in the “old” fashion.

As far as I know there is no way for a NDIS 5.x protocol driver to force the
underlying miniport to indicate full packets (that’s usually the biggest
pain when developing a protocol driver).

Hope it helps
GV

–
Gianluca Varenni, Windows DDK MVP

CACE Technologies
http://www.cacetech.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 01, 2007 4:30 PM
Subject: [ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

> All
>
> I have a protocol driver whose protocol type is not IP (also the ethertype
> will not be 802.3). The miniport indicates multiple packets and hence full
> packets (I have verbally conformed this from my miniport team - that they
> indicate multiple packets whenever possible and hence full pkts). But in
> my protocol driver the callback is ProtocolReceive instead of
> ProtocolReceivePacket.
>
> 1) Is that because our protocol type is not IP and ether is not 802.3
> (Maybe Ndis.sys is interjecting and only providing look-ahead data to all
> bound protocols to optimize the order in which it hands over the pkts to
> bound protocols in future. !!!. But always we get partial pkts i.e.
> ProtocolReceive never full packets i.e. ProtocolReceivePacket).
>
> 2) If it is because of any of the reasons above, can miniport change the
> protocol/ethertypes to IP/802.3 temporarily and force ndis to handover
> full pkts ( but also only to my protocol driver (if that is feasible and
> makes sense)).
>
> 3) Also why doesn’t we have a NDIS function for protocol drivers to
> receive full packets i.e. ProtocolReceivePacketS() or
> ProtocolReceivePacket(…, ndis_paket, count) etc. when the miniport
> indicates array of packets. Why do protocol drivers sill get called back
> only for single packet (at least looking at the protocol driver RX
> callback signatures)
>
> Basically I want to know how I can make NDIS.sys to handover full pkts in
> to my protocol driver (at this time assuming my miniport is indicating pkt
> lists and hence full pkts).
>
> Please let me know of any info that can guide towards answers to above.
>
> thanks.
>
> —
> 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

3

Unbind your miniport from all protocols except your own.

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-304892-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, November 01, 2007 7:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

All

I have a protocol driver whose protocol type is not IP (also the
ethertype will not be 802.3). The miniport indicates multiple packets
and hence full packets (I have verbally conformed this from my miniport
team - that they indicate multiple packets whenever possible and hence
full pkts). But in my protocol driver the callback is ProtocolReceive
instead of ProtocolReceivePacket.

  1. Is that because our protocol type is not IP and ether is not 802.3
    (Maybe Ndis.sys is interjecting and only providing look-ahead data to
    all bound protocols to optimize the order in which it hands over the
    pkts to bound protocols in future. !!!. But always we get partial pkts
    i.e. ProtocolReceive never full packets i.e. ProtocolReceivePacket).

  2. If it is because of any of the reasons above, can miniport change
    the protocol/ethertypes to IP/802.3 temporarily and force ndis to
    handover full pkts ( but also only to my protocol driver (if that is
    feasible and makes sense)).

  3. Also why doesn’t we have a NDIS function for protocol drivers to
    receive full packets i.e. ProtocolReceivePacketS() or
    ProtocolReceivePacket(…, ndis_paket, count) etc. when the miniport
    indicates array of packets. Why do protocol drivers sill get called
    back only for single packet (at least looking at the protocol driver RX
    callback signatures)

Basically I want to know how I can make NDIS.sys to handover full pkts
in to my protocol driver (at this time assuming my miniport is
indicating pkt lists and hence full pkts).

Please let me know of any info that can guide towards answers to above.

thanks.

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

4

Varenni
Thank you. How can I check what are all the IM drivers bound to miniport?

Thomas
Our miniport will have to bind to TCp/IP and also my protocol driver.
Basiclaly it has to bound to all existing standard protocols and additionally to my new protocol
( I made my protocol driver to bind only to our miniport though, guess that not teh issue here).

I am checking to see what all IM drivers are bound now to our miniport and in our configuration, if those are needed or can disabled or modified so that I receive full pkts. Hopefully binding of IM protocols is controlled i.e. not any 3’rd party IM driver can come up and bind to any miniport.

5

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-304899-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, November 01, 2007 8:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive
vs ProtocolReceivePacket)

Varenni
Thank you. How can I check what are all the IM drivers bound to
miniport?

Thomas
Our miniport will have to bind to TCp/IP and also my protocol driver.
Basiclaly it has to bound to all existing standard protocols and
additionally to my new protocol
( I made my protocol driver to bind only to our miniport though, guess
that not the issue here).
[PCAUSA] I seem to recall that if a packet is indicated to multiple protocols then one of them will be called at ProtocolReceivePackets and others will be called at ProtocolReceive.

I don’t know how to control which is called at which callback…

Thomas F. Divine

I am checking to see what all IM drivers are bound now to our miniport
and in our configuration, if those are needed or can disabled or
modified so that I receive full pkts. Hopefully binding of IM protocols
is controlled i.e. not any 3’rd party IM driver can come up and bind to
any miniport.

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

6

Thomas

Thank you. DDK on NdisMIndicateReceivePacket

“…When a miniport driver calls NdisMIndicateReceivePacket, NDIS passes each pointer at ReceivePackets separately, in the miniport driver-determined order, to the ProtocolReceivePacket function(s) of bound protocol(s) that export this function. To other bound protocols, NDIS passes each packet pointer to the ProtocolReceive function(s)…”

Above verbatim is unclear and seem to suggest both ways. Anyways

  1. what is the miniport driver-determined order?
  2. How is it decided who gets called back at ProtocolReceivePacket and who gets called at ProtocolReceive?

Hope MS folks can throw some light on this for me.
Not sure if this helps, but my protocol driver receives pkts of a unique protocol type which no other protocol drver in teh system will be interested in and my protocol driver is bound only to my miniport (i.e not to all installed NICs).

Our miniport driver and IM driver both use NdisMIndicateReceivePacket to indicate full packets to their upper edge.

Right now I am using NdistransferData->ProtocolTransferDatacomplete (basically the NdisProt sample).

Also DDK says
“…When NDIS calls the ProtocolReceive function of a driver that exports a ProtocolReceivePacket function, ProtocolReceive can call NdisGetReceivedPacket and NDIS_GET_ORIGINAL_PACKET to retrieve the out-of-band information associated with an incoming packet that was indicated as part of a packet array…”

I will try NdisGetReceivedPacket / NDIS_GET_ORIGINAL_PACKET in the context of ProtocolReceive itself and hopefully have the whole pkt there itself instead of calling NdisTransferData and waiting to be called back at ProtocolTransferDatacomplete(). The later is making me to have unnecessary code requiring me to maintain rx pkt/buffer pools in my protocol driver too (in addition to those already maintained by natively by the miniport).

7

NDIS will call a ProtocolReceive() handler when the original packet is
indicated to NdisMIndicatePacket() with the packet status set to
NDIS_STATUS_RESOURCES.

NDIS will also call a ProtocolRecieve() handler when, during he completion
processing of send, the packet matches the loopback or local filter
criteria. In this case the system cannot provide the packet because the
packet is already owned by a ‘protocol’.

However, it is my understanding that NDIS will endeavor to indicate the
NDIS_PACKET via ProtocolReceivePacket() to every bound protocol that has
such a handler. The return value from those handlers is a reference count
that NDIS internally maintains. Only when that reference count reaches
(effectively) zero due to calls to NdisReturnPackets() will (the) NDIS
(wrapper) return the packet to the indicating Miniport via
MiniportReturnPacket().

But consider what happens if a Protocol return a non-zero reference count.
At that point, the protocol has taken ‘ownership’ of the packet and thus has
the exlusive right to use the ProtocolReserved field of the packet. It
is therefore impossible to ‘give’ this packet to another Protocol. Thus the
behavior that NDIS will only indicate a receive to ProtocolReceivePacket()
as long as the packet is not already accepted by a previous protocol in the
binding list.

Since most packets are of interest to only one protocol, this is not
typically a problem. Some rather curious side-effects can occur, however,
with performance and such if the binding order of protocols that are both
interested in a subset of LAN traffic get shifted around.

In my experience most common reason for a protocol to get a
ProtocolReceive() when the developer was expecting a ProtocolReceivePacket()
is the NDIS_STATUS_RESOURCES indication. In this case, however, it sounds
like both your protocol and another in the system are likely interested in
the same packets. Since your protocol is (conincidently) after the other
protocol in the Miniport Open List, well, you lose.

In the bad old days of thinking that IM drivers were the greatest thing
since running water and flushing toilets, the way to get an asyncronously
ownable read-only reference to a received packet was to have an IM driver
(instead of a protocol) that was just ‘passing through’ the packet. Since
the IM driver can ‘add to’ the reference count (in a sense) by holding both
a ‘passthru’ reference and an ‘internal’ reference, the buffer copy can be
avoided. The impact, however, of an IM driver tends to overwhelm the
savings, however, and so I suggest you stick with the Pure Protocol approach
and just deal with the necessary fact that if you share a packet with TCPIP,
chances are one of you will have to buffer the packet.

Good Luck,
-dave

David R. Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, November 02, 2007 5:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

Thomas

Thank you. DDK on NdisMIndicateReceivePacket

“…When a miniport driver calls NdisMIndicateReceivePacket, NDIS passes
each pointer at ReceivePackets separately, in the miniport driver-determined
order, to the ProtocolReceivePacket function(s) of bound protocol(s) that
export this function. To other bound protocols, NDIS passes each packet
pointer to the ProtocolReceive function(s)…”

Above verbatim is unclear and seem to suggest both ways. Anyways

  1. what is the miniport driver-determined order?
  2. How is it decided who gets called back at ProtocolReceivePacket and who
    gets called at ProtocolReceive?

Hope MS folks can throw some light on this for me.
Not sure if this helps, but my protocol driver receives pkts of a unique
protocol type which no other protocol drver in teh system will be interested
in and my protocol driver is bound only to my miniport (i.e not to all
installed NICs).

Our miniport driver and IM driver both use NdisMIndicateReceivePacket to
indicate full packets to their upper edge.

Right now I am using NdistransferData->ProtocolTransferDatacomplete
(basically the NdisProt sample).

Also DDK says
“…When NDIS calls the ProtocolReceive function of a driver that exports a
ProtocolReceivePacket function, ProtocolReceive can call
NdisGetReceivedPacket and NDIS_GET_ORIGINAL_PACKET to retrieve the
out-of-band information associated with an incoming packet that was
indicated as part of a packet array…”

I will try NdisGetReceivedPacket / NDIS_GET_ORIGINAL_PACKET in the context
of ProtocolReceive itself and hopefully have the whole pkt there itself
instead of calling NdisTransferData and waiting to be called back at
ProtocolTransferDatacomplete(). The later is making me to have unnecessary
code requiring me to maintain rx pkt/buffer pools in my protocol driver too
(in addition to those already maintained by natively by the miniport).

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

8

Yes, I really did read this post. Really. It is early, I have not had
enough coffee. (Even at 3pm I have not had enough coffee).

You are not sharing packets with TCPIP. I got that. I just had a synaptic
disconnect due to low cafeen levels. My appologies.

However, do you have NETMON or Ethereal bound to your adapter to watch what
is going on (or both!)? Make sure your protocol is ‘first’ in the binding
order or, as others suggest, start with being ‘only’ in the binding order!

Also (I have not confirmed this, it is a hunch) it is quite possible that
TCPIP or NDISUIO or any other protocol might queue packets indcated to its
ProtocolReceivePacket() without first checking the MAC header to see if the
packet is even interesting. In that case, it truly will be bad luck for the
remaining protocols.

-dave

-----Original Message-----
From: David R. Cattley [mailto:xxxxx@msn.com]
Sent: Friday, November 02, 2007 9:32 AM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

NDIS will call a ProtocolReceive() handler when the original packet is
indicated to NdisMIndicatePacket() with the packet status set to
NDIS_STATUS_RESOURCES.

NDIS will also call a ProtocolRecieve() handler when, during he completion
processing of send, the packet matches the loopback or local filter
criteria. In this case the system cannot provide the packet because the
packet is already owned by a ‘protocol’.

However, it is my understanding that NDIS will endeavor to indicate the
NDIS_PACKET via ProtocolReceivePacket() to every bound protocol that has
such a handler. The return value from those handlers is a reference count
that NDIS internally maintains. Only when that reference count reaches
(effectively) zero due to calls to NdisReturnPackets() will (the) NDIS
(wrapper) return the packet to the indicating Miniport via
MiniportReturnPacket().

But consider what happens if a Protocol return a non-zero reference count.
At that point, the protocol has taken ‘ownership’ of the packet and thus has
the exlusive right to use the ProtocolReserved field of the packet. It
is therefore impossible to ‘give’ this packet to another Protocol. Thus the
behavior that NDIS will only indicate a receive to ProtocolReceivePacket()
as long as the packet is not already accepted by a previous protocol in the
binding list.

Since most packets are of interest to only one protocol, this is not
typically a problem. Some rather curious side-effects can occur, however,
with performance and such if the binding order of protocols that are both
interested in a subset of LAN traffic get shifted around.

In my experience most common reason for a protocol to get a
ProtocolReceive() when the developer was expecting a ProtocolReceivePacket()
is the NDIS_STATUS_RESOURCES indication. In this case, however, it sounds
like both your protocol and another in the system are likely interested in
the same packets. Since your protocol is (conincidently) after the other
protocol in the Miniport Open List, well, you lose.

In the bad old days of thinking that IM drivers were the greatest thing
since running water and flushing toilets, the way to get an asyncronously
ownable read-only reference to a received packet was to have an IM driver
(instead of a protocol) that was just ‘passing through’ the packet. Since
the IM driver can ‘add to’ the reference count (in a sense) by holding both
a ‘passthru’ reference and an ‘internal’ reference, the buffer copy can be
avoided. The impact, however, of an IM driver tends to overwhelm the
savings, however, and so I suggest you stick with the Pure Protocol approach
and just deal with the necessary fact that if you share a packet with TCPIP,
chances are one of you will have to buffer the packet.

Good Luck,
-dave

David R. Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, November 02, 2007 5:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

Thomas

Thank you. DDK on NdisMIndicateReceivePacket

“…When a miniport driver calls NdisMIndicateReceivePacket, NDIS passes
each pointer at ReceivePackets separately, in the miniport driver-determined
order, to the ProtocolReceivePacket function(s) of bound protocol(s) that
export this function. To other bound protocols, NDIS passes each packet
pointer to the ProtocolReceive function(s)…”

Above verbatim is unclear and seem to suggest both ways. Anyways

  1. what is the miniport driver-determined order?
  2. How is it decided who gets called back at ProtocolReceivePacket and who
    gets called at ProtocolReceive?

Hope MS folks can throw some light on this for me.
Not sure if this helps, but my protocol driver receives pkts of a unique
protocol type which no other protocol drver in teh system will be interested
in and my protocol driver is bound only to my miniport (i.e not to all
installed NICs).

Our miniport driver and IM driver both use NdisMIndicateReceivePacket to
indicate full packets to their upper edge.

Right now I am using NdistransferData->ProtocolTransferDatacomplete
(basically the NdisProt sample).

Also DDK says
“…When NDIS calls the ProtocolReceive function of a driver that exports a
ProtocolReceivePacket function, ProtocolReceive can call
NdisGetReceivedPacket and NDIS_GET_ORIGINAL_PACKET to retrieve the
out-of-band information associated with an incoming packet that was
indicated as part of a packet array…”

I will try NdisGetReceivedPacket / NDIS_GET_ORIGINAL_PACKET in the context
of ProtocolReceive itself and hopefully have the whole pkt there itself
instead of calling NdisTransferData and waiting to be called back at
ProtocolTransferDatacomplete(). The later is making me to have unnecessary
code requiring me to maintain rx pkt/buffer pools in my protocol driver too
(in addition to those already maintained by natively by the miniport).

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

9

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 01, 2007 5:44 PM
Subject: RE:[ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

> Varenni
> Thank you. How can I check what are all the IM drivers bound to miniport?
>

I usually use the ndiskd extensions of Windbg. You use !protocols and
!miniports to list the various miniports and protocols. Then !protocol
to list who binds to whom (remembering that an IM is a
protocol and a miniport). This is what I usually do. You can probably obtain
a similar result by using the Device manager, enabling the option “Show
hidden devices” and then looking at the Network adapters list. If you have
an IM called “foo” you will find something like
|- MyMiniport
|- MyMiniport - FOO

> Thomas
> Our miniport will have to bind to TCp/IP and also my protocol driver.

Uhm, in another mail in this thread you said

—
Not sure if this helps, but my protocol driver receives pkts of a unique
protocol type which no other protocol drver in teh system will be interested
in and my protocol driver is bound only to my miniport (i.e not to all
installed NICs).
—

Is TCP/IP bound to your miniport or not?

Have a nice day
GV

–
Gianluca Varenni, Windows DDK MVP

CACE Technologies
http://www.cacetech.com

> Basiclaly it has to bound to all existing standard protocols and
> additionally to my new protocol
> ( I made my protocol driver to bind only to our miniport though, guess
> that not teh issue here).
>
> I am checking to see what all IM drivers are bound now to our miniport and
> in our configuration, if those are needed or can disabled or modified so
> that I receive full pkts. Hopefully binding of IM protocols is controlled
> i.e. not any 3’rd party IM driver can come up and bind to any miniport.
>
> —
> 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

10

Varenni
Yes TCP/IP is also bound to our miniport along with my protocol.

Dave
Thank you for both the answers. Certainly threw some more light in understanding issues involved for me.

-Yes. I am not sharing pkts with TCP/IP.

> Make sure your protocol is ‘first’ in the binding order or,
>as others suggest, start with being ‘only’ in the binding order!

(Our miniport/IM has to support TCP/IP and other protocols also). But I will make sure my protocol driver is first in the binding order. I am assuming that is achieved through, speicfying my protocol first in the upper edge of miniport (and IM INF also ?). Let me know if that is not the way to achieve the binding order.
BTW my protocol lower edge has only my protocol listed (no ndisx etc, so it will not bind to all the NICs, just our NIC which supports that protocol).

11

You are saying that your miniport passes custom packets to your custom
protocol driver. What is the upper edge or your protocol driver?

GV

Gianluca Varenni, Windows DDK MVP

CACE Technologies
http://www.cacetech.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, November 02, 2007 10:32 AM
Subject: RE:[ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

> Varenni
> Yes TCP/IP is also bound to our miniport along with my protocol.
>
> Dave
> Thank you for both the answers. Certainly threw some more light in
> understanding issues involved for me.
>
> -Yes. I am not sharing pkts with TCP/IP.
>
>>> Make sure your protocol is ‘first’ in the binding order or,
>>>as others suggest, start with being ‘only’ in the binding order!
>
> (Our miniport/IM has to support TCP/IP and other protocols also). But I
> will make sure my protocol driver is first in the binding order. I am
> assuming that is achieved through, speicfying my protocol first in the
> upper edge of miniport (and IM INF also ?). Let me know if that is not the
> way to achieve the binding order.
> BTW my protocol lower edge has only my protocol listed (no ndisx etc, so
> it will not bind to all the NICs, just our NIC which supports that
> protocol).
>
>
>
>
> —
> 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

12

Varenni

Below is my protocol driver INF.

HKR,Ndi\Interfaces, “UpperRange”, noupper
HKR,“Ndi\Interfaces”,“LowerRange”,MyProtocol //Bind only to those miniports supporting MyProtocol which is our own NIC
;HKR,“Ndi\Interfaces”,“LowerRange”,“ndis4,ndis5,ndis5_prot” //commented out so that my protoocl driver binds only to our miniport exposing that MyProtocol in its upper edge.

I hope that is what you asked.
I can provide more details but our NIC stack (which ends at my protocol driver at the top) gets linked with other standard stack on top of it, so i get pkts in to my protocol driver from that stack which is well defined etc.

13

Thomas,

[PCAUSA] I seem to recall that if a packet is indicated to multiple protocols then one of them > will be called at ProtocolReceivePackets and others will be called at ProtocolReceive.

I think it depends on whether protocols are interested in packet. As long as no one returns
non-zero refcount from its ReceivePacke() handler, NDIS can keep on indicating this packet.
However, if some protocol returns non-zero refcount from its ReceivePacke() handler , then this protocol will own the packet until it returns it to NDIS with NdisReturnPackets().
At this point NDIS will have to force all other protocols who have not yet been indicated this packet to make their own copies of it - after all, the same packet cannot have more than one owner at a time, can it??? Therefore, NDIS will have either to do media-specific indication, or to indicate a packet with NDIS_STATUS_RESOURCES.

Therefore, if multiple protocols are bound to the underlying miniport, then the OP has a good reason to expect either a media-specific indication or a packet with NDIS_STATUS_RESOURCES, despite the fact that underlying miniport does packet-based indications and never sets NDIS_STATUS_RESOURCES in packets that it indicates…

I don’t know how to control which is called at which callback…

Well, if my above mentioned vision of things is correct, then this is just beyond protocol’s control - after all, protocols X just cannot control what protocol Y does…

Anton Bassov

14

>>Therefore, NDIS will have either to do media-specific indication, or to indicate a packet with NDIS_STATUS_RESOURCES.?
What is a media-specific indication?

Also, I am planning to use NdisGetReceivedPacket / NDIS_GET_ORIGINAL_PACKET in the context of ProtocolReceive itself and thus not do NdisTransferData and wait for ProtocolTransferDataComplete.

That way I can read the data from the original pkt as soon as possible and not have to indicate a separate pkt/buffer pool in protocol driver also in addition to what is there already in the miniport (of course when status_resources happens I will have to make a copy but that is a rare occurrence I suppose and hence my rx Q depth does not have to be large).

I have some questions on above approach though
(I am yet to investigate those, but any pointers would be helpful)

  1. For the NDIS_PACKET I get from NdisGetReceivedPacket() / NDIS_GET_ORIGINAL_PACKET, it says it is read-only. What does that mean. What can I do on it and what I cannot. Specifically how long that pkt is valid?

  2. I am assuming I can just call NdisGetReceivedPacket in ProtocolReceive itself. If so why would anyone want to go through ProtocolTransferDataComplete in first place?

  3. DDK on NdisGetReceivedPacket() does not talk about NdisReturnPackets() at all, so what is the life of the pkt it returns and how do I indicate to NDIS that I am done with the packet?

Like what if one misbehaving protocol got a reference to my protocol pkt and whiel I got my pkt through NdisGetReceivedPacket(), it does a NdisReturnPackets()???

Any pointers would be helpful…

15

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-305104-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Sunday, November 04, 2007 5:23 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive
vs ProtocolReceivePacket)

>>Therefore, NDIS will have either to do media-specific indication,
or to indicate a packet with NDIS_STATUS_RESOURCES.?
What is a media-specific indication?

Also, I am planning to use NdisGetReceivedPacket /
NDIS_GET_ORIGINAL_PACKET in the context of ProtocolReceive itself and
thus not do NdisTransferData and wait for ProtocolTransferDataComplete.

That way I can read the data from the original pkt as soon as possible
and not have to indicate a separate pkt/buffer pool in protocol driver
also in addition to what is there already in the miniport (of course
when status_resources happens I will have to make a copy but that is a
rare occurrence I suppose and hence my rx Q depth does not have to be
large).

I have some questions on above approach though
(I am yet to investigate those, but any pointers would be helpful)

  1. For the NDIS_PACKET I get from NdisGetReceivedPacket() /
    NDIS_GET_ORIGINAL_PACKET, it says it is read-only. What does that
    mean. What can I do on it and what I cannot. Specifically how long that
    pkt is valid?
    [PCAUSA] It is valid until you return from your ProtocolReceive handler.

The packet is read-only. What more can be said? You cannot modify the packet or its contents.

  1. I am assuming I can just call NdisGetReceivedPacket in
    ProtocolReceive itself. If so why would anyone want to go through
    ProtocolTransferDataComplete in first place?
    [PCAUSA] You only need to call NdisTransferData if a full packet is not indicated. A “full packet” means that LookaheadBufferSize == PacketSize. When this is true the HeaderBuffer and LookaheadBuffer together contain all bytes of the packet and there is no need to call NdisTransferData. This does not, however, guarantee that NdisGetReceivedPacket will return a non-NULL packet.
  1. DDK on NdisGetReceivedPacket() does not talk about
    NdisReturnPackets() at all, so what is the life of the pkt it returns
    and how do I indicate to NDIS that I am done with the packet?

[PCAUSA] It is valid until you return from your ProtocolReceive handler.

Like what if one misbehaving protocol got a reference to my protocol
pkt and whiel I got my pkt through NdisGetReceivedPacket(), it does a
NdisReturnPackets()???

Any pointers would be helpful…
[PCAUSA] The DDK documentation of ProtocolReceive is helpful.

Thomas F. Divine

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

16

Thomas and Anton, Thanks

>This does not, however, guarantee that NdisGetReceivedPacket will return a non-NULL packet.

O.k Above explains the rest !

17

> Also, I am planning to use NdisGetReceivedPacket / ?

NDIS_GET_ORIGINAL_PACKET in the context of ProtocolReceive itself and
thus not do NdisTransferData and wait for ProtocolTransferDataComplete.

NdisGetReceivedPacket can return NULL.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

18

One minor amplification of a point Thomas makes…

The packet is read-only. What more can be said? You cannot modify the
packet or its contents.

Not only is the the ‘packet’ read-only but the NDIS_PACKET ‘descriptor’ of
the packet is read-only including the present arrangement of the
NDIS_BUFFER(s), the ProtocolReserved fields, indeed everything. That means
about the only thing you can safely do with this packet is read it. You
absolutely must not do anything which modifies the packet descriptor, buffer
chains, or buffer contents.

And one minor extension of a point Thomas makes …

A “full packet” means that LookaheadBufferSize == PacketSize.

It is possible (although thankfully rare with current NICs) that an
indication at ProtocolReceive() can show up with LookaheadBufferSize !=
PacketSize *and* NdisGetReceivedPacket() *NOT* be NULL. The (read-only)
packet returned by NdisGetReceivePacket() does indeed contain the full
packet. But what you will find is that it is described by two (or more)
NDIS_BUFFER(s) chained.

At issue is what NDIS is free to do when indicating a ‘legacy’ style packet
when it indeed has a full NDIS_PACKET to work with. The header is always in
the first NDIS_BUFFER (MDL). The remainder of that buffer is presented as
the look-a-head data, or, I suppose, the full ‘next’ buffer it that happens
to fall just on the correct boudnary. If the packet is described by more
than one NDIS_BUFFER (often the case for a loopback packet sent by
TCPIP.SYS) then you might not get much more than the IP/UDP header in the
look-a-head data. However, the ‘full’ packet might still be available via
NdisGetReceivedPacket().

So the only caveat here is that NdisGetReceivedPacket() should be tested
before assuming that LookaheadBufferSize != PacketSize means the entire
packet is not available at the time of indication.

Also, keep in mind that minimum look-a-head size is apropos only the true
‘received’ packet and not a loopback (which will have the full packet
lurking under the covers anyway).

Good Luck
-dave

David R. Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Sunday, November 04, 2007 9:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive vs
ProtocolReceivePacket)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-305104-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Sunday, November 04, 2007 5:23 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ProtocolDriver Receive Callbacks (ProtocolReceive
vs ProtocolReceivePacket)

>>Therefore, NDIS will have either to do media-specific indication,
or to indicate a packet with NDIS_STATUS_RESOURCES.?
What is a media-specific indication?

Also, I am planning to use NdisGetReceivedPacket /
NDIS_GET_ORIGINAL_PACKET in the context of ProtocolReceive itself and
thus not do NdisTransferData and wait for ProtocolTransferDataComplete.

That way I can read the data from the original pkt as soon as possible
and not have to indicate a separate pkt/buffer pool in protocol driver
also in addition to what is there already in the miniport (of course
when status_resources happens I will have to make a copy but that is a
rare occurrence I suppose and hence my rx Q depth does not have to be
large).

I have some questions on above approach though (I am yet to
investigate those, but any pointers would be helpful)

  1. For the NDIS_PACKET I get from NdisGetReceivedPacket() /
    NDIS_GET_ORIGINAL_PACKET, it says it is read-only. What does that
    mean. What can I do on it and what I cannot. Specifically how long
    that pkt is valid?
    [PCAUSA] It is valid until you return from your ProtocolReceive handler.

The packet is read-only. What more can be said? You cannot modify the packet
or its contents.

  1. I am assuming I can just call NdisGetReceivedPacket in
    ProtocolReceive itself. If so why would anyone want to go through
    ProtocolTransferDataComplete in first place?
    [PCAUSA] You only need to call NdisTransferData if a full packet is not
    indicated. A “full packet” means that LookaheadBufferSize == PacketSize.
    When this is true the HeaderBuffer and LookaheadBuffer together contain all
    bytes of the packet and there is no need to call NdisTransferData. This does
    not, however, guarantee that NdisGetReceivedPacket will return a non-NULL
    packet.
  1. DDK on NdisGetReceivedPacket() does not talk about
    NdisReturnPackets() at all, so what is the life of the pkt it returns
    and how do I indicate to NDIS that I am done with the packet?

[PCAUSA] It is valid until you return from your ProtocolReceive handler.

Like what if one misbehaving protocol got a reference to my protocol
pkt and whiel I got my pkt through NdisGetReceivedPacket(), it does a
NdisReturnPackets()???

Any pointers would be helpful…
[PCAUSA] The DDK documentation of ProtocolReceive is helpful.

Thomas F. Divine

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