Dynamically loading an NDIS intermediate filter driver

Is it possible to load an NDIS intermediate filter driver dynamically
using OpenService, StartService etc.? I can load and unload the driver using
the above mentioned methods but I can not get the bindings to work. Is there
a way to setup these bindings dynamically without using the .inf install
route?

Regards,
jacques

Jacques,

You can dynamically manipulate the bindings of network components with code
similar to the BindView sample in the DDK.

I think you will find, however, that the Net class installer (NetCfg) will
essentially require that an IM driver be installed via a pair of INF files.
The process of ‘stacking’ IM filter drivers in a predetermined order and
ensuring exclusive bindings at the Protocol edge are all handled by NetCfg.

The INF install process for an NDIS IM driver is pretty straight forward.
What part of this process is incompatible with your solution?

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jacques Fourie
Sent: Monday, September 19, 2005 5:10 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Dynamically loading an NDIS intermediate filter driver

Is it possible to load an NDIS intermediate filter driver dynamically
using OpenService, StartService etc.? I can load and unload the driver using
the above mentioned methods but I can not get the bindings to work. Is there
a way to setup these bindings dynamically without using the .inf install
route?

Regards,
jacques


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

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

Hi Dave,

Our current solution (a VPN client) uses the INF install process and works
quite well if the user owns the PC on which the software is being installed.
In cases where the user only wants to run the software once a solution that
did not require the INF install path would be more desirable. In theory the
user should only run an executable which then loads the NDIS IM driver and
manages all the bindings. This would obviously require administrative
privileges but still seems a whole lot easier than the current process,
which entails running an install application and rebooting the PC.

Maybe I should ask another question and that is if the reboot step is an
absolute hard requirement when installing NDIS IM drivers the INF way? I may
be doing something wrong in the NDIS IM driver but without rebooting the
install-uninstall cycle is not always working as it should.

regards,
jacques

Obviously there are security implications but requiring administrative
privileges and running an executable still

Jacques,

You can dynamically manipulate the bindings of network components with code
similar to the BindView sample in the DDK.

I think you will find, however, that the Net class installer (NetCfg) will
essentially require that an IM driver be installed via a pair of INF files.
The process of ‘stacking’ IM filter drivers in a predetermined order and
ensuring exclusive bindings at the Protocol edge are all handled by NetCfg.

The INF install process for an NDIS IM driver is pretty straight forward.
What part of this process is incompatible with your solution?

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jacques Fourie
Sent: Monday, September 19, 2005 5:10 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Dynamically loading an NDIS intermediate filter driver

Is it possible to load an NDIS intermediate filter driver dynamically
using OpenService, StartService etc.? I can load and unload the driver using
the above mentioned methods but I can not get the bindings to work. Is there
a way to setup these bindings dynamically without using the .inf install
route?

Regards,
jacques


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

You are currently subscribed to ntdev as: xxxxx@msn.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@trispen.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Jacques,

The reboot requirement is only a ‘requirement’ if the NetCfg returns that
you must reboot. In general I would have to say that no, a reboot should
not generally be required.

A common mistake in an IM driver that exposes an Auxilary Device Object is
to destroy the Auxilary Device Object in the XxxUnload() handler. The
existence of the Auxilary Device Object will cause the reference count of
the driver to be such that XxxUnload will not be called.

Because PnP and NDIS are managing the lifetime of the driver, it is
important to have a way that NDIS or NetCfg can ‘signal’ the driver to
destroy the Auxilary Device Object so that PnP can unload the driver.

One technique is to create the Aux DO when the first virtual miniport is
created and to destroy it after the last virtual miniport is destroyed. I
believe later samples of VMINI and PASSTHRU might have demonstrated this
technique. When NetCfg removes an IM driver (bindings) the virtual
miniports are removed. As with any miniport driver, when the last miniport
is removed, NDIS allows PnP to ‘attempt’ to remove the driver. If any
references to the driver remain, the driver is not unloaded. By removing
the Aux DO while when the last Virtual Miniport is destroyed, the reference
count will be in a state that will allow NDIS and PnP to unload the driver.

FYI: The ProtocolUnload() (or UnloadProtocol()) handler is another
possibility but suffers from a few bugs and other oddities. To get NetCfg
to even cause it to be called when uninstalling the NCF_NDIS_PROTOCOL
characteristic needs to be set. You might find the following thread
interesting as well.

