Network connection

Hello,

I have written a driver for a proprietary network card (which is not a
standard NIC card). This is a monolithic driver and it neither does
register itself as a NDIS driver nor does it communicate with NDIS
stack.

Now, the question is this ? What should I do to display my network
adapter in 'Network Connections' (in the control panel) ? Should it
necessarily be registered as a NDIS driver or is there any other
solution for this ?

I need this because I have a generic application that gets the list of
network adapters from Network Connections in the Control Panel, and
communicates with them.

Thanks,
Srivi.

soviet_bloke
Wed Nov 15 16:47:32 CST 2006

> I have written a driver for a proprietary network card (which is not a
> standard NIC card). This is a monolithic driver and it neither does
> register itself as a NDIS driver nor does it communicate with NDIS
> stack.

Could you please explain the above???? Let's face it - if your driver
does not deal with NDIS, from the system's perspective, it may qualify
for being anything but NIC driver.....

Anton Bassov

srii...@hotmail.com wrote:
> Hello,
>
> I have written a driver for a proprietary network card (which is not a
> standard NIC card). This is a monolithic driver and it neither does
> register itself as a NDIS driver nor does it communicate with NDIS
> stack.
>
> Now, the question is this ? What should I do to display my network
> adapter in 'Network Connections' (in the control panel) ? Should it
> necessarily be registered as a NDIS driver or is there any other
> solution for this ?
>
> I need this because I have a generic application that gets the list of
> network adapters from Network Connections in the Control Panel, and
> communicates with them.
>
> Thanks,
> Srivi.

Thomas
Wed Nov 15 16:45:23 CST 2006

You would have to glue your driver into the NDIS miniport architecture for
it to appear as a network adapter to the system.

Your alternative is to modify your generic application to detect your
"network" card through some private mechanism and include your card along
with real NDIS miniports...

Thomas F. Divine
http://www.rawether.net

<sriivii@hotmail.com> wrote in message
news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
> Hello,
>
> I have written a driver for a proprietary network card (which is not a
> standard NIC card). This is a monolithic driver and it neither does
> register itself as a NDIS driver nor does it communicate with NDIS
> stack.
>
> Now, the question is this ? What should I do to display my network
> adapter in 'Network Connections' (in the control panel) ? Should it
> necessarily be registered as a NDIS driver or is there any other
> solution for this ?
>
> I need this because I have a generic application that gets the list of
> network adapters from Network Connections in the Control Panel, and
> communicates with them.
>
> Thanks,
> Srivi.
>

sriivii
Wed Nov 15 17:04:08 CST 2006

I was just wondering if I could make the adapter appear in 'Network
connection' just by creating some registry keys or something of that
sort.


Thomas F. Divine [MVP] wrote:
> You would have to glue your driver into the NDIS miniport architecture for
> it to appear as a network adapter to the system.
>
> Your alternative is to modify your generic application to detect your
> "network" card through some private mechanism and include your card along
> with real NDIS miniports...
>
> Thomas F. Divine
> http://www.rawether.net
>
> <sriivii@hotmail.com> wrote in message
> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
> > Hello,
> >
> > I have written a driver for a proprietary network card (which is not a
> > standard NIC card). This is a monolithic driver and it neither does
> > register itself as a NDIS driver nor does it communicate with NDIS
> > stack.
> >
> > Now, the question is this ? What should I do to display my network
> > adapter in 'Network Connections' (in the control panel) ? Should it
> > necessarily be registered as a NDIS driver or is there any other
> > solution for this ?
> >
> > I need this because I have a generic application that gets the list of
> > network adapters from Network Connections in the Control Panel, and
> > communicates with them.
> >
> > Thanks,
> > Srivi.
> >

Thomas
Wed Nov 15 17:17:23 CST 2006

No, trying that would really hose the system. NDIS has it's own enumerator
and installer. A ton of APIs would probably break. It would be a nightmare.

Thos

<sriivii@hotmail.com> wrote in message
news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
>I was just wondering if I could make the adapter appear in 'Network
> connection' just by creating some registry keys or something of that
> sort.
>
>
> Thomas F. Divine [MVP] wrote:
>> You would have to glue your driver into the NDIS miniport architecture
>> for
>> it to appear as a network adapter to the system.
>>
>> Your alternative is to modify your generic application to detect your
>> "network" card through some private mechanism and include your card along
>> with real NDIS miniports...
>>
>> Thomas F. Divine
>> http://www.rawether.net
>>
>> <sriivii@hotmail.com> wrote in message
>> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
>> > Hello,
>> >
>> > I have written a driver for a proprietary network card (which is not a
>> > standard NIC card). This is a monolithic driver and it neither does
>> > register itself as a NDIS driver nor does it communicate with NDIS
>> > stack.
>> >
>> > Now, the question is this ? What should I do to display my network
>> > adapter in 'Network Connections' (in the control panel) ? Should it
>> > necessarily be registered as a NDIS driver or is there any other
>> > solution for this ?
>> >
>> > I need this because I have a generic application that gets the list of
>> > network adapters from Network Connections in the Control Panel, and
>> > communicates with them.
>> >
>> > Thanks,
>> > Srivi.
>> >
>

soviet_bloke
Wed Nov 15 19:15:54 CST 2006

Thomas,

Please look at the statement that the OP made in his original post:

[begin quote]

I need this because I have a generic application that gets the list of
network adapters from Network Connections in the Control Panel, and
communicates with them

[end quote]

