CODEWITHSUNDEEP
ndis
newsoft
newsoft

Reputation: 13

Calls FilterAttach in filter driver

I create NDIS network filter driver but when I install it I see "FilterAttach" call 4 times.
Why "FilterAttach" call 4 times In my Filter Driver?

Upvotes: 1

Views: 707

Answers (1)

Jeffrey Tippet
Jeffrey Tippet

Reputation: 3006

There are 3 reasons that you'll see many FilterAttach calls in your driver:

  • multiple NICs,
  • monitoring filters, and
  • NDIS binding recalculations

Let's look at each in detail.

Multiple NICs

Filter drivers will bind a filter module to each NIC that is compatible with the filter driver. So if you have 3 compatible NICs, you'll get at least three calls to FilterAttach.

 [TCPIP]    [TCPIP]    [TCPIP]
    |          |          |
[filter1]  [filter2]  [filter3]
    |          |          |
 [NIC1]     [NIC2]     [NIC3]

You can tell you're in this situation because the NDIS_FILTER_ATTACH_PARAMETERS::BaseMiniportIfIndex value is different across the different FilterAttach instances. This means your filter is getting bound over different NICs.

Monitoring filters

An NDIS LWF is either monitoring or modifying. Look in the INF file to see which type of filter you have:

; For a Monitoring filter, use this:
;     HKR, Ndi,FilterType,0x00010001, 1 ; Monitoring filter
; For a Modifying filter, use this:
;     HKR, Ndi,FilterType,0x00010001, 2 ; Modifying filter

The difference between monitoring and modifying is in how these filters bind to a network card. A modifying filter is the simplest: it will just bind once per network card. In contrast, monitoring filters will bind once for each other modifying filter, and one more time for the NIC itself. Here's a diagram of what happens when you have a monitoring filter and 2 modifying filters:

  [TCPIP]
     |
[monitoring1]   // 3
     |
[modifying2]
     |
[monitoring1]   // 2
     |
[modifying1]
     |
[monitoring1]   // 1
     |
   [NIC]

The key thing to notice in this diagram is that the same monitoring filter is attached 3 times to the stack: once over the NIC, and once over each of the 2 modifying filters (modifying1 and modifying2).

If you don't want your monitoring filter to bind at each altitude like that, you can return NDIS_STATUS_NOT_SUPPORTED from your FilterAttach handler any time NDIS_FILTER_ATTACH_PARAMETERS::LowerIfIndex is different from NDIS_FILTER_ATTACH_PARAMETERS::BaseMiniportIfIndex. If you have a mandatory filter, you should also set the NDIS_FILTER_ATTACH_FLAGS_IGNORE_MANDATORY flag in the NDIS_FILTER_ATTACH_PARAMETERS::Flags, but note that we do not recommend marking a monitoring filter as mandatory.

You can tell that you're in this situation if the NDIS_FILTER_ATTACH_PARAMETERS::BaseMiniportIfIndex is the same in both calls to FilterAttach, but the NDIS_FILTER_ATTACH_PARAMETERS::FilterModuleGuidNameis different. TheBaseMiniportIfIndextells you which miniport your filter is over, and theFilterModuleGuidName` tells you exactly which filter instance is attaching.

NDIS binding recalculations

The final reason that a filter may see multiple calls to its FilterAttach routine is because NDIS sometimes recalculates bindings. Maybe a new filter is getting installed below your filter — NDIS will unbind your filter (FilterDetach) bind the new filter, then bind your filter again (FilterAttach).

You can tell that NDIS is re-trying your filter due to a binding recalculation because the NDIS_FILTER_ATTACH_PARAMETERS::FilterModuleGuidName is the same as a previous call to FilterAttach. This means that NDIS is attaching your filter in the same spot as before.

Debugging tips

If you have a kernel debugger attached, you can always use !ndiskd.filterdriver to see where your filter is attached. You can also use !ndiskd.netreport to see a graphical visualization of the network stack.

Upvotes: 2

Related Questions