Discussion:
Multiple NDIS IM drivers in the same Filter Class
(too old to reply)
Ilya Faenson
2004-04-01 02:35:49 UTC
Permalink
Most practical applications for the NDIS intermediate drivers require
developers to know where exactly their drivers are loaded in relation
to other filters. For example, if your driver happens to be placed
below a VPN driver rather than above it, that driver is unlikely to
be functional. The same it often true about coexistence with firewalls,
packet schedulers and so on so forth. Therefore, I highly recommend
your own filter class and some external management of the FilterClasses
value. Any decent product programmatically installs / uninstalls its
intermediate driver(s), so that [un]install is a place to deal with
the FilterClasses before the install and after the uninstall. Your
notify object should double-check that the filter order is still to your
liking when a network configuration is changed.

Hope that helps,
Ilya Faenson
Hi,
MSDN says you cannot have multiple IM drivers in the same filter class,
however I have heard otherwise and in fact am able to load/install multiple
IM drivers in the same filter class (like
failover class for example). Can some one tell me if this is supposed to
work or not?
Some additional information is available in the latest MSDN. See the topic
"INFO: Controlling Stacking Order of NDIS 5.0 Intermediate Drivers", PSS IS
http://support.microsoft.com/default.aspx?scid=kb;en-us;250615
Yes, it certainly does appear that multiple filters of the same class (at
least failover) can be installed. However, the real binding order isn't
defined under these conditions and the installation may not work
successfully and repeatably in all cases.
Perhaps Longhorn NDIS 6 will help in the future.
Thomas F. Divine
Thanks
Lyle
Maxim S. Shatskih
2004-04-01 12:02:50 UTC
Permalink
Post by Ilya Faenson
Most practical applications for the NDIS intermediate drivers require
developers to know where exactly their drivers are loaded in relation
to other filters. For example, if your driver happens to be placed
below a VPN driver rather than above it, that driver is unlikely to
be functional.
Sorry, but "below VPN" means - filtering a WAN miniport below NDISWAN, which is
absolutely other song and can be easily prevented.
Post by Ilya Faenson
The same it often true about coexistence with firewalls,
packet schedulers and so on so forth.
I see nothing which can prevent firewall and scheduler (or 2 firewalls) from
co-existing, regardless of the binding order.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
***@storagecraft.com
http://www.storagecraft.com
Ilya Faenson
2004-04-02 22:13:14 UTC
Permalink
Maxim,

Microsoft VPN client you're talking about has negligible market share
at the moment. All industry leading VPN clients (Nortel, Cisco, Check
Point etc.) happen to run virtual NDIS LAN miniports and intermediate
drivers, so being stuck "below VPN" intermediate driver is indeed a
distinct possibility. Microsoft VPN client is being redesigned for
Longhorn though - let's see what they come up with.

I was not talking about running two firewalls which rarely makes sense.
A more typical case is a filter changing the nature of the traffic and/
or spoofing it. The firewall's functionality (and the filter's) will be
affected considerably by the filter order. For example, the spoofer
will defeat the firewall if placed above it.

Hope that clarifies what I meant to say,
-Ilya
Post by Maxim S. Shatskih
Post by Ilya Faenson
Most practical applications for the NDIS intermediate drivers require
developers to know where exactly their drivers are loaded in relation
to other filters. For example, if your driver happens to be placed
below a VPN driver rather than above it, that driver is unlikely to
be functional.
Sorry, but "below VPN" means - filtering a WAN miniport below NDISWAN, which is
absolutely other song and can be easily prevented.
Post by Ilya Faenson
The same it often true about coexistence with firewalls,
packet schedulers and so on so forth.
I see nothing which can prevent firewall and scheduler (or 2 firewalls) from
co-existing, regardless of the binding order.
Loading...