I just wonder how the OP sees the possibility of "communication"
between this generic application and his "network adapter"......

OK, he can trick this app into believing that it deals with a network
adapter if he adds support for the appropriate OIDs in his Dispatch()
routine (in order to make it look more real, he can even assign a
symbolic link in the form "\\Device\\{GUID}" to it), but what is he
going to do when it comes to actually communicating with this "adapter"
in some way, other than DeviceIoControl() ???? Once his "adapter" does
not provide support for NDIS, this application
would be unable to use anything that somehow involves protocol drivers
(for example, to use Winsock or NetBios with it), and, apparently, it
would be unable to send WMI queries to his "adapter" either.


Therefore, the only thing the OP can do is to write a custom, rather
than generic, application that communicates with this "adapter" only
via ReadFile()/WriteFile()/DeviceIoControl() calls, and, at this point,
the very term "network adapter" becomes just inappropriate in relation
to his driver.

Anton Bassov

Thomas F. Divine [MVP] wrote:
> No, trying that would really hose the system. NDIS has it's own enumerator
> and installer. A ton of APIs would probably break. It would be a nightmare.
>
> Thos
>
> <sriivii@hotmail.com> wrote in message
> news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
> >I was just wondering if I could make the adapter appear in 'Network
> > connection' just by creating some registry keys or something of that
> > sort.
> >
> >
> > Thomas F. Divine [MVP] wrote:
> >> You would have to glue your driver into the NDIS miniport architecture
> >> for
> >> it to appear as a network adapter to the system.
> >>
> >> Your alternative is to modify your generic application to detect your
> >> "network" card through some private mechanism and include your card along
> >> with real NDIS miniports...
> >>
> >> Thomas F. Divine
> >> http://www.rawether.net
> >>
> >> <sriivii@hotmail.com> wrote in message
> >> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
> >> > Hello,
> >> >
> >> > I have written a driver for a proprietary network card (which is not a
> >> > standard NIC card). This is a monolithic driver and it neither does
> >> > register itself as a NDIS driver nor does it communicate with NDIS
> >> > stack.
> >> >
> >> > Now, the question is this ? What should I do to display my network
> >> > adapter in 'Network Connections' (in the control panel) ? Should it
> >> > necessarily be registered as a NDIS driver or is there any other
> >> > solution for this ?
> >> >
> >> > I need this because I have a generic application that gets the list of
> >> > network adapters from Network Connections in the Control Panel, and
> >> > communicates with them.
> >> >
> >> > Thanks,
> >> > Srivi.
> >> >
> >

sriivii
Wed Nov 15 21:57:13 CST 2006

The purpose it to keep the application still generic and to use the
customised API which works both for NIC and non-NIC cards.

soviet_bloke@hotmail.com wrote:
> Thomas,
>
> Please look at the statement that the OP made in his original post:
>
> [begin quote]
>
> I need this because I have a generic application that gets the list of
> network adapters from Network Connections in the Control Panel, and
> communicates with them
>
> [end quote]
>
> I just wonder how the OP sees the possibility of "communication"
> between this generic application and his "network adapter"......
>
> OK, he can trick this app into believing that it deals with a network
> adapter if he adds support for the appropriate OIDs in his Dispatch()
> routine (in order to make it look more real, he can even assign a
> symbolic link in the form "\\Device\\{GUID}" to it), but what is he
> going to do when it comes to actually communicating with this "adapter"
> in some way, other than DeviceIoControl() ???? Once his "adapter" does
> not provide support for NDIS, this application
> would be unable to use anything that somehow involves protocol drivers
> (for example, to use Winsock or NetBios with it), and, apparently, it
> would be unable to send WMI queries to his "adapter" either.
>
>
> Therefore, the only thing the OP can do is to write a custom, rather
> than generic, application that communicates with this "adapter" only
> via ReadFile()/WriteFile()/DeviceIoControl() calls, and, at this point,
> the very term "network adapter" becomes just inappropriate in relation
> to his driver.
>
> Anton Bassov
>
> Thomas F. Divine [MVP] wrote:
> > No, trying that would really hose the system. NDIS has it's own enumerator
> > and installer. A ton of APIs would probably break. It would be a nightmare.
> >
> > Thos
> >
> > <sriivii@hotmail.com> wrote in message
> > news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
> > >I was just wondering if I could make the adapter appear in 'Network
> > > connection' just by creating some registry keys or something of that
> > > sort.
> > >
> > >
> > > Thomas F. Divine [MVP] wrote:
> > >> You would have to glue your driver into the NDIS miniport architecture
> > >> for
> > >> it to appear as a network adapter to the system.
> > >>
> > >> Your alternative is to modify your generic application to detect your
> > >> "network" card through some private mechanism and include your card along
> > >> with real NDIS miniports...
> > >>
> > >> Thomas F. Divine
> > >> http://www.rawether.net
> > >>
> > >> <sriivii@hotmail.com> wrote in message
> > >> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
> > >> > Hello,
> > >> >
> > >> > I have written a driver for a proprietary network card (which is not a
> > >> > standard NIC card). This is a monolithic driver and it neither does
> > >> > register itself as a NDIS driver nor does it communicate with NDIS
> > >> > stack.
> > >> >
> > >> > Now, the question is this ? What should I do to display my network
> > >> > adapter in 'Network Connections' (in the control panel) ? Should it
> > >> > necessarily be registered as a NDIS driver or is there any other
> > >> > solution for this ?
> > >> >
> > >> > I need this because I have a generic application that gets the list of
> > >> > network adapters from Network Connections in the Control Panel, and
> > >> > communicates with them.
> > >> >
> > >> > Thanks,
> > >> > Srivi.
> > >> >
> > >