http://groups.google.com/group/microsoft.public.development.device.drivers/b
rowse_thread/thread/4d837556167faa16/50069215885e7cda?lnk=st&q=NDIS++UnloadP
rotocol&rnum=1&hl=en#50069215885e7cda

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: Jacques Fourie [mailto:xxxxx@trispen.com]
Sent: Monday, September 19, 2005 8:17 AM
To: Windows System Software Devs Interest List
Cc: xxxxx@msn.com
Subject: Re: [ntdev] Dynamically loading an NDIS intermediate filter driver

Hi Dave,

Our current solution (a VPN client) uses the INF install process and works
quite well if the user owns the PC on which the software is being installed.
In cases where the user only wants to run the software once a solution that
did not require the INF install path would be more desirable. In theory the
user should only run an executable which then loads the NDIS IM driver and
manages all the bindings. This would obviously require administrative
privileges but still seems a whole lot easier than the current process,
which entails running an install application and rebooting the PC.

Maybe I should ask another question and that is if the reboot step is an
absolute hard requirement when installing NDIS IM drivers the INF way? I may
be doing something wrong in the NDIS IM driver but without rebooting the
install-uninstall cycle is not always working as it should.

regards,
jacques

Obviously there are security implications but requiring administrative
privileges and running an executable still

Jacques,

You can dynamically manipulate the bindings of network components with
code
similar to the BindView sample in the DDK.

I think you will find, however, that the Net class installer (NetCfg) will
essentially require that an IM driver be installed via a pair of INF
files.
The process of ‘stacking’ IM filter drivers in a predetermined order and
ensuring exclusive bindings at the Protocol edge are all handled by
NetCfg.

The INF install process for an NDIS IM driver is pretty straight forward.
What part of this process is incompatible with your solution?

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jacques Fourie
Sent: Monday, September 19, 2005 5:10 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Dynamically loading an NDIS intermediate filter driver

Is it possible to load an NDIS intermediate filter driver dynamically
using OpenService, StartService etc.? I can load and unload the driver
using
the above mentioned methods but I can not get the bindings to work. Is
there
a way to setup these bindings dynamically without using the .inf install
route?

Regards,
jacques


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

You are currently subscribed to ntdev as: xxxxx@msn.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@trispen.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi David, Jacques, everyone,

To add to Jacques question, is there a way to get an Intermediate Filter
driver to load/unload on demand as with a protocol driver through net
start/stop or something similar?

NetCfg installer seem to ignore my SERVICE_DEMAND_START setting for
StartType in the INF files. Even with the SERVICE_DEMAND_START setting
NetCfg automatically loads my Intermediate Filter driver on installation.

Kind regards

Beyers Cronje

PS David, thank you AGAIN for such excellent responses to NDIS questions!

PPS Jacques, you from South Africa ? Nice to see another Afrikaans name on
this list :slight_smile:

On 9/19/05, David R. Cattley wrote:
>
> Jacques,
>
> The reboot requirement is only a ‘requirement’ if the NetCfg returns that
> you must reboot. In general I would have to say that no, a reboot should
> not generally be required.
>
> A common mistake in an IM driver that exposes an Auxilary Device Object is
> to destroy the Auxilary Device Object in the XxxUnload() handler. The
> existence of the Auxilary Device Object will cause the reference count of
> the driver to be such that XxxUnload will not be called.
>
> Because PnP and NDIS are managing the lifetime of the driver, it is
> important to have a way that NDIS or NetCfg can ‘signal’ the driver to
> destroy the Auxilary Device Object so that PnP can unload the driver.
>
> One technique is to create the Aux DO when the first virtual miniport is
> created and to destroy it after the last virtual miniport is destroyed. I
> believe later samples of VMINI and PASSTHRU might have demonstrated this
> technique. When NetCfg removes an IM driver (bindings) the virtual
> miniports are removed. As with any miniport driver, when the last miniport
> is removed, NDIS allows PnP to ‘attempt’ to remove the driver. If any
> references to the driver remain, the driver is not unloaded. By removing
> the Aux DO while when the last Virtual Miniport is destroyed, the
> reference
> count will be in a state that will allow NDIS and PnP to unload the
> driver.
>
> FYI: The ProtocolUnload() (or UnloadProtocol()) handler is another
> possibility but suffers from a few bugs and other oddities. To get NetCfg
> to even cause it to be called when uninstalling the NCF_NDIS_PROTOCOL
> characteristic needs to be set. You might find the following thread
> interesting as well.
>
>
> http://groups.google.com/group/microsoft.public.development.device.drivers/b
>
> rowse_thread/thread/4d837556167faa16/50069215885e7cda?lnk=st&q=NDIS++UnloadP
> rotocol&rnum=1&hl=en#50069215885e7cda
>
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
> -----Original Message-----
> From: Jacques Fourie [mailto:xxxxx@trispen.com]
> Sent: Monday, September 19, 2005 8:17 AM
> To: Windows System Software Devs Interest List
> Cc: xxxxx@msn.com
> Subject: Re: [ntdev] Dynamically loading an NDIS intermediate filter
> driver
>
> Hi Dave,
>
> Our current solution (a VPN client) uses the INF install process and works
> quite well if the user owns the PC on which the software is being
> installed.
> In cases where the user only wants to run the software once a solution
> that
> did not require the INF install path would be more desirable. In theory
> the
> user should only run an executable which then loads the NDIS IM driver and
> manages all the bindings. This would obviously require administrative
> privileges but still seems a whole lot easier than the current process,
> which entails running an install application and rebooting the PC.
>
> Maybe I should ask another question and that is if the reboot step is an
> absolute hard requirement when installing NDIS IM drivers the INF way? I
> may
> be doing something wrong in the NDIS IM driver but without rebooting the
> install-uninstall cycle is not always working as it should.
>
> regards,
> jacques
>
> Obviously there are security implications but requiring administrative
> privileges and running an executable still
> > Jacques,
> >
> > You can dynamically manipulate the bindings of network components with
> code
> > similar to the BindView sample in the DDK.
> >
> > I think you will find, however, that the Net class installer (NetCfg)
> will
> > essentially require that an IM driver be installed via a pair of INF
> files.
> > The process of ‘stacking’ IM filter drivers in a predetermined order and
> > ensuring exclusive bindings at the Protocol edge are all handled by
> NetCfg.
> >
> > The INF install process for an NDIS IM driver is pretty straight
> forward.
> > What part of this process is incompatible with your solution?
> >
> > Good Luck,
> > Dave Cattley
> > Consulting Engineer
> > Systems Software Development
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Jacques Fourie
> > Sent: Monday, September 19, 2005 5:10 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Dynamically loading an NDIS intermediate filter driver
> >
> > Is it possible to load an NDIS intermediate filter driver dynamically
> > using OpenService, StartService etc.? I can load and unload the driver
> using
> > the above mentioned methods but I can not get the bindings to work. Is
> there
> > a way to setup these bindings dynamically without using the .inf install
> > route?
> >
> > Regards,
> > jacques
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@msn.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@trispen.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@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

David,

Thanks for all the info - it really helped in understanding a bit more about
NDIS driver loading / unloading.

regards,
jacques

Jacques,

The reboot requirement is only a ‘requirement’ if the NetCfg returns that
you must reboot. In general I would have to say that no, a reboot should
not generally be required.

A common mistake in an IM driver that exposes an Auxilary Device Object is
to destroy the Auxilary Device Object in the XxxUnload() handler. The
existence of the Auxilary Device Object will cause the reference count of
the driver to be such that XxxUnload will not be called.

Because PnP and NDIS are managing the lifetime of the driver, it is
important to have a way that NDIS or NetCfg can ‘signal’ the driver to
destroy the Auxilary Device Object so that PnP can unload the driver.

One technique is to create the Aux DO when the first virtual miniport is
created and to destroy it after the last virtual miniport is destroyed. I
believe later samples of VMINI and PASSTHRU might have demonstrated this
technique. When NetCfg removes an IM driver (bindings) the virtual
miniports are removed. As with any miniport driver, when the last miniport
is removed, NDIS allows PnP to ‘attempt’ to remove the driver. If any
references to the driver remain, the driver is not unloaded. By removing
the Aux DO while when the last Virtual Miniport is destroyed, the reference
count will be in a state that will allow NDIS and PnP to unload the driver.

FYI: The ProtocolUnload() (or UnloadProtocol()) handler is another
possibility but suffers from a few bugs and other oddities. To get NetCfg
to even cause it to be called when uninstalling the NCF_NDIS_PROTOCOL
characteristic needs to be set. You might find the following thread
interesting as well.

http://groups.google.com/group/microsoft.public.development.device.drivers/b
rowse_thread/thread/4d837556167faa16/50069215885e7cda?lnk=st&q=NDIS++UnloadP
rotocol&rnum=1&hl=en#50069215885e7cda

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: Jacques Fourie [mailto:xxxxx@trispen.com]
Sent: Monday, September 19, 2005 8:17 AM
To: Windows System Software Devs Interest List
Cc: xxxxx@msn.com
Subject: Re: [ntdev] Dynamically loading an NDIS intermediate filter driver

Hi Dave,

Our current solution (a VPN client) uses the INF install process and works
quite well if the user owns the PC on which the software is being installed.
In cases where the user only wants to run the software once a solution that
did not require the INF install path would be more desirable. In theory the
user should only run an executable which then loads the NDIS IM driver and
manages all the bindings. This would obviously require administrative
privileges but still seems a whole lot easier than the current process,
which entails running an install application and rebooting the PC.

