> I have an NDIS intermediate driver of my own and am working with some VPN
clients which also have intermediate drivers of their own.
AFAIK, as many as you want. There is one caveat, though: you can only
have one IM of a given FilterClass installed in the system at a time. I
have been unable to get from Microsoft why this is the case, but I’ve
seen bad things in situations where two drivers of the same FilterClass
were installed - blue screens, reproducable, in one case.
Here’s the deal. Win2k/XP maintain a registry key
(HKLM\System\CurrentControlSet\Control\Network\FilterClasses IIRC - no
windows box close to verify, sorry) that is a REG_MULTI_SZ which holds
an ordered list of filter classes. There are three there by default -
failover, loadbalance, scheduler - but you can add more. The QoS packet
scheduler that ships with XP is a scheduler driver.
Drivers are bound in the order of the classes in that key. If you want
your driver to be at the bottom of the stack, your filter class entry
has to come first (or last? experiiment…) in that list.
Creating new FilterClass entries is easy - just specify a filter class
in your INF and it will automatically be added to the registry by the
class installer. Furthermore, it will be inserted in the lowest
position. If the class already exists, no change will take place.
The only robust way to make sure your filter doesn’t collide with
another filter in the same class, though, is to specify a custom filter
class and check in the registry to make sure it doesn’t already exist
before driver installation. You can also re-order the classes at that
time if you have a specific binding order requirement.
During testing, I had a bunch of trouble with bulescreens during driver
installation, and a couple of bugs were filed with microsoft. In the
meantime, I found that deleting the “control” value from that same
registry key is enough to cause the class isntaller to re-build the
configuration data on the next boot, so try that if you run into
mysterious installation bluescreens.
One other note - the most popular IM driver out there is a thingy called
the Deterministic NDIS Enhancer (DNE) by Deterministic Networks, Inc.
That driver is included in many big VPN-related products - SafeNet,
Cisco, SonicWall, and I hear Microsoft is shipping it in the new Win9x
VPN client, but i haven’t had time to check it out yet. Anyway, DNE
installs as class failover, so you can’t use that either if you want to
interoperate with anything. Also, DNE gets really picky about binding
order. In one case, we found that DNE *required* that it be bound at
the bottom of the stack (i.e. closest to the miniport) when used with
the Windows XP PPPoE driver and our IM. When we bound below DNE, DNE
didn’t accept (or see?) the packets at all. Stack traces seemed to
confirm that their driver got called, so I don’t know what the deal was
there, but they’ve been informed.
One last thing. In spite of the above, I’d recommend checking out DNE
if you’re in the IM market. They have a good and widely-installed
driver that accepts ‘plugins’ - it’s what Microsoft should have written
instead of the IM architecture, in my opinion. I’m told that they’re
moving in that direction with NDIS6, but that’s years off yet. The best
part about it is that your plugins are cross-platform, including 95, 98,
Me, NT, 200, XP, and even Unix and WinCE. Note - I don’t have anything
to do with them; I’m just impressed with their stuff.
Hope this helps.
-sd