sriivii
Wed Nov 15 21:57:26 CST 2006

The purpose it to keep the application still generic and to use the
customised API which works both for NIC and non-NIC cards.

Btw, what is OP ?!

soviet_bloke@hotmail.com wrote:
> Thomas,
>
> Please look at the statement that the OP made in his original post:
>
> [begin quote]
>
> I need this because I have a generic application that gets the list of
> network adapters from Network Connections in the Control Panel, and
> communicates with them
>
> [end quote]
>
> I just wonder how the OP sees the possibility of "communication"
> between this generic application and his "network adapter"......
>
> OK, he can trick this app into believing that it deals with a network
> adapter if he adds support for the appropriate OIDs in his Dispatch()
> routine (in order to make it look more real, he can even assign a
> symbolic link in the form "\\Device\\{GUID}" to it), but what is he
> going to do when it comes to actually communicating with this "adapter"
> in some way, other than DeviceIoControl() ???? Once his "adapter" does
> not provide support for NDIS, this application
> would be unable to use anything that somehow involves protocol drivers
> (for example, to use Winsock or NetBios with it), and, apparently, it
> would be unable to send WMI queries to his "adapter" either.
>
>
> Therefore, the only thing the OP can do is to write a custom, rather
> than generic, application that communicates with this "adapter" only
> via ReadFile()/WriteFile()/DeviceIoControl() calls, and, at this point,
> the very term "network adapter" becomes just inappropriate in relation
> to his driver.
>
> Anton Bassov
>
> Thomas F. Divine [MVP] wrote:
> > No, trying that would really hose the system. NDIS has it's own enumerator
> > and installer. A ton of APIs would probably break. It would be a nightmare.
> >
> > Thos
> >
> > <sriivii@hotmail.com> wrote in message
> > news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
> > >I was just wondering if I could make the adapter appear in 'Network
> > > connection' just by creating some registry keys or something of that
> > > sort.
> > >
> > >
> > > Thomas F. Divine [MVP] wrote:
> > >> You would have to glue your driver into the NDIS miniport architecture
> > >> for
> > >> it to appear as a network adapter to the system.
> > >>
> > >> Your alternative is to modify your generic application to detect your
> > >> "network" card through some private mechanism and include your card along
> > >> with real NDIS miniports...
> > >>
> > >> Thomas F. Divine
> > >> http://www.rawether.net
> > >>
> > >> <sriivii@hotmail.com> wrote in message
> > >> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
> > >> > Hello,
> > >> >
> > >> > I have written a driver for a proprietary network card (which is not a
> > >> > standard NIC card). This is a monolithic driver and it neither does
> > >> > register itself as a NDIS driver nor does it communicate with NDIS
> > >> > stack.
> > >> >
> > >> > Now, the question is this ? What should I do to display my network
> > >> > adapter in 'Network Connections' (in the control panel) ? Should it
> > >> > necessarily be registered as a NDIS driver or is there any other
> > >> > solution for this ?
> > >> >
> > >> > I need this because I have a generic application that gets the list of
> > >> > network adapters from Network Connections in the Control Panel, and
> > >> > communicates with them.
> > >> >
> > >> > Thanks,
> > >> > Srivi.
> > >> >
> > >

Thomas
Wed Nov 15 22:13:44 CST 2006

"OP" is "original poster".

That would be sriivii.

Thomas

<sriivii@hotmail.com> wrote in message
news:1163649446.790825.203510@m73g2000cwd.googlegroups.com...
> The purpose it to keep the application still generic and to use the
> customised API which works both for NIC and non-NIC cards.
>
> Btw, what is OP ?!
>
> soviet_bloke@hotmail.com wrote:
>> Thomas,
>>
>> Please look at the statement that the OP made in his original post:
>>
>> [begin quote]
>>
>> I need this because I have a generic application that gets the list of
>> network adapters from Network Connections in the Control Panel, and
>> communicates with them
>>
>> [end quote]
>>
>> I just wonder how the OP sees the possibility of "communication"
>> between this generic application and his "network adapter"......
>>
>> OK, he can trick this app into believing that it deals with a network
>> adapter if he adds support for the appropriate OIDs in his Dispatch()
>> routine (in order to make it look more real, he can even assign a
>> symbolic link in the form "\\Device\\{GUID}" to it), but what is he
>> going to do when it comes to actually communicating with this "adapter"
>> in some way, other than DeviceIoControl() ???? Once his "adapter" does
>> not provide support for NDIS, this application
>> would be unable to use anything that somehow involves protocol drivers
>> (for example, to use Winsock or NetBios with it), and, apparently, it
>> would be unable to send WMI queries to his "adapter" either.
>>
>>
>> Therefore, the only thing the OP can do is to write a custom, rather
>> than generic, application that communicates with this "adapter" only
>> via ReadFile()/WriteFile()/DeviceIoControl() calls, and, at this point,
>> the very term "network adapter" becomes just inappropriate in relation
>> to his driver.
>>
>> Anton Bassov
>>
>> Thomas F. Divine [MVP] wrote:
>> > No, trying that would really hose the system. NDIS has it's own
>> > enumerator
>> > and installer. A ton of APIs would probably break. It would be a
>> > nightmare.
>> >
>> > Thos
>> >
>> > <sriivii@hotmail.com> wrote in message
>> > news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
>> > >I was just wondering if I could make the adapter appear in 'Network
>> > > connection' just by creating some registry keys or something of that
>> > > sort.
>> > >
>> > >
>> > > Thomas F. Divine [MVP] wrote:
>> > >> You would have to glue your driver into the NDIS miniport
>> > >> architecture
>> > >> for
>> > >> it to appear as a network adapter to the system.
>> > >>
>> > >> Your alternative is to modify your generic application to detect
>> > >> your
>> > >> "network" card through some private mechanism and include your card
>> > >> along
>> > >> with real NDIS miniports...
>> > >>
>> > >> Thomas F. Divine
>> > >> http://www.rawether.net
>> > >>
>> > >> <sriivii@hotmail.com> wrote in message
>> > >> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
>> > >> > Hello,
>> > >> >
>> > >> > I have written a driver for a proprietary network card (which is
>> > >> > not a
>> > >> > standard NIC card). This is a monolithic driver and it neither
>> > >> > does
>> > >> > register itself as a NDIS driver nor does it communicate with NDIS
>> > >> > stack.
>> > >> >
>> > >> > Now, the question is this ? What should I do to display my network
>> > >> > adapter in 'Network Connections' (in the control panel) ? Should
>> > >> > it
>> > >> > necessarily be registered as a NDIS driver or is there any other
>> > >> > solution for this ?
>> > >> >
>> > >> > I need this because I have a generic application that gets the
>> > >> > list of
>> > >> > network adapters from Network Connections in the Control Panel,
>> > >> > and
>> > >> > communicates with them.
>> > >> >
>> > >> > Thanks,
>> > >> > Srivi.
>> > >> >
>> > >
>

soviet_bloke
Wed Nov 15 23:57:21 CST 2006

> The purpose it to keep the application still generic and to use the
> customised API which works both for NIC and non-NIC cards.


NIC stands for 'Network Interface Card" , so that, apparently, by " NIC
and non-NIC cards"
you meant NDIS-compliant and NDIS-non-compliant network cards (in fact,
I've never heard about the latter type - you are, probably, the first
person in the world to introduce the one).
In actuality, the purpose of NDIS is to provide a standard network
interface, so that protocol drivers can seamlessly communicate with
network adapters, although both protocol drivers and network adapters
may be supplied by various vendors.


Therefore, in most cases designing NDIS-non-compliant network card is
among those things that just defeat the common sense. The only
*THEORETICALLY* possible exception to the rule is the situation when
you need something really, really custom (including a client
application). To be honest, I just cannot imagine the situation when
you may need something like that - as Thomas has already explained it
to you, the most reasonable thing to do is just to add NDIS support to
your driver



However, if you need just "customised API"...... well, then this is a
bit different story, but you have to stop thinking of your driver as of
network adapter - let the system think of it as
of anything but NIC (and, indeed, this is what it is, from the system's
perspective). Instead of fooling the whole system, you can limit
yourself to fooling the target application - for the purpose of your
task it will work just fine




What you can do is just to hook Winsock in the address space of your
target application, so that you can redirect Winsock calls to your
driver, effectively bypassing the network stack whenever you are
interested in doing it . It sounds easy, but, in actuality, it is not -
if you really want to make your app believe that it deals with the
network stack, you have to implement all protocol-related details
yourself (it can be done either by your hooking code or by your
driver). In the extreme case, you may be required to implement the
whole functionality of TCPIP.SYS. Do you really need it????


To summarize, I would advise you to think it over again - as Thomas has
already told you, the best thing to do is to add NDIS support to your
driver. This is how you are supposed to do things


Anton Bassov


sriivii@hotmail.com wrote:
> The purpose it to keep the application still generic and to use the
> customised API which works both for NIC and non-NIC cards.
>
> soviet_bloke@hotmail.com wrote:
> > Thomas,
> >
> > Please look at the statement that the OP made in his original post:
> >
> > [begin quote]
> >
> > I need this because I have a generic application that gets the list of
> > network adapters from Network Connections in the Control Panel, and
> > communicates with them
> >
> > [end quote]
> >
> > I just wonder how the OP sees the possibility of "communication"
> > between this generic application and his "network adapter"......
> >
> > OK, he can trick this app into believing that it deals with a network
> > adapter if he adds support for the appropriate OIDs in his Dispatch()
> > routine (in order to make it look more real, he can even assign a
> > symbolic link in the form "\\Device\\{GUID}" to it), but what is he
> > going to do when it comes to actually communicating with this "adapter"
> > in some way, other than DeviceIoControl() ???? Once his "adapter" does
> > not provide support for NDIS, this application
> > would be unable to use anything that somehow involves protocol drivers
> > (for example, to use Winsock or NetBios with it), and, apparently, it
> > would be unable to send WMI queries to his "adapter" either.
> >
> >
> > Therefore, the only thing the OP can do is to write a custom, rather
> > than generic, application that communicates with this "adapter" only
> > via ReadFile()/WriteFile()/DeviceIoControl() calls, and, at this point,
> > the very term "network adapter" becomes just inappropriate in relation
> > to his driver.
> >
> > Anton Bassov
> >
> > Thomas F. Divine [MVP] wrote:
> > > No, trying that would really hose the system. NDIS has it's own enumerator
> > > and installer. A ton of APIs would probably break. It would be a nightmare.
> > >
> > > Thos
> > >
> > > <sriivii@hotmail.com> wrote in message
> > > news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
> > > >I was just wondering if I could make the adapter appear in 'Network
> > > > connection' just by creating some registry keys or something of that
> > > > sort.
> > > >
> > > >
> > > > Thomas F. Divine [MVP] wrote:
> > > >> You would have to glue your driver into the NDIS miniport architecture
> > > >> for
> > > >> it to appear as a network adapter to the system.
> > > >>
> > > >> Your alternative is to modify your generic application to detect your
> > > >> "network" card through some private mechanism and include your card along
> > > >> with real NDIS miniports...
> > > >>
> > > >> Thomas F. Divine
> > > >> http://www.rawether.net
> > > >>
> > > >> <sriivii@hotmail.com> wrote in message
> > > >> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
> > > >> > Hello,
> > > >> >
> > > >> > I have written a driver for a proprietary network card (which is not a
> > > >> > standard NIC card). This is a monolithic driver and it neither does
> > > >> > register itself as a NDIS driver nor does it communicate with NDIS
> > > >> > stack.
> > > >> >
> > > >> > Now, the question is this ? What should I do to display my network
> > > >> > adapter in 'Network Connections' (in the control panel) ? Should it
> > > >> > necessarily be registered as a NDIS driver or is there any other
> > > >> > solution for this ?
> > > >> >
> > > >> > I need this because I have a generic application that gets the list of
> > > >> > network adapters from Network Connections in the Control Panel, and
> > > >> > communicates with them.
> > > >> >
> > > >> > Thanks,
> > > >> > Srivi.
> > > >> >
> > > >

Thomas
Thu Nov 16 00:48:55 CST 2006


<soviet_bloke@hotmail.com> wrote in message
news:1163656641.818182.107280@m7g2000cwm.googlegroups.com...
>> The purpose it to keep the application still generic and to use the
>> customised API which works both for NIC and non-NIC cards.
>
>
> NIC stands for 'Network Interface Card" , so that, apparently, by " NIC
> and non-NIC cards"
> you meant NDIS-compliant and NDIS-non-compliant network cards (in fact,
> I've never heard about the latter type - you are, probably, the first
> person in the world to introduce the one).

Actually, the WDK includes an interesting example on a non-NDIS network
driver. It is the KMDF "PCIDRV" sample driver. It is a WDM (non-NDIS) driver
for the Intel 82557/82558 based PCI Ethernet Adapter (10/100) and Intel
compatibles.

Very educational sample, IMHO.

No, it doesn't appear in the Network Control Panel.

The WDK "NDISEDGE" sample shows how to glue PCIDRV into the NDIS framework.

I personally wouldn't follow this model for production purposes, but it does
illustrate useful techniques.

I think that the OP should simply take his existing driver and adapt it to
be a true NDIS miniport...

Thomas


> In actuality, the purpose of NDIS is to provide a standard network
> interface, so that protocol drivers can seamlessly communicate with
> network adapters, although both protocol drivers and network adapters
> may be supplied by various vendors.
>
>
> Therefore, in most cases designing NDIS-non-compliant network card is
> among those things that just defeat the common sense. The only
> *THEORETICALLY* possible exception to the rule is the situation when
> you need something really, really custom (including a client
> application). To be honest, I just cannot imagine the situation when
> you may need something like that - as Thomas has already explained it
> to you, the most reasonable thing to do is just to add NDIS support to
> your driver
>
>
>
> However, if you need just "customised API"...... well, then this is a
> bit different story, but you have to stop thinking of your driver as of
> network adapter - let the system think of it as
> of anything but NIC (and, indeed, this is what it is, from the system's
> perspective). Instead of fooling the whole system, you can limit
> yourself to fooling the target application - for the purpose of your
> task it will work just fine
>
>
>
>
> What you can do is just to hook Winsock in the address space of your
> target application, so that you can redirect Winsock calls to your
> driver, effectively bypassing the network stack whenever you are
> interested in doing it . It sounds easy, but, in actuality, it is not -
> if you really want to make your app believe that it deals with the
> network stack, you have to implement all protocol-related details
> yourself (it can be done either by your hooking code or by your
> driver). In the extreme case, you may be required to implement the
> whole functionality of TCPIP.SYS. Do you really need it????
>
>
> To summarize, I would advise you to think it over again - as Thomas has
> already told you, the best thing to do is to add NDIS support to your
> driver. This is how you are supposed to do things
>
>
> Anton Bassov
>
>
> sriivii@hotmail.com wrote:
>> The purpose it to keep the application still generic and to use the
>> customised API which works both for NIC and non-NIC cards.
>>
>> soviet_bloke@hotmail.com wrote:
>> > Thomas,
>> >
>> > Please look at the statement that the OP made in his original post:
>> >
>> > [begin quote]
>> >
>> > I need this because I have a generic application that gets the list of
>> > network adapters from Network Connections in the Control Panel, and
>> > communicates with them
>> >
>> > [end quote]
>> >
>> > I just wonder how the OP sees the possibility of "communication"
>> > between this generic application and his "network adapter"......
>> >
>> > OK, he can trick this app into believing that it deals with a network
>> > adapter if he adds support for the appropriate OIDs in his Dispatch()
>> > routine (in order to make it look more real, he can even assign a
>> > symbolic link in the form "\\Device\\{GUID}" to it), but what is he
>> > going to do when it comes to actually communicating with this "adapter"
>> > in some way, other than DeviceIoControl() ???? Once his "adapter" does
>> > not provide support for NDIS, this application
>> > would be unable to use anything that somehow involves protocol drivers
>> > (for example, to use Winsock or NetBios with it), and, apparently, it
>> > would be unable to send WMI queries to his "adapter" either.
>> >
>> >
>> > Therefore, the only thing the OP can do is to write a custom, rather
>> > than generic, application that communicates with this "adapter" only
>> > via ReadFile()/WriteFile()/DeviceIoControl() calls, and, at this point,
>> > the very term "network adapter" becomes just inappropriate in relation
>> > to his driver.
>> >
>> > Anton Bassov
>> >
>> > Thomas F. Divine [MVP] wrote:
>> > > No, trying that would really hose the system. NDIS has it's own
>> > > enumerator
>> > > and installer. A ton of APIs would probably break. It would be a
>> > > nightmare.
>> > >
>> > > Thos
>> > >
>> > > <sriivii@hotmail.com> wrote in message
>> > > news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
>> > > >I was just wondering if I could make the adapter appear in 'Network
>> > > > connection' just by creating some registry keys or something of
>> > > > that
>> > > > sort.
>> > > >
>> > > >
>> > > > Thomas F. Divine [MVP] wrote:
>> > > >> You would have to glue your driver into the NDIS miniport
>> > > >> architecture
>> > > >> for
>> > > >> it to appear as a network adapter to the system.
>> > > >>
>> > > >> Your alternative is to modify your generic application to detect
>> > > >> your
>> > > >> "network" card through some private mechanism and include your
>> > > >> card along
>> > > >> with real NDIS miniports...
>> > > >>
>> > > >> Thomas F. Divine
>> > > >> http://www.rawether.net
>> > > >>
>> > > >> <sriivii@hotmail.com> wrote in message
>> > > >> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
>> > > >> > Hello,
>> > > >> >
>> > > >> > I have written a driver for a proprietary network card (which is
>> > > >> > not a
>> > > >> > standard NIC card). This is a monolithic driver and it neither
>> > > >> > does
>> > > >> > register itself as a NDIS driver nor does it communicate with
>> > > >> > NDIS
>> > > >> > stack.
>> > > >> >
>> > > >> > Now, the question is this ? What should I do to display my
>> > > >> > network
>> > > >> > adapter in 'Network Connections' (in the control panel) ? Should
>> > > >> > it
>> > > >> > necessarily be registered as a NDIS driver or is there any other
>> > > >> > solution for this ?
>> > > >> >
>> > > >> > I need this because I have a generic application that gets the
>> > > >> > list of
>> > > >> > network adapters from Network Connections in the Control Panel,
>> > > >> > and
>> > > >> > communicates with them.
>> > > >> >
>> > > >> > Thanks,
>> > > >> > Srivi.
>> > > >> >
>> > > >
>

