NDIS Connection-Oriented Intermediate Driver

KevinO

unread,

Nov 15, 2002, 5:46:56 AM11/15/02

to

In NdisIMRegisterLayeredMiniport _MINI_PORT_CHARACTERISTICS has CoXxxx entries
but the documentation (and the threads I have read) explicitly exclude
connection-oriented communication at its upper edge.
I need to access a connectionless miniport from connection-oriented
applications. Can anyone suggest how?

Thanks

KevinO

unread,

Nov 27, 2002, 5:04:57 AM11/27/02

to

"Aditya Dube" <ad...@microsoft.com> wrote in message news:<eqexFWOlCHA.1568@tkmsftngp07>...
> I do not see any reason for this not to work. MUX IM drivers may have a
> Co-NDIS Upper edge and a Connection-less lower edge.
>
> As you said earlier, the miniport and protocol interfaces of a MUX IM driver
> can differ.
>
> We do not have any samples that illustrate how to do this.
>

May I be a little confused please?

Referring to my original posting, the documentation sets all the
CoXxx entries in the NdisIMRegisterLayeredMiniport function to NULL.
Is it the case that there is no in-built inhibition to using these
links to establish a Connection-oriented upper edge on an IM driver
with a connectionless lower edge. (please say yes!!!)

Thanks for your contributions all - it's nice not to feel alone!!

Stephan Wolf

unread,

Nov 15, 2002, 11:05:58 AM11/15/02

to

You seem to be right, the docs say "An NDIS intermediate driver can
support only connectionless communication at its virtual miniport".

However, I have not found any explanation as to *why* this should be
the case.

Any comments anyone?

BTW, I never dealt with "connection-oriented". Maybe Robert Schlabbach
has some answers for us...?

Stephan
---
On 15 Nov 2002 02:46:56 -0800, ke...@omearak.freeserve.co.uk (KevinO)
wrote:

Robert Schlabbach

unread,

Nov 16, 2002, 12:42:44 PM11/16/02

to

"Stephan Wolf" <ste...@hotmail.com> wrote in message
news:3dd51af7...@news.t-online.de...

> You seem to be right, the docs say "An NDIS intermediate driver can
> support only connectionless communication at its virtual miniport".
>
> However, I have not found any explanation as to *why* this should be
> the case.
>
> Any comments anyone?
>
> BTW, I never dealt with "connection-oriented". Maybe Robert Schlabbach
> has some answers for us...?

I don't know why either. Someone from Microsoft would have to enlighten us.
The documentation is consistent on this: In the
NdisIMRegisterLayeredMiniport() documentation, it also says that all CoNDIS
handler pointers must be NULL.

OTOH, it has been observed that specifying an NDISWAN driver as being NDIS
5.0 leads to crashes as NDIS then calls the CoNDIS handlers of the
miniport. I didn't investigate this any further, though, since my own IM
needs to be backwards compatible with Windows versions that only support
NDIS 4.0, but it _may_ be possible that at least IMs with a CoNDIS WAN
(5.0) upper edge are possible...

Regards,«
--
Robert Schlabbach
e-mail: robe...@gmx.net
Berlin, Germany

Stephan Wolf

unread,

Nov 21, 2002, 7:19:19 AM11/21/02

to

Pitty we get no answer from MS here. Maybe we should move this thread
to "microsoft.public.development.device.drivers"...

[done, cross-posted...]

Stephan
---

Aditya Dube [MS]

unread,

Nov 22, 2002, 10:06:49 PM11/22/02

to

NDIS does not support passing Co-NDIS semantics to filters.

For example, filters cannot be informed of VC creation or deletion. There is
also no API to enable the Filter IM driver to get called when the Co-Ndis
client calls NdisCoSendPackets
or when the Co-Ndis miniport calls NdisMCoIndicateReceivePacket.

The MUX Intermediate drivers can have a Co-NDIS lower -edge. This is how
AtmLane.sys is implemented.

We are studying the feasibility of enabling filters to intercept co-ndis
calls for the next version of the OS (the one after .Net Server.)

Aditya Dube

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"Stephan Wolf" <ste...@hotmail.com> wrote in message

news:3ddccef3...@news.t-online.de...

Robert Schlabbach

unread,

Nov 23, 2002, 4:55:42 PM11/23/02

to

Hi Aditya,

you will have to find a solution for this - because of PPP over Ethernet.
Even Microsoft's own PPPoE is only an NDIS 4.0 driver, plainly because it
is an IM, needs a connection-oriented upper edge, and there is no such
thing as NDISWAN 5.0. According to Microsoft, NDISWAN will be scrapped
entirely beyond Longhorn.

Without NDISWAN, there would be _no way at all_ left to implement PPPoE on
Windows. What is needed is the ability to write an NDIS IM with a
connectionless lower edge and a CoNDIS upper edge. The sooner we get this,
the better. Remember that Microsoft will also have to rewrite their own
PPPoE code to this...

Best Regards,

--
Robert Schlabbach
e-mail: robe...@gmx.net
Berlin, Germany

"Aditya Dube [MS]" <ad...@online.microsoft.com> wrote in message
news:u3Ofc1pkCHA.2672@tkmsftngp09...

Maxim S. Shatskih

unread,

Nov 24, 2002, 7:36:06 AM11/24/02

to

> The MUX Intermediate drivers can have a Co-NDIS lower -edge. This is
how

And why not upper?

Am I wrong that, for MUX IM, lower and upper edges are very, very much
independent on one another?
Am I wrong that MUX is, in fact, a protocol + a virtual software-only
miniport in the same binary?

Is it not possible to write a binary which will be both a CoNDIS
miniport and a connectionless protocol?

Max

Aditya Dube

unread,

Nov 25, 2002, 7:48:00 PM11/25/02

to

I do not see any reason for this not to work. MUX IM drivers may have a
Co-NDIS Upper edge and a Connection-less lower edge.

As you said earlier, the miniport and protocol interfaces of a MUX IM driver
can differ.

We do not have any samples that illustrate how to do this.

Aditya Dube

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:arqi14$266s$7...@gavrilo.mtu.ru...