Hi,

I've got an NDIS IM MUX driver, which is based on the MUX sample in the
W2k3 DDK.
I'm trying to get an IM filter driver to bind to this, at *install
time*.

This filter driver is bound to the physical miniport before install
(along with TCPIP, MS Client, File & Printer sharing). I've built the
MUX notifyob with "DISABLE_PROTOCOLS_TO_PHYSICAL" defined, so ideally,
i would expect that after the install, all the protocols that were
bound to the physical NIC should now be bound to the MUX miniport.
Unfortunately, the filter driver is not bound to it (incidentally,
neither is the nlbs driver).

I can bind the filter driver after the install, manually from the UI,
by checking the box on the MUX miniport, so there isnt anything in the
NDIS upperRange or lowerRange to prevent the binding from happening.

I've stepped through the notifyobject in the debugger (from breakpoints
in SysQueryBindingPath, and NotifyBindingPath) to see if the notifyob
ever even got the binding paths with the filter driver in it. I didnt
see any.

The filter driver's protocol inf has the following interesting lines:

1. [ndi]
Characteristics = 0x4490 ; NCF_NDIS_PROTOCOL | NCF_HAS_UI | NCF_FILTER
| NCF_NO_SERVICE

2. [AddReg]
HKR, Ndi, FilterClass, , failover
HKR, Ndi\Interfaces, UpperRange, , noupper
HKR, Ndi\Interfaces, LowerRange, , nolower
HKR, Ndi\Interfaces, FilterMediaTypes, , "ethernet, nolower"


Why isnt the filter drivers binding paths showing up in the notifyob
methods ?

Alternatively, is there any other way to programmatically bind the
filter driver to the MUX driver ? (This is what i really want to
achieve)

Thanks,

Gaurav

NDIS Filter intermediate (IM) drivers are somewhat, say, "invisible" or
"translucent". That is, a Filter IM attaches to the miniport(s), but
the protocols(s) above the miniport still think they bind *directly* to
the miniport.

Not sure what the MUX sample currently does (I haven't looked into it
for a while) but IIRC when I wrote a MUX I had to take care of
unbinding/binding protocols from/to miniports of physical NICs myself
(i.e. in the MUX protocol's Notify Object).

Note that binding paths are *always* established for all networking
components. That is, there is no way to prevent binding paths from
being created between any two net components that can bind to each
other [..although the docs say different].

You can just prevent a binding from getting *enabled* (note the
difference).

Use the DDK's bindview (or netcfg) sample tool to see all the bindings.

Use INetCfgBindingPath::Enable() or INetCfgComponentBindings::BindTo()
and INetCfgComponentBindings::UnbindFrom() to enable/disable
(activate/deactivate) binding paths.

Stephan
---
gauravl@gmail.com wrote:

Yes, I stepped through the notify object closely and i found that the
filter IM was being disabled from the MUX driver (ms_wlbs is the filter
IM), and there was only a *Notify* call to the MUX's notify object.

-->CMuxNotify INetCfgNotifyGlobal::SysNotifyBindingPath.
ChangeFlag: NCN_ADD NCN_DISABLE
BindingPath: ms_wlbs->ROOT\MS_MUXMP\0001
<--CMuxNotify INetCfgNotifyGlobal::SysNotifyBindingPath(HRESULT = 0).

TCP on the other hand was enabled on the MUX driver, and there was a
query as well as a notify call to the MUX's notify object.

-->CMuxNotify INetCfgNotifyGlobal::SysQueryBindingPath.
ChangeFlag: NCN_ADD NCN_ENABLE
BindingPath: ms_tcpip->ROOT\MS_MUXMP\0001
<--CMuxNotify INetCfgNotifyGlobal::SysQueryBindingPath(HRESULT = 0).

-->CMuxNotify INetCfgNotifyGlobal::SysNotifyBindingPath.
ChangeFlag: NCN_ADD NCN_ENABLE
BindingPath: ms_tcpip->ROOT\MS_MUXMP\0001
<--CMuxNotify INetCfgNotifyGlobal::SysNotifyBindingPath(HRESULT = 0).

So it seems like someone (the ms_wlbs filter's notifyob?) has disabled
that binding, and the MUX's notifyob doesnt have a chance to enable it.
I try to fail the 'SysNotifyBindingPath (disable)' call but that
doesnt prevent the disable.

The workaround is to enabled it post-install using bindview. But i'd
like to know who disables the binding at install time, and whether i
can prevent the disabling from inside the notifyob somehow.

Thanks!

Gaurav

gauravl@gmail.com wrote:
Hmm, IIRC, what we do is that we actually actively re-enable the
binding when we see the notify (!), i.e. we call
INetCfgBindingPath::Enable(TRUE).

Stephan