soviet_bloke
Thu Nov 16 02:24:58 CST 2006

Thomas,

> Actually, the WDK includes an interesting example on a non-NDIS network
> driver. It is the KMDF "PCIDRV" sample driver. It is a WDM (non-NDIS) driver
> for the Intel 82557/82558 based PCI Ethernet Adapter (10/100) and Intel
> compatibles.
>

As far as I understand, in the end of the day such drivers are still
meant to be indirectly made NDIS-compliant with the help of additional
drivers that expose NDIS interface on their upper edges. I think it
must be quite usefull approach for someone who wants to present some
device (say, USB modem) as NIC. As far as I understand, my ADSL
connection works in more or less similar fashion - I have a modem plus
2 separate drivers( one of them deals with the modem itself, and
another one presents itself as a miniport on its upper edge and deals
with the other driver on its lower one). Actually, the whole thing
appears as a dial-up connection in the Control Panel.


However, if I got it right, the OP wants to do exactly the opposite -
he has a network card, and he wants to make its driver ignore NDIS
altogether, effectively making it unusable by the network stack. This
is why I said that he is, probably, the first person in the world who
wants to introduce such design

Anton Bassov


Thomas F. Divine [MVP] wrote:
> <soviet_bloke@hotmail.com> wrote in message
> news:1163656641.818182.107280@m7g2000cwm.googlegroups.com...
> >> The purpose it to keep the application still generic and to use the
> >> customised API which works both for NIC and non-NIC cards.
> >
> >
> > NIC stands for 'Network Interface Card" , so that, apparently, by " NIC
> > and non-NIC cards"
> > you meant NDIS-compliant and NDIS-non-compliant network cards (in fact,
> > I've never heard about the latter type - you are, probably, the first
> > person in the world to introduce the one).
>
> Actually, the WDK includes an interesting example on a non-NDIS network
> driver. It is the KMDF "PCIDRV" sample driver. It is a WDM (non-NDIS) driver
> for the Intel 82557/82558 based PCI Ethernet Adapter (10/100) and Intel
> compatibles.
>
> Very educational sample, IMHO.
>
> No, it doesn't appear in the Network Control Panel.
>
> The WDK "NDISEDGE" sample shows how to glue PCIDRV into the NDIS framework.
>
> I personally wouldn't follow this model for production purposes, but it does
> illustrate useful techniques.
>
> I think that the OP should simply take his existing driver and adapt it to
> be a true NDIS miniport...
>
> Thomas
>
>
> > In actuality, the purpose of NDIS is to provide a standard network
> > interface, so that protocol drivers can seamlessly communicate with
> > network adapters, although both protocol drivers and network adapters
> > may be supplied by various vendors.
> >
> >
> > Therefore, in most cases designing NDIS-non-compliant network card is
> > among those things that just defeat the common sense. The only
> > *THEORETICALLY* possible exception to the rule is the situation when
> > you need something really, really custom (including a client
> > application). To be honest, I just cannot imagine the situation when
> > you may need something like that - as Thomas has already explained it
> > to you, the most reasonable thing to do is just to add NDIS support to
> > your driver
> >
> >
> >
> > However, if you need just "customised API"...... well, then this is a
> > bit different story, but you have to stop thinking of your driver as of
> > network adapter - let the system think of it as
> > of anything but NIC (and, indeed, this is what it is, from the system's
> > perspective). Instead of fooling the whole system, you can limit
> > yourself to fooling the target application - for the purpose of your
> > task it will work just fine
> >
> >
> >
> >
> > What you can do is just to hook Winsock in the address space of your
> > target application, so that you can redirect Winsock calls to your
> > driver, effectively bypassing the network stack whenever you are
> > interested in doing it . It sounds easy, but, in actuality, it is not -
> > if you really want to make your app believe that it deals with the
> > network stack, you have to implement all protocol-related details
> > yourself (it can be done either by your hooking code or by your
> > driver). In the extreme case, you may be required to implement the
> > whole functionality of TCPIP.SYS. Do you really need it????
> >
> >
> > To summarize, I would advise you to think it over again - as Thomas has
> > already told you, the best thing to do is to add NDIS support to your
> > driver. This is how you are supposed to do things
> >
> >
> > Anton Bassov
> >
> >
> > sriivii@hotmail.com wrote:
> >> The purpose it to keep the application still generic and to use the
> >> customised API which works both for NIC and non-NIC cards.
> >>
> >> soviet_bloke@hotmail.com wrote:
> >> > Thomas,
> >> >
> >> > Please look at the statement that the OP made in his original post:
> >> >
> >> > [begin quote]
> >> >
> >> > I need this because I have a generic application that gets the list of
> >> > network adapters from Network Connections in the Control Panel, and
> >> > communicates with them
> >> >
> >> > [end quote]
> >> >
> >> > I just wonder how the OP sees the possibility of "communication"
> >> > between this generic application and his "network adapter"......
> >> >
> >> > OK, he can trick this app into believing that it deals with a network
> >> > adapter if he adds support for the appropriate OIDs in his Dispatch()
> >> > routine (in order to make it look more real, he can even assign a
> >> > symbolic link in the form "\\Device\\{GUID}" to it), but what is he
> >> > going to do when it comes to actually communicating with this "adapter"
> >> > in some way, other than DeviceIoControl() ???? Once his "adapter" does
> >> > not provide support for NDIS, this application
> >> > would be unable to use anything that somehow involves protocol drivers
> >> > (for example, to use Winsock or NetBios with it), and, apparently, it
> >> > would be unable to send WMI queries to his "adapter" either.
> >> >
> >> >
> >> > Therefore, the only thing the OP can do is to write a custom, rather
> >> > than generic, application that communicates with this "adapter" only
> >> > via ReadFile()/WriteFile()/DeviceIoControl() calls, and, at this point,
> >> > the very term "network adapter" becomes just inappropriate in relation
> >> > to his driver.
> >> >
> >> > Anton Bassov
> >> >
> >> > Thomas F. Divine [MVP] wrote:
> >> > > No, trying that would really hose the system. NDIS has it's own
> >> > > enumerator
> >> > > and installer. A ton of APIs would probably break. It would be a
> >> > > nightmare.
> >> > >
> >> > > Thos
> >> > >
> >> > > <sriivii@hotmail.com> wrote in message
> >> > > news:1163631848.751423.276600@h54g2000cwb.googlegroups.com...
> >> > > >I was just wondering if I could make the adapter appear in 'Network
> >> > > > connection' just by creating some registry keys or something of
> >> > > > that
> >> > > > sort.
> >> > > >
> >> > > >
> >> > > > Thomas F. Divine [MVP] wrote:
> >> > > >> You would have to glue your driver into the NDIS miniport
> >> > > >> architecture
> >> > > >> for
> >> > > >> it to appear as a network adapter to the system.
> >> > > >>
> >> > > >> Your alternative is to modify your generic application to detect
> >> > > >> your
> >> > > >> "network" card through some private mechanism and include your
> >> > > >> card along
> >> > > >> with real NDIS miniports...
> >> > > >>
> >> > > >> Thomas F. Divine
> >> > > >> http://www.rawether.net
> >> > > >>
> >> > > >> <sriivii@hotmail.com> wrote in message
> >> > > >> news:1163630206.967824.168880@h54g2000cwb.googlegroups.com...
> >> > > >> > Hello,
> >> > > >> >
> >> > > >> > I have written a driver for a proprietary network card (which is
> >> > > >> > not a
> >> > > >> > standard NIC card). This is a monolithic driver and it neither
> >> > > >> > does
> >> > > >> > register itself as a NDIS driver nor does it communicate with
> >> > > >> > NDIS
> >> > > >> > stack.
> >> > > >> >
> >> > > >> > Now, the question is this ? What should I do to display my
> >> > > >> > network
> >> > > >> > adapter in 'Network Connections' (in the control panel) ? Should
> >> > > >> > it
> >> > > >> > necessarily be registered as a NDIS driver or is there any other
> >> > > >> > solution for this ?
> >> > > >> >
> >> > > >> > I need this because I have a generic application that gets the
> >> > > >> > list of
> >> > > >> > network adapters from Network Connections in the Control Panel,
> >> > > >> > and
> >> > > >> > communicates with them.
> >> > > >> >
> >> > > >> > Thanks,
> >> > > >> > Srivi.
> >> > > >> >
> >> > > >
> >

Stephan
Thu Nov 16 08:57:16 CST 2006

Sure the OP could write some virtual NDIS miniport, whose only purpose
is to "represent" a (virtual) NIC in the system. So his app. would find
this virtual NIC. The virtual miniport and the OP's non-NDIS drive
could communicate using e.g. IOCTLs (similar to NDISWDM I guess).

Not sure however whether this really makes any sense at all.

Stephan

soviet_bloke
Thu Nov 16 14:00:08 CST 2006

Stephan,

> Sure the OP could write some virtual NDIS miniport, whose only purpose
> is to "represent" a (virtual) NIC in the system. So his app. would find
> this virtual NIC. The virtual miniport and the OP's non-NDIS drive
> could communicate using e.g. IOCTLs (similar to NDISWDM I guess).
>
> Not sure however whether this really makes any sense at all.

I would say that, in the OP's particular situation, it just does not
make sense to do it - after all, such approach gives you an additional
overhead because of IO Manager's involvement,
so that it makes sense to use it only if you want to add NDIS support
to some device, provided by some third party, i.e. its actual
(non-NDIS) driver has already been written.


However, the OP writes a driver for his own physical network card.
Therefore, as Thomas has already pointed out, the most reasonable
approach in this situation is just to add NDIS
support to the original driver.