Maybe I should ask another question and that is if the reboot step is an
absolute hard requirement when installing NDIS IM drivers the INF way? I may
be doing something wrong in the NDIS IM driver but without rebooting the
install-uninstall cycle is not always working as it should.

regards,
jacques

Obviously there are security implications but requiring administrative
privileges and running an executable still
> Jacques,
>
> You can dynamically manipulate the bindings of network components with
code
> similar to the BindView sample in the DDK.
>
> I think you will find, however, that the Net class installer (NetCfg) will
> essentially require that an IM driver be installed via a pair of INF
files.
> The process of ‘stacking’ IM filter drivers in a predetermined order and
> ensuring exclusive bindings at the Protocol edge are all handled by
NetCfg.
>
> The INF install process for an NDIS IM driver is pretty straight forward.
> What part of this process is incompatible with your solution?
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jacques Fourie
> Sent: Monday, September 19, 2005 5:10 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Dynamically loading an NDIS intermediate filter driver
>
> Is it possible to load an NDIS intermediate filter driver dynamically
> using OpenService, StartService etc.? I can load and unload the driver
using
> the above mentioned methods but I can not get the bindings to work. Is
there
> a way to setup these bindings dynamically without using the .inf install
> route?
>
> Regards,
> jacques
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@msn.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@trispen.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@trispen.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Beyers,

The system is not ignoring the setting of SERVICE_DEMAND_START. The
ConfigMgr (PnP) is ?demanding? that it start because NDIS has enumerated the
virtual miniports created when your IM driver was bound to one or more
network interfaces. If you were to set it toe SERVICE_DISABLED your would
find that the system obeys that value just fine and does not start it!

Perhaps you could look at your requirement from a perspective other than
using the SCM to start/stop the driver.

An NDIS IM driver is a PnP driver. It is viewed by NDIS (and PnP) as the
driver for the virtual miniport(s) created at the ?top? of the filter. The
NDIS protocol ?edge? does *not* behave then exactly like a ?legacy? NDIS
Protocol driver. The driver load lifecycle is managed by NDIS and PnP just
like any other miniport driver.

The NetCfg and specifically the Network Service Class installer create a
virtual miniport for each ?binding? that the protocol edge has and it is the
enumeration of this (these) virtual miniports that cause NDIS to request
that the driver be loaded. It is only this loading process that enables the
DriverEntry to register the Protocol edge and subsequently trigger binding
(to the protocol edge) to occur. When in the process of binding (to a
Miniport at the Protocol edge) the IM driver ?creates? the virtual miniport,
NDIS and PnP complete the process of starting the virtual miniport.

Keep in mind that as long as an IM driver is bound into the logical NetCfg
?stack?, the stack is not started unless the IM driver starts. Put another
way, stopping an IM driver without unbinding it from the NetCfg ?stack?
(interface) renders the entire interface broken! I don?t think that is what
you are trying to do by ?dynamically? loading and unloading your IM driver.
It seems more reasonable to expect you are trying to dynamically insert and
remove your IM filter from the NetCfg ?interface? but still allow the
remaining components to function when your IM driver is ?removed?.

If that is the case you really must remove the binding to remove the IM
filter. As a side-effect of removing the last binding, a properly
implemented IM driver will also stop and unload (because PnP stops and
unloads it).

If you want to install your IM driver in an ?inert? way, simply disable all
of the bindings after install (or create a custom installer DLL to do that).
When you wish to dynamically ?turn it on? use the example code in BindView
to enable the binding.

Good Luck,

Dave Cattley

Consulting Engineer

Systems Software Development

(OT: Beyers & Jacques ? I have had the pleasure of spending three December
holidays with family outside of JNB / Sandton and at CPT. We loved it and
can?t wait to get back for our 4th.)


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Beyers Cronje
Sent: Monday, September 19, 2005 11:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Dynamically loading an NDIS intermediate filter driver

Hi David, Jacques, everyone,

To add to Jacques question, is there a way to get an Intermediate Filter
driver to load/unload on demand as with a protocol driver through net
start/stop or something similar?

NetCfg installer seem to ignore my SERVICE_DEMAND_START setting for
StartType in the INF files. Even with the SERVICE_DEMAND_START setting
NetCfg automatically loads my Intermediate Filter driver on installation.

Kind regards

Beyers Cronje

PS David, thank you AGAIN for such excellent responses to NDIS questions!

PPS Jacques, you from South Africa ? Nice to see another Afrikaans name on
this list :slight_smile: