NDIS LightWeight Filter INF file - How does "LowerExclude" work? RRS feed

  • Question

  • Hello.
    We have a LWF driver which, based on WDK NDIS LWF driver, intercepts NDIS packets.
    The associated INF file is configured as follows:

    - FilterClass -> compression
    - FilterType -> 0x00010001,0x00000002
    - UpperRange -> "noupper"
    - LowerRange -> "nolower"
    - FilterMediaTypes -> "ethernet, tokenring, fddi, wan"
    - FilterRunType -> 0x00010001, 2 ; OPTIONAL Filter | This is an optional filter module
    We would like to avoid attaching to certain types of adapters. This means FilterAttach of our LWF would not be called for them. The first question is: Is this possible?

    Investigating we have bumped into what seems to be an alternative. Several ndis filter drivers inf files include the following line:

    HKR, Ndi\Interfaces, LowerExclude,   , "ndisatm, ndiscowan, ndiswan, ndiswanasync, ndiswanipx, ndiswannbf"

    Unfortunately we have not found detailed documentation about how this technique works. We would like to know:

    1- What is LowerExclude, how does it work, and how must it be configured?

    2- What are the outcomes of including those types of adapters in the LowerExclude line?

    3- What do the values included in the parameter list refer to? For example, are they "MatchingDeviceId" entries from the adapters registry keys?

    We would be grateful if you could help us with this issue. Thank you in advance,

    Javier Guerrero
    Thursday, January 29, 2015 1:22 PM

All replies

  • There are 3 ways to get your driver to not bind to some other driver:
    1. Have your filter/protocol return a failure status each time NDIS proposes the binding (in FilterAttach/ProtocolBindAdapter).
    2. Disable the binding in usermode.  Do this from an application with INetCfgBindingPath::Enable(FALSE), or from a Notify Object's INetCfgComponentNotifyBinding::NotifyBindingPath callback.
    3. Don't let the binding get created in the first place, by fiddling with the binding keywords in your INF.

    It sounds like you're interested in the third option.  If the third option works, then it's the best, since it is the most efficient and doesn't allow nosy users to re-enable your bindings. But the third option is also the most limited, since you need to work with the set of keywords that the binding engine understands.

    LowerExclude is one of these binding keywords.  For LWFs, binding works like this.  A binding between a LWF and an adapter is created: if the LWF's FilterMediaTypes has some token in common with the adapter's LowerRange, and the LWF's LowerExclude has no token in common with the adapter's UpperRange.

    Example 1:

    LWF has FilterMediaTypes = "a,b,c" and LowerExclude = "x,y,z"
    Adapter has LowerRange = "d,c" and UpperRange = "w"
    The LWF is bound to the adapter, because "c" is in common with the LowerRange+FilterMediaTypes, and there is no common element in the UpperRange+LowerExclude.

    Example 2:

    LWF has FilterMediaTypes = "a,b,c" and LowerExclude = "x,y,z"
    Adapter has LowerRange = "a,b,c" and UpperRange = "w,x"
    The LWF is not bound to the adapter, because "x" is in common with UpperRange+LowerExclude.

    Generally, you're going to find that LowerExclude is of limited usefulness, because most hardware adapters have an UpperRange that is simply "ndis5".  You don't get very granular selection with that.  You're probably going to need to resort to using an INetCfg call, or just failing FilterAttach on undesired adapters.

    Thursday, January 29, 2015 11:51 PM