Hi all,
I have a protocol driver part of an IM. I need to selectively pick up
interfaces for binding. Specifying lower edge as “ndis5” selects all
interfaces(which have upper edge as “ndis5”) by default. Also i have
characterisitcs=0x0 in protocol’s inf. i have an application which can
enable the “selective binding”. So my requirement is how to mute these
default bindings while the protocol driver is installed. Is there any flag
that can be passed to binding engine via inf/api for muting these bindings?
> So my requirement is how to mute these default bindings while the protocol driver is installed A Notify Object Good Luck,Dave Cattley
my application is an exe and there is no notify object dll. Is there any
other way i can do this?
No alternative exists. A notify object is the only way that a protocol can selectively disable bindings. The WDK includes a sample notify object – for your purposes, you can strip out anything relating to “WDF”, which is most of the code. Once you are left with a simple skeleton, you can implement the QueryBindingPath method to disable any bindings that you don’t want.
http://code.msdn.microsoft.com/NDISProt-9a3cab24/sourcecode?fileId=51283&pathId=1211861005
Ok thanks.
I need one more clarification. I will still be using the appln to enable
bindings for desired interfaces, so can the appln use registry to
communicate the desired interfaces to notify object(Basically
QueryBindingPath reads a registry and decides whether to allow or disallow
a binding)? or is there a better way.
That’s a reasonable way to do it. Create a registry key for the application that lists all bindings that are allowed (whitelisted). The application updates this registry key. The notify object simply reads the registry key, and adds/removes bindings as necessary to enforce the application’s policy.
Ok Thanks a lot
Note that using a registry key is not quite atomic. If the app is actively changing the key while the driver is reading it, you can easily see torn state. Also, the driver still has to know /when/ to read the registry key. If it only reads the key at fixed points in time, you should be ok, but if you need to read the registry every time it is updated, you might as well just send the white list is an irp
d
Bent from my phone
From: Subbiah Ganesanmailto:xxxxx
Sent: ?2/?26/?2013 11:20 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] Custom Binding for a Protocol driver
Ok Thanks a lot — NTDEV is sponsored by OSR OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
Those are valid concerns for interacting with drivers, but in this context, we’re talking about two usermode components (an application, and a driver’s usermode NotifyObject). Synchronizing these two is made possible by the system-wide INetCfgLock.
> Synchronizing these two is made possible by the system-wide INetCfgLock. … Just so long as the UM application doing the writing/updating of the [private] registry key holding the white/black list acquires the INetCfgLock as a prerequisite to modifying that list. In other words, the application and the Notify Object must agree that the white/black list is logically now part of the “Network Configuration” and may only be changed while holding the NetCfgLock. Cheers,Dave Cattley