In fact, I think the reason why the OP wants to do things in rather
unconventional (and unreasonable) way is just trivial - apparently,
once NDIS has never had a reputation for being easy to learn and
implement, he just does not want to deal with it


Anton Bassov


Stephan Wolf [MVP] wrote:
> Sure the OP could write some virtual NDIS miniport, whose only purpose
> is to "represent" a (virtual) NIC in the system. So his app. would find
> this virtual NIC. The virtual miniport and the OP's non-NDIS drive
> could communicate using e.g. IOCTLs (similar to NDISWDM I guess).
>
> Not sure however whether this really makes any sense at all.
>
> Stephan

Stephan
Fri Nov 17 02:59:13 CST 2006

soviet_bloke@hotmail.com wrote:
[..]
> - apparently,
> once NDIS has never had a reputation for being easy to learn and
> implement,

Well, I have always been wondering about this myth.

IMHO, NDIS is much easier to learn and understand than Windows drivers
in general. Much because NDIS is a world of its own and its design is
btw platform independent. That's the (historic) reason why one should
not call any non-NDIS functions in an NDIS miniport. In theory, a
properly written NDIS miniport would recompile and run on just any
hardware and/or OS platform. May I cite the Linux ndiswrapper project
as evidence.

Stephan

soviet_bloke
Fri Nov 17 10:41:21 CST 2006

Stephan,


> > - apparently,
> > once NDIS has never had a reputation for being easy to learn and
> > implement,
>
> Well, I have always been wondering about this myth.

This belief directly results from the fact that NDIS is, probably, the
most poorly documented part of DDK. For example, look at
NdisGetReceivedPacket() documentation -MSDN tells you that
NdisGetReceivedPacket() retrieves a packet that was received from the
underlying driver, and that's it. Can you see any mentioning of NULL as
of its return value, let alone any explanation as to why it may happen
( it happens when underlying miniport relies upon media-specific
indication, for example, NdisMEthIndicateReceive(), rather than upon
NdisMIndicateReceivePacket())??? Therefore, you may be quite surprized
to find out that, for no apparent reason, your protocol is unable to
retrieve a packet that was indicated to it.....


> NDIS is much easier to learn and understand than Windows drivers
> in general.

Actually, this is true - ndis.h alone seems to be quite informative
source. However, be carefull....

You are not supposed to use all these structures directly - instead,
you are supposed just to pass opaque NDIS_HANDLES to all NDIS functions
and macros. The immediate consequence is that all declarations are
accurate enough to make these macros work.... but nothing more than
that. After some experimentation and disasssembly you are going to
realize that NDIS_OPEN_BLOCK is, in actuality, much bigger than its
declaration in ndis.h, as well as that its 'AdapterHandle' points to
NDIS_MINIPORT_BLOCK and not to NDIS_ADAPTER_BLOCK as ndis.h
suggests......

>In theory, a
> properly written NDIS miniport would recompile and run on just any
> hardware and/or OS platform.

In practice, however, it may well happen that your NDIS IM works fine
with adapter X and fails on adapter Y for no apparent reason......


As you can see, NDIS has quite a few pitfalls, so that the popular
belief about its complexity is not that unfounded

Anton Bassov


Stephan Wolf [MVP] wrote:
> soviet_bloke@hotmail.com wrote:
> [..]
> > - apparently,
> > once NDIS has never had a reputation for being easy to learn and
> > implement,
>
> Well, I have always been wondering about this myth.
>
> IMHO, NDIS is much easier to learn and understand than Windows drivers
> in general. Much because NDIS is a world of its own and its design is
> btw platform independent. That's the (historic) reason why one should
> not call any non-NDIS functions in an NDIS miniport. In theory, a
> properly written NDIS miniport would recompile and run on just any
> hardware and/or OS platform. May I cite the Linux ndiswrapper project
> as evidence.
>
> Stephan