question on NDIS_PACKET structure...

OSR_Community_User · August 10, 2004, 5:59pm

Hi,

I have an NDIS intermediate driver that is working fine. Now I want to
insert my own packets into the outgoing stream. So, I’m building the packet
descriptor/buffer, etc, and calling NdisSend(). When the miniport driver
below me completes the send I don’t think I want to call NdisMSendComplete()
because I think that would confuse the protocol driver above me. First, is
this a correct assumption?

Now, I want to insert something into the MiniportReserved field in the
NDIS_PACKET structure that I allocated on the send and I’m confused by the
DDK docs a bit. Here’s a snippet from the NDIS_PACKET help description:

A single driver can use the MiniportReserved(Ex) area and a single driver
can use the ProtocolReserved area while a particular packet descriptor is
being used in a transfer operation. Consequently, NDIS intermediate drivers,
which have both MiniportXxx and ProtocolXxx functions, cannot use these
areas in incoming packet descriptors for their own purposes.

Does this mean I can’t use the MiniportReserved field AT ALL or only on
packets coming down from the protocol? It seems like I should be able to
use it because the Passthru sample does some stuff with it to store the
original packet descriptor pointer. Also, how can I use it? Can I allocate
a small block of memory and store my per packet data in there and then
assign the address to the MiniportReserved field?

Just want to un-confuse myself.

Thanks,
Paul

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

Thomas_F_Divine · August 10, 2004, 10:19pm

“Paul Benware” wrote in message news:xxxxx@ntdev…
Hi,

I have an NDIS intermediate driver that is working fine. Now I want to insert my own packets into the outgoing stream. So, I’m building the packet descriptor/buffer, etc, and calling NdisSend(). When the miniport driver below me completes the send I don’t think I want to call NdisMSendComplete() because I think that would confuse the protocol driver above me. First, is this a correct assumption?

You are correct. NdisMSentComplete tells the sender (above) that the a packet the it sent has been completed. In this case, the protocol above did not send the packet, so it doesn’t make any sense to make this call.

Now, I want to insert something into the MiniportReserved field in the NDIS_PACKET structure that I allocated on the send and I’m confused by the DDK docs a bit. Here’s a snippet from the NDIS_PACKET help description:

Hang on there!!!

You said that you want to “insert my own packets into the outgoing stream”. If you lookup NdisSend and NdisSendPackets you will find that they are functions that are called by NDIS protocols. If you IM driver is calling either of these functions, then it must actually be doing so in the context of it’s lower-edge “protocol” interface. What this means is that in the NDIS packet that YOU send YOU own the ProtocolReserved area and the miniport (below you) owns the MiniportReserved fields.

Don’t get confused…

If you are calling NdisSend you are a NDIS protocol and you own the ProtocolReserved area - but NOT the MiniportReserved area. The miniport below you owns the MiniportReserved area.

A single driver can use the MiniportReserved(Ex) area and a single driver can use the ProtocolReserved area while a particular packet descriptor is being used in a transfer operation. Consequently, NDIS intermediate drivers, which have both MiniportXxx and ProtocolXxx functions, cannot use these areas in incoming packet descriptors for their own purposes.

Does this mean I can’t use the MiniportReserved field AT ALL or only on packets coming down from the protocol? It seems like I should be able to use it because the Passthru sample does some stuff with it to store the original packet descriptor pointer. Also, how can I use it? Can I allocate a small block of memory and store my per packet data in there and then assign the address to the MiniportReserved field?

1.) As a packet is being sent from a higher-level protocol down to the upper-edge or “miniport” interface of a lower-level NDIS IM driver…

When a packet enters your NDIS IM driver from above it enters at the NDIS IM driver upper-edge or “miniport” interface. For this send packet descriptor the protocol (above you) already owns the ProtocolReserved area. For this send packet descriptor you own the MiniportReserved areas (since you are the miniport the packet was sent to…).

Make sure you understand: for this particular NDIS packet descriptor both the ProtocolReserved and the MiniportReserved area have well-defined “owners”.

You can probably see now why NDIS IM drivers must at least “re-wrap packets in a fresh packet descriptor” as they pass through. It is only through this additional step that a new set of packet descriptors can be made available to pass the packet along on it’s journey.

In the new NDIS packet descriptor you can use the ProtocolReserved area of the “fresh packet descriptor” since your NDIS IM driver’s lower-edge “protocol” inteface will be calling NdisSend or NdisSendPackets. And, as mentioned above, the minipport below you is the owner of the MiniportReserved ares of the “fresh packet descriptor”.

2.) As a packet is being received from a lower-level miniport below up to the lower-edge or “protocol” interface of a higher-level NDIS IM driver…

The reverse is true.

A little monotonous here.

Hope this helps.

Thomas F. Divine, Windows DDK MVP

http://www.pcausa.com

http://www.ndis.com

Just want to un-confuse myself.

Thanks,
Paul

----------------------------

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

Maxim_S_Shatskih · August 11, 2004, 3:33am

You can use the pool handle field in NDIS_PACKET structure to distinguish your packets from the packets came from above.

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

----- Original Message -----
From: Paul Benware
To: Windows System Software Devs Interest List
Sent: Wednesday, August 11, 2004 1:57 AM
Subject: [ntdev] question on NDIS_PACKET structure…

Hi,

I have an NDIS intermediate driver that is working fine. Now I want to insert my own packets into the outgoing stream. So, I’m building the packet descriptor/buffer, etc, and calling NdisSend(). When the miniport driver below me completes the send I don’t think I want to call NdisMSendComplete() because I think that would confuse the protocol driver above me. First, is this a correct assumption?

Now, I want to insert something into the MiniportReserved field in the NDIS_PACKET structure that I allocated on the send and I’m confused by the DDK docs a bit. Here’s a snippet from the NDIS_PACKET help description:

A single driver can use the MiniportReserved(Ex) area and a single driver can use the ProtocolReserved area while a particular packet descriptor is being used in a transfer operation. Consequently, NDIS intermediate drivers, which have both MiniportXxx and ProtocolXxx functions, cannot use these areas in incoming packet descriptors for their own purposes.

Does this mean I can’t use the MiniportReserved field AT ALL or only on packets coming down from the protocol? It seems like I should be able to use it because the Passthru sample does some stuff with it to store the original packet descriptor pointer. Also, how can I use it? Can I allocate a small block of memory and store my per packet data in there and then assign the address to the MiniportReserved field?

Just want to un-confuse myself.

Thanks,
Paul

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · August 11, 2004, 8:06am

Isn’t the pool handle in the “Private” section of the structure? I.e. Off
limits?

Paul Benware

Director of Client Development

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, August 11, 2004 3:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] question on NDIS_PACKET structure…

You can use the pool handle field in NDIS_PACKET structure to
distinguish your packets from the packets came from above.

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

----- Original Message -----

From: Paul Benware mailto:xxxxx

To: Windows System mailto:xxxxx Software Devs Interest List

Sent: Wednesday, August 11, 2004 1:57 AM

Subject: [ntdev] question on NDIS_PACKET structure…

Hi,

I have an NDIS intermediate driver that is working fine. Now I want to
insert my own packets into the outgoing stream. So, I’m building the packet
descriptor/buffer, etc, and calling NdisSend(). When the miniport driver
below me completes the send I don’t think I want to call NdisMSendComplete()
because I think that would confuse the protocol driver above me. First, is
this a correct assumption?

Now, I want to insert something into the MiniportReserved field in the
NDIS_PACKET structure that I allocated on the send and I’m confused by the
DDK docs a bit. Here’s a snippet from the NDIS_PACKET help description:

A single driver can use the MiniportReserved(Ex) area and a single driver
can use the ProtocolReserved area while a particular packet descriptor is
being used in a transfer operation. Consequently, NDIS intermediate drivers,
which have both MiniportXxx and ProtocolXxx functions, cannot use these
areas in incoming packet descriptors for their own purposes.

Does this mean I can’t use the MiniportReserved field AT ALL or only on
packets coming down from the protocol? It seems like I should be able to
use it because the Passthru sample does some stuff with it to store the
original packet descriptor pointer. Also, how can I use it? Can I allocate
a small block of memory and store my per packet data in there and then
assign the address to the MiniportReserved field?

Just want to un-confuse myself.

Thanks,
Paul

----------------------------

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@koolspan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · August 11, 2004, 8:10am

Thanks for the help Thomas. It did dawn on me right after I sent it that I
want to use the ProtocolReserved area. I think I have it now.

Now a related question about this:

The DDK docs says that the ProtocolReserved area is a “variable-sized area”.
How does one know and/or affect the amount of space allocated for this
variable sized area?

Thanks,
Paul

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Tuesday, August 10, 2004 10:18 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] question on NDIS_PACKET structure…

“Paul Benware” wrote in message news:xxxxx@ntdev…

Hi,

I have an NDIS intermediate driver that is working fine. Now I want to
insert my own packets into the outgoing stream. So, I’m building the packet
descriptor/buffer, etc, and calling NdisSend(). When the miniport driver
below me completes the send I don’t think I want to call NdisMSendComplete()
because I think that would confuse the protocol driver above me. First, is
this a correct assumption?

You are correct. NdisMSentComplete tells the sender (above) that the a
packet the it sent has been completed. In this case, the protocol above did
not send the packet, so it doesn’t make any sense to make this call.

Now, I want to insert something into the MiniportReserved field in the
NDIS_PACKET structure that I allocated on the send and I’m confused by the
DDK docs a bit. Here’s a snippet from the NDIS_PACKET help description:

Hang on there!!!

You said that you want to “insert my own packets into the outgoing stream”.
If you lookup NdisSend and NdisSendPackets you will find that they are
functions that are called by NDIS protocols. If you IM driver is calling
either of these functions, then it must actually be doing so in the context
of it’s lower-edge “protocol” interface. What this means is that in the NDIS
packet that YOU send YOU own the ProtocolReserved area and the miniport
(below you) owns the MiniportReserved fields.

Don’t get confused…

If you are calling NdisSend you are a NDIS protocol and youown the
ProtocolReserved area - but NOT the MiniportReserved area. The miniport
below you owns the MiniportReserved area.

A single driver can use the MiniportReserved(Ex) area and a single driver
can use the ProtocolReserved area while a particular packet descriptor is
being used in a transfer operation. Consequently, NDIS intermediate drivers,
which have both MiniportXxx and ProtocolXxx functions, cannot use these
areas in incoming packet descriptors for their own purposes.

Does this mean I can’t use the MiniportReserved field AT ALL or only on
packets coming down from the protocol? It seems like I should be able to
use it because the Passthru sample does some stuff with it to store the
original packet descriptor pointer. Also, how can I use it? Can I allocate
a small block of memory and store my per packet data in there and then
assign the address to the MiniportReserved field?

1.) As a packet is being sent from a higher-level protocol down tothe
upper-edge or “miniport” interface of a lower-level NDIS IM driver…

When a packet entersyour NDIS IM driver from above it enters at the NDIS IM
driver upper-edge or “miniport” interface. For this send packet descriptor
the protocol (above you) already owns the ProtocolReserved area. For this
send packet descriptor you own the MiniportReserved areas (since you are the
miniport the packet was sent to…).

Make sure you understand: for this particular NDIS packet descriptor both
the ProtocolReserved and the MiniportReserved area have well-defined
“owners”.

You can probably see nowwhy NDIS IM drivers must at least “re-wrap packets
in a fresh packet descriptor” as they pass through. It is only through this
additional step that a new set of packet descriptors can be made available
to pass the packet along on it’s journey.

In the new NDIS packet descriptor you can use the ProtocolReserved area of
the “fresh packet descriptor” since your NDIS IM driver’s lower-edge
“protocol” inteface will be calling NdisSend or NdisSendPackets. And, as
mentioned above, the minipport below you is the owner of the
MiniportReserved ares of the “fresh packet descriptor”.

2.) As a packet is being received from a lower-level miniport below up tothe
lower-edge or “protocol” interface of a higher-level NDIS IM driver…

The reverse is true.

A little monotonous here.

Hope this helps.

Thomas F. Divine, Windows DDK MVP

http://www.pcausa.com

http://www.ndis.com

Just want to un-confuse myself.

Thanks,
Paul

----------------------------

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@koolspan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thomas_F_Divine · August 11, 2004, 9:14am

“Paul Benware” wrote in message news:xxxxx@ntdev…
Thanks for the help Thomas. It did dawn on me right after I sent it that I want to use the ProtocolReserved area. I think I have it now.

Now a related question about this:

The DDK docs says that the ProtocolReserved area is a “variable-sized area”. How does one know and/or affect the amount of space allocated for this variable sized area?

Actually, it turns out that you can only use the ProtocolReserved area in packet descriptors that you have allocated yourself. This means that you simply need to remember the size that you specified when you called NdisAllpcatePacketPool.

Thomas F. Divine, Windows DDK MVP

http://www.rawether.net

Thanks,
Paul

----------------------------

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

------------------------------------------------------------------------------

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Tuesday, August 10, 2004 10:18 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] question on NDIS_PACKET structure…

“Paul Benware” wrote in message news:xxxxx@ntdev…

Hi,

I have an NDIS intermediate driver that is working fine. Now I want to insert my own packets into the outgoing stream. So, I’m building the packet descriptor/buffer, etc, and calling NdisSend(). When the miniport driver below me completes the send I don’t think I want to call NdisMSendComplete() because I think that would confuse the protocol driver above me. First, is this a correct assumption?

You are correct. NdisMSentComplete tells the sender (above) that the a packet the it sent has been completed. In this case, the protocol above did not send the packet, so it doesn’t make any sense to make this call.

Now, I want to insert something into the MiniportReserved field in the NDIS_PACKET structure that I allocated on the send and I’m confused by the DDK docs a bit. Here’s a snippet from the NDIS_PACKET help description:

Hang on there!!!

You said that you want to “insert my own packets into the outgoing stream”. If you lookup NdisSend and NdisSendPackets you will find that they are functions that are called by NDIS protocols. If you IM driver is calling either of these functions, then it must actually be doing so in the context of it’s lower-edge “protocol” interface. What this means is that in the NDIS packet that YOU send YOU own the ProtocolReserved area and the miniport (below you) owns the MiniportReserved fields.

Don’t get confused…

If you are calling NdisSend you are a NDIS protocol and youown the ProtocolReserved area - but NOT the MiniportReserved area. The miniport below you owns the MiniportReserved area.

A single driver can use the MiniportReserved(Ex) area and a single driver can use the ProtocolReserved area while a particular packet descriptor is being used in a transfer operation. Consequently, NDIS intermediate drivers, which have both MiniportXxx and ProtocolXxx functions, cannot use these areas in incoming packet descriptors for their own purposes.

Does this mean I can’t use the MiniportReserved field AT ALL or only on packets coming down from the protocol? It seems like I should be able to use it because the Passthru sample does some stuff with it to store the original packet descriptor pointer. Also, how can I use it? Can I allocate a small block of memory and store my per packet data in there and then assign the address to the MiniportReserved field?

1.) As a packet is being sent from a higher-level protocol down tothe upper-edge or “miniport” interface of a lower-level NDIS IM driver…

When a packet entersyour NDIS IM driver from above it enters at the NDIS IM driver upper-edge or “miniport” interface. For this send packet descriptor the protocol (above you) already owns the ProtocolReserved area. For this send packet descriptor you own the MiniportReserved areas (since you are the miniport the packet was sent to…).

Make sure you understand: for this particular NDIS packet descriptor both the ProtocolReserved and the MiniportReserved area have well-defined “owners”.

You can probably see nowwhy NDIS IM drivers must at least “re-wrap packets in a fresh packet descriptor” as they pass through. It is only through this additional step that a new set of packet descriptors can be made available to pass the packet along on it’s journey.

In the new NDIS packet descriptor you can use the ProtocolReserved area of the “fresh packet descriptor” since your NDIS IM driver’s lower-edge “protocol” inteface will be calling NdisSend or NdisSendPackets. And, as mentioned above, the minipport below you is the owner of the MiniportReserved ares of the “fresh packet descriptor”.

2.) As a packet is being received from a lower-level miniport below up tothe lower-edge or “protocol” interface of a higher-level NDIS IM driver…

The reverse is true.

A little monotonous here.

Hope this helps.

Thomas F. Divine, Windows DDK MVP

http://www.pcausa.com

http://www.ndis.com

Just want to un-confuse myself.

Thanks,
Paul

----------------------------

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@koolspan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · August 11, 2004, 9:43am

Hmm. Thanks again. You’d think that the DDK docs would refer you to this
from the NDIS_PACKET help page instead of leaving you wondering.

Paul Benware

Director of Client Development

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, August 11, 2004 9:13 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] question on NDIS_PACKET structure…

“Paul Benware” wrote in message news:xxxxx@ntdev…

Thanks for the help Thomas. It did dawn on me right after I sent it that I
want to use the ProtocolReserved area. I think I have it now.

Now a related question about this:

The DDK docs says that the ProtocolReserved area is a “variable-sized area”.
How does one know and/or affect the amount of space allocated for this
variable sized area?

Actually, it turns out that you can only use the ProtocolReserved area in
packet descriptors that you have allocated yourself. This means that you
simply need to remember the size that you specified when you called
NdisAllpcatePacketPool.

Thomas F. Divine, Windows DDK MVP

http://www.rawether.net

Thanks,
Paul

----------------------------

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

_____

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Tuesday, August 10, 2004 10:18 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] question on NDIS_PACKET structure…

“Paul Benware” wrote in message news:xxxxx@ntdev…

Hi,

I have an NDIS intermediate driver that is working fine. Now I want to
insert my own packets into the outgoing stream. So, I’m building the packet
descriptor/buffer, etc, and calling NdisSend(). When the miniport driver
below me completes the send I don’t think I want to call NdisMSendComplete()
because I think that would confuse the protocol driver above me. First, is
this a correct assumption?

You are correct. NdisMSentComplete tells the sender (above) that the a
packet the it sent has been completed. In this case, the protocol above did
not send the packet, so it doesn’t make any sense to make this call.

Now, I want to insert something into the MiniportReserved field in the
NDIS_PACKET structure that I allocated on the send and I’m confused by the
DDK docs a bit. Here’s a snippet from the NDIS_PACKET help description:

Hang on there!!!

You said that you want to “insert my own packets into the outgoing stream”.
If you lookup NdisSend and NdisSendPackets you will find that they are
functions that are called by NDIS protocols. If you IM driver is calling
either of these functions, then it must actually be doing so in the context
of it’s lower-edge “protocol” interface. What this means is that in the NDIS
packet that YOU send YOU own the ProtocolReserved area and the miniport
(below you) owns the MiniportReserved fields.

Don’t get confused…

If you are calling NdisSend you are a NDIS protocol and youown the
ProtocolReserved area - but NOT the MiniportReserved area. The miniport
below you owns the MiniportReserved area.

A single driver can use the MiniportReserved(Ex) area and a single driver
can use the ProtocolReserved area while a particular packet descriptor is
being used in a transfer operation. Consequently, NDIS intermediate drivers,
which have both MiniportXxx and ProtocolXxx functions, cannot use these
areas in incoming packet descriptors for their own purposes.

Does this mean I can’t use the MiniportReserved field AT ALL or only on
packets coming down from the protocol? It seems like I should be able to
use it because the Passthru sample does some stuff with it to store the
original packet descriptor pointer. Also, how can I use it? Can I allocate
a small block of memory and store my per packet data in there and then
assign the address to the MiniportReserved field?

1.) As a packet is being sent from a higher-level protocol down tothe
upper-edge or “miniport” interface of a lower-level NDIS IM driver…

When a packet entersyour NDIS IM driver from above it enters at the NDIS IM
driver upper-edge or “miniport” interface. For this send packet descriptor
the protocol (above you) already owns the ProtocolReserved area. For this
send packet descriptor you own the MiniportReserved areas (since you are the
miniport the packet was sent to…).

Make sure you understand: for this particular NDIS packet descriptor both
the ProtocolReserved and the MiniportReserved area have well-defined
“owners”.

You can probably see nowwhy NDIS IM drivers must at least “re-wrap packets
in a fresh packet descriptor” as they pass through. It is only through this
additional step that a new set of packet descriptors can be made available
to pass the packet along on it’s journey.

In the new NDIS packet descriptor you can use the ProtocolReserved area of
the “fresh packet descriptor” since your NDIS IM driver’s lower-edge
“protocol” inteface will be calling NdisSend or NdisSendPackets. And, as
mentioned above, the minipport below you is the owner of the
MiniportReserved ares of the “fresh packet descriptor”.

2.) As a packet is being received from a lower-level miniport below up tothe
lower-edge or “protocol” interface of a higher-level NDIS IM driver…

The reverse is true.

A little monotonous here.

Hope this helps.

Thomas F. Divine, Windows DDK MVP

http://www.pcausa.com

http://www.ndis.com

Just want to un-confuse myself.

Thanks,
Paul

----------------------------

Paul Benware

KoolSpan Inc.

11134 Stephalee Lane

North Bethesda, MD 20852

TELE: 1-301-468-9434

DIRECT: 1-585-582-3296

CELL: 1-585-739-0441

www.koolspan.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@koolspan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@koolspan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com