I have written a miniport driver that works as a virtual adapter for a VPN client. It takes too much time to create and destroy these adapters on the fly using the setup api. What I would like to do have the TCPIP protocol to bind to the adapter when its in use and unbind when the adaper is no longer in use.
My only idea is to bring up the adapter in some state where TCP cannot bind to the adapter. When the adapter is needed, change that state to where TCP/IP could bind and then send a IOCTL_NDIS_REBIND_ADAPTER which would toggle the bind state. When the adapter is no longer needed, revert the state and re-send the IOCTL_NDIS_REBIND_ADAPTER. The problem is I have no idea what state would prevent TCP/IP from binding to an adapter that reports Ethernet Capability.
Does anyone know how to do this or another way to accomplish the same goal?
Thanks,
-Matthew
Matthew,
The answer is still the same. When the adapter is de-enumerated (or
disabled) TCPIP and all other bound protocols will unbind. Again, you do
not want to use NetCfg to ‘unbind’ (or more precisely disable the binding)
because that runs the binding engine. The PnP operation of de-enumerating
or disabling the (virtual) adapter is what you need to perform.
Go look at NdisIMInitializeDeviceInstanceEx() and src\network\ndis\ndiswdm.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shrew.net
Sent: Monday, August 21, 2006 4:29 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Prevent TCPIP from binding to a miniport.
I have written a miniport driver that works as a virtual adapter for a VPN
client. It takes too much time to create and destroy these adapters on the
fly using the setup api. What I would like to do have the TCPIP protocol to
bind to the adapter when its in use and unbind when the adaper is no longer
in use.
My only idea is to bring up the adapter in some state where TCP cannot bind
to the adapter. When the adapter is needed, change that state to where
TCP/IP could bind and then send a IOCTL_NDIS_REBIND_ADAPTER which would
toggle the bind state. When the adapter is no longer needed, revert the
state and re-send the IOCTL_NDIS_REBIND_ADAPTER. The problem is I have no
idea what state would prevent TCP/IP from binding to an adapter that reports
Ethernet Capability.
Does anyone know how to do this or another way to accomplish the same goal?
Thanks,
-Matthew
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Can I call NdisIMInitializeDeviceInstanceEx even though this is not an IM driver?
Maybe I need to be a WAN adapter and send WAN line up and down messages.
Maybe emulating the cable disconnect is a good idea.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, August 22, 2006 12:28 AM
Subject: [ntdev] Prevent TCPIP from binding to a miniport.
> I have written a miniport driver that works as a virtual adapter for a VPN
client. It takes too much time to create and destroy these adapters on the fly
using the setup api. What I would like to do have the TCPIP protocol to bind to
the adapter when its in use and unbind when the adaper is no longer in use.
>
> My only idea is to bring up the adapter in some state where TCP cannot bind
to the adapter. When the adapter is needed, change that state to where TCP/IP
could bind and then send a IOCTL_NDIS_REBIND_ADAPTER which would toggle the
bind state. When the adapter is no longer needed, revert the state and re-send
the IOCTL_NDIS_REBIND_ADAPTER. The problem is I have no idea what state would
prevent TCP/IP from binding to an adapter that reports Ethernet Capability.
>
> Does anyone know how to do this or another way to accomplish the same goal?
>
> Thanks,
>
> -Matthew
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Maxim, I already have this but I didn’t think it forced the protocols to rebind. I will run some tests and see if this happens.
Maxim, the TCPIP protocol is still bound and the adapter is visible in ipconfig when the media status is disconnected. I think the reason why the dialup adapter only shows up when used because it uses the wan line up and down messages. I think this is the way I will have to go … crap 
Matthew,
It does not. TCPIP simply moves the interface into a ‘disconnected’ state
but the interface (none the less) remains present.
Typically VPN virtual adapters do not emulate media connect because doing so
can have adverse effects on other things like the time it takes to bring up
or down the adapter/interface. Most of the time a VPN adapter is statically
configured (TCPIP settings static) with media sense disabled. The
negotiated projection parameters are written to the registry prior to
enabling the adapter.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shrew.net
Sent: Monday, August 21, 2006 5:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Prevent TCPIP from binding to a miniport.
Maxim, I already have this but I didn’t think it forced the protocols to
rebind. I will run some tests and see if this happens.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
David, I tried the route of writing the parameters to the registry and then using the setupapi to enable /disable the adapter. It took so long to bring enable/disable its was totally unusable. However, I didn’t try disabling media sense though … how would you go about doing that anyway? The plan right now is to get away from the setup api as much as possible which is why I am posting these threads.
I need the up/down time to be as fast as possbile. With the way I have it right now, the delay is anywhere between 2 to 10 seconds with a solid HDD light. This is pretty sad considering the PHASE1+XAUTH+CONFIG negotiations typically complete before setupapi gets done doing whatever it is it does to create the adapter.
I have been reading through the DDK and the NDIS WAN option is starting to look appealing. I just wish there was a clear way to do it with a standard ethernet miniport and still have it work quickly. Its probably my fault for choosing the wrong driver technology in the first place. Linux and FreeBSD can create/destroy TUN/TAP drivers with blinding speed. I don’t understand why setupapi has to be so utterly slow or why every vendor that wants to provide virtual ethernet functionality has to write and package thier own NDIS driver … Sorry, now Im just complaining. I guess its time to stop that and start coding 
Media connect should work quickly, especially with a static IP - try
this on a normal ethernet adapter. Not 10 seconds and even not 2.
Something might be wrong with your driver.
–PA
wrote in message news:xxxxx@ntdev…
> David, I tried the route of writing the parameters to the registry and then using the setupapi to enable /disable the adapter.
> It took so long to bring enable/disable its was totally unusable. However, I didn’t try disabling media sense though … how
> would you go about doing that anyway? The plan right now is to get away from the setup api as much as possible which is why I
> am posting these threads.
>
> I need the up/down time to be as fast as possbile. With the way I have it right now, the delay is anywhere between 2 to 10
> seconds with a solid HDD light. This is pretty sad considering the PHASE1+XAUTH+CONFIG negotiations typically complete before
> setupapi gets done doing whatever it is it does to create the adapter.
>
> I have been reading through the DDK and the NDIS WAN option is starting to look appealing. I just wish there was a clear way
> to do it with a standard ethernet miniport and still have it work quickly. Its probably my fault for choosing the wrong driver
> technology in the first place. Linux and FreeBSD can create/destroy TUN/TAP drivers with blinding speed. I don’t understand
> why setupapi has to be so utterly slow or why every vendor that wants to provide virtual ethernet functionality has to write
> and package thier own NDIS driver … Sorry, now Im just complaining. I guess its time to stop that and start coding
>
Matthew,
Please describe more specifically what SetupApi logic you are using at
tunnel setup time to ‘enable’ the adapter. In general you would be best
served to have an adapter ‘created’ but disabled and to simply enable it.
This operation should not take 2 to 10 seconds. If in fact what you are
doing is ‘creating’ an adapter instance on demand, I can understand why it
is slow.
I appologize for refering to the NDISWDM sample as an example of using the
IM driver model to solve this. I am wrong about that. The sample does not
demonstrate that technique (and I can’t for the life of me now recall where
I have a sample that does demonstrate that). I have written virtual
adapter drivers which *do* use this technique, however. (ot: Eliyas-Y
didn’t you publish such a sample at one time?)
As I am sure you are aware the DEVCON sample is the ultimate reference to
how to enable/disable a devnode. I recall, however, that a bunch of it’s
processing time is the result of enumerating the devnodes to find the one
you wish to operate on. Once you have the SP_DEV_INFO_DATA calling the
class installer to DICS_ENABLE or DICS_DISABLE the device should not take
very long.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
David, as I stated previously, I did try to use the device enable/disable technique and it was still slow. Using this technique also requires that you have a device created in advance. One of the differences between my IPSEC client and others is that it supports multiple simultaneous tunnels. For that reason, there is little I can do to gauge how many adapters would be needed to satisfy the user requirements. Now I am back to creating adapters on demand or managing a pool of adapters over time.
I appreciate all the help people have offered here. Instead of trying to modify my current model, I think the time would be better served writing a WAN adapter that can create ‘Links’ on demand. That way I am only installing one adapter with setupapi and the Link create / destroy will all be handled within the confines of the NDIS system which should be near instantaneous.
Again, thank you all.
-Matthew
Well crap. I don’t think a WAN or CO driver will work either. I didn’t realize there would be so much integration with TAPI or Call managers. Maybe creating a pool of adapters is the only way to handle this. Grrrrr …
David, I only have one thing to say.
I finally took your advice and … YOU ROCK!!!
You are now my 12th best friend in the whole world.
-Matthew
Ok, so my adapter disable time is now almost instantaneous but my adapter enable time is about the same ( can take several seconds to enable ) on windows 2000. Its a bit faster on windows XP. I write the adapter config info to the registry and use a simple setup api propery change with the DICS_ENABLE option to accomplish this.
David mentioned that media sense should be disabled to increase the enable speed. I modified the NIC driver to always report NdisMediaStateConnected for OID_GEN_MEDIA_CONNECT_STATUS. Is there another change that needs to be made. Maybe in the inf file?
Thanks in advance,
-Matthew
AFAIK to ‘disable’ media sense you need to report NDIS_STATUS_NOT_SUPPORTED
when queried for OID_GEN_MEDIA_CONNECT_STATUS. Responding to the OID with
success is what tells NDIS that it can expect media sense support from the
miniport. You should also remove OID_GEN_MEDIA_CONNECT_STATUS from the list
supplied by OID_GEN_SUPPORTED_OIDS.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shrew.net
Sent: Friday, August 25, 2006 10:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Prevent TCPIP from binding to a miniport.
Ok, so my adapter disable time is now almost instantaneous but my adapter
enable time is about the same ( can take several seconds to enable ) on
windows 2000. Its a bit faster on windows XP. I write the adapter config
info to the registry and use a simple setup api propery change with the
DICS_ENABLE option to accomplish this.
David mentioned that media sense should be disabled to increase the enable
speed. I modified the NIC driver to always report NdisMediaStateConnected
for OID_GEN_MEDIA_CONNECT_STATUS. Is there another change that needs to be
made. Maybe in the inf file?
Thanks in advance,
-Matthew
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hmmm. This was worth a shot but I tried all combinations of omitting OID_GEN_MEDIA_CONNECT_STATUS from OID_GEN_SUPPORTED_OIDS and reponding with NDIS_STATUS_NOT_SUPPORTED. Results varied from odd system livelocks to blue screens.
I flipped through the DDK and it states that support for OID_GEN_MEDIA_CONNECT_STATUS is required. My driver init function returns with no delay, my initialize adapter returns with no delay. If enabling and adapter can work faster than taking several seconds, I don’t know where to go from here.
Anyone have any suggestions?
Thanks,
-Matthew
“David R. Cattley” wrote in message news:xxxxx@ntdev…
> AFAIK to ‘disable’ media sense you need to report NDIS_STATUS_NOT_SUPPORTED
> when queried for OID_GEN_MEDIA_CONNECT_STATUS. Responding to the OID with
> success is what tells NDIS that it can expect media sense support from the
> miniport. You should also remove OID_GEN_MEDIA_CONNECT_STATUS from the list
> supplied by OID_GEN_SUPPORTED_OIDS.
In the NDIS WDK documentation, OID_GEN_MEDIA_CONNECT_STATUS is marked as mandatory, so not supporting it looks like an error.
Also, DisableDHCPMediaSense is a global parameter, if set,
this will affect all connections ( http://support.microsoft.com/kb/q239924 )
Regards,
–PA