Can NDIS5 drivers be "chained" in Windows XP?

Several years ago we developed an NDIS2 driver in OS/2. When our code is
notified a frame is available (typically via ReceiveLookahead indication),
it returns SUCCESS to indicate it will accept and copy the frame. If there
is more than one driver in the chain, the next driver does NOT get the
indication. Our code also returns FORWARD_FRAME when it wishes to pass along
a frame to the next driver instance in its chain without accepting it and it
returns FRAME_REJECTED when it does not want to accept the frame but also
does not want to pass it to the next driver in the chain. The ability to
chain together drivers and have those toward the rear of the chain NOT see
frames consumed by those toward the front can be an important performance
boost in some situations for us.

We've recently had an outside company rewrite our driver for NDIS in Windows
XP. This driver does not support the idea of a chain of instances where an
instance that receives a frame can choose to accept or reject the frame such
that any other instances of the driver do not receive the frame at all. The
outside vendor cannot determine if/how this can be done in Windows. Is there
a way to achieve this behavior in Windows XP?

Thanks,
Stephen

Thomas
Tue Dec 09 10:51:31 CST 2003

The behavior that you are referring to changed with NDIS 3.1 (possibly as
early as NDIS 3.0...).

In NDIS 3.1 and higher all NDIS transport drivers (highest-level NDIS
protocol drivers) will receive ALL received frames. There is NO action that
a NDIS transport driver can take that will prevent other NDIS transport
drivers from receiving any particular frame. Sorry.

Perhaps an NDIS Intermediate (IM) driver (effectively a filter between the
NDIS miniport and the NDIS transport) can consume the frame for you. See the
PassThru NDIS IM driver sample in the Windows 2003 DDK. There will also be
an article about extending the PassThru NDIS IM driver sample to provide IP
address blocking functionality on the Windows Driver Developer's Digest
(WD-3, http://www.wd-3.com) December 15, 2003 issue.

Hope this helps.

Thomas F. Divine
www.pcausa.com


"Stephen" <smrobinson62 at ureach dot com> wrote in message
news:exYAwkmvDHA.2368@TK2MSFTNGP09.phx.gbl...
> Several years ago we developed an NDIS2 driver in OS/2. When our code is
> notified a frame is available (typically via ReceiveLookahead indication),
> it returns SUCCESS to indicate it will accept and copy the frame. If there
> is more than one driver in the chain, the next driver does NOT get the
> indication. Our code also returns FORWARD_FRAME when it wishes to pass
along
> a frame to the next driver instance in its chain without accepting it and
it
> returns FRAME_REJECTED when it does not want to accept the frame but also
> does not want to pass it to the next driver in the chain. The ability to
> chain together drivers and have those toward the rear of the chain NOT see
> frames consumed by those toward the front can be an important performance
> boost in some situations for us.
>
> We've recently had an outside company rewrite our driver for NDIS in
Windows
> XP. This driver does not support the idea of a chain of instances where an
> instance that receives a frame can choose to accept or reject the frame
such
> that any other instances of the driver do not receive the frame at all.
The
> outside vendor cannot determine if/how this can be done in Windows. Is
there
> a way to achieve this behavior in Windows XP?
>
> Thanks,
> Stephen
>
>

James
Tue Dec 09 11:25:40 CST 2003

Let me explain a bit what IM drivers do, since Thomas mentioned them. An IM
driver sees a packet and has responsibility of forwarding or not forwarding it
to the next driver. A forwarded packet may be unchanged by the IM driver or
changed.

That's a lot of freedom. I expect, however, that you intend somebody or other to
see packets or some transform of them, eg, an underlying NIC driver or an
overlying TCPIP.sys (or whatever TCP/IP is called). In the IM driver, if the
packet is forwarded, you don't control who sees a packet, unchanged or changed,
next.

Now it should be obvious that you can get creative, eg, "drop" the current
packet and, through some other layer such as a TDI client or a TDI transport or
a driver attached directly to a NIC driver's device object, create a new packet
(with the original one's contents, perhaps changed somewhat) and forward that
directly. Just remember, however, that the deeper you get into changing the
"natural" flow, the more responsible you're going to be for all the messy
details (eg, resending, acknowledgment) that one ordinarily leaves to TCP/IP and
friends.

Stephen wrote:

> If there
> is more than one driver in the chain, the next driver does NOT get the
> indication.

[snip]


> The ability to
> chain together drivers and have those toward the rear of the chain NOT see
> frames consumed by those toward the front can be an important performance
> boost in some situations for us.

--
If replying by e-mail, please remove "nospam." from the address.

James Antognini
Windows DDK MVP

Stephan
Wed Dec 10 14:02:16 CST 2003

[re-posting from "kernel-mode"...]

The chaining mechanism has changed between NDIS2 and NDIS3+ in that a
receiving protocol can no longer decide whether a received frame will
or will not be passed to any other protocols.

If you need control over received (and sent) frames then you need to
write either a Filter or a MUX Intermediate driver (IM).

A Filter IM will still not allow you to pass received frames to one
bound protocol while not passing it to others. You'd need a MUX IM for
that purpose, which exposes several virtual adapter instances. Then
have the Notify Object associated with the MUX IM control which
protocols bind to which virtual adapters. The MUX can now decide which
received frames to indicate for which virtual adapters and, thus,
which protocols receive a particular frame.

Not that I have ever seen such an implementation.

Stephan
---
On Tue, 9 Dec 2003 10:29:06 -0500, "Stephen" <smrobinson62 at ureach
dot com> wrote:

>Several years ago we developed an NDIS2 driver in OS/2. When our code is
>notified a frame is available (typically via ReceiveLookahead indication),
>it returns SUCCESS to indicate it will accept and copy the frame. If there
>is more than one driver in the chain, the next driver does NOT get the
>indication. Our code also returns FORWARD_FRAME when it wishes to pass along
>a frame to the next driver instance in its chain without accepting it and it
>returns FRAME_REJECTED when it does not want to accept the frame but also
>does not want to pass it to the next driver in the chain. The ability to
>chain together drivers and have those toward the rear of the chain NOT see
>frames consumed by those toward the front can be an important performance
>boost in some situations for us.
>
>We've recently had an outside company rewrite our driver for NDIS in Windows
>XP. This driver does not support the idea of a chain of instances where an
>instance that receives a frame can choose to accept or reject the frame such
>that any other instances of the driver do not receive the frame at all. The
>outside vendor cannot determine if/how this can be done in Windows. Is there
>a way to achieve this behavior in Windows XP?
>
>Thanks,
>Stephen

Stephen
Wed Dec 17 10:48:27 CST 2003

Thomas, James and Stephan - thanks for the timely and detailed replies.

Regards,
Stephen