Hi,
I have a basic question on Intermediate Driver in Vista. I am trying to
port a NDIS 4.0 filter intermediate driver to NDIS 6.0 (in Vista).
Since in Vista there is no “filter intermediate driver”, I am making it
an “Intermediate driver”.
Does “Intermediate driver” mean it should be a MUX driver, which will
require more changes for porting?
OR
We can just have an Intermediate Driver which will mean just porting
NDIS calls in the driver?
Thanks,
Sunil
Don?t let the documentation and the wishful thinking of the NDIS6 ?party
line? get in your way J
Vista supports NDIS5 intermediate drivers and NDIS6 intermediate drivers.
An IM driver is any driver that has a miniport upper edge and a protocol
lower edge. That includes ?MUX? where the relationship is N:K and
?Filter? where the relationship is 1:1.
Now that said, it would be better if you are porting such a thing to port it
to either an entirely different type of driver depending on what it does:
If you IM driver plays with IP packets and only IP packts,
consider the Windows Filtering Platform and possibly a WFP callout driver.
If you IM plays with Layer 2 (Ethernet) frame level information,
plays with OIDs to accomplish its job, etc. then consider building a Light
Weight Filter (LWF) driver for NDIS6.
MUX and Filter just refer to the cardinality of the relationship between
bindings and virtual miniports. Also, a MUX driver is presumed to have a
Notify Object to figure out how to setup the Miniports. The system (NetCfg)
has built in support for Filter type drivers that require a single virtual
miniport created over each protocol binding.
Infact, the NDIS6 team fully implemented the complex install and operational
behavior to allow layer IM drivers and LWF drivers (more or less)
arbitrarily in the interface ?stack?.
What does your driver do? That will determine what you should consider as a
porting target (or perhaps no port at all).
Does it not work on Vista or something? Have you tried?
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bale, Sunil (IE10)
Sent: Thursday, January 22, 2009 8:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS 6.0 Intermediate Driver
Hi,
I have a basic question on Intermediate Driver in Vista. I am trying to port
a NDIS 4.0 filter intermediate driver to NDIS 6.0 (in Vista).
Since in Vista there is no “filter intermediate driver”, I am making it an
“Intermediate driver”.
Does “Intermediate driver” mean it should be a MUX driver, which will
require more changes for porting?
OR
We can just have an Intermediate Driver which will mean just porting NDIS
calls in the driver?
Thanks,
Sunil
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>Does “Intermediate driver” mean it should be a MUX driver
No, it’s absolutely other notion new to NDIS6.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks!
My driver is a fail over driver, which works with a dual port (or two) ethernet card. So basically it takes care of choosing a different port (or enet card) in case one of them fails or a cable fault on one of the ports and it is 1:1 binding.
So I think this has to be an IM driver to acheive this.
-Sunil
Sunil,
The LBFO mechanisms in NDIS are designed to allow multiple NICs managed by
the same Miniport Driver to be exposed to NDIS as a ‘bundle’ consisting of a
Primary and zero or more Secondary NICs - all acting as a single logical
NIC.
The routines NdisMSetMiniportSecondary() and NdisMPromoteMiniport() support
this paradigm.
The solution technique of building an MUX driver to create a LBFO driver
might now be a thing of the past. Unless you are trying to do this for
NICs that
There are some presentations from WinHEC 2000 that I will refer you to as
background information though it is, of course, not exactly ‘fresh’. Look
at the IM driver and LBFO Miniport information as well as the WDK design
guide docs.
http://www.microsoft.com/whdc/device/network/WinHEC2kPres.mspx
You seem to be missing the point that a MUX *is* an IM driver. You are also
seem to be missing the point that by it’s very nature, a LBFO driver does
not present a 1:1 binding to virtual miniport model to upper bound
protocols. If it did, there would be nothing to load balance or failover
too. I suggest you read the above materials and look at the binding
diagrams to come to an understanding of how LBFO drivers expose a ‘bundle’
of links as a single link.
But keep in mind that NDIS6 introduces the concepts of “Interfaces” and
“Ports”. This changes the model around LBFO. Most significantly think
about an LBFO deployment with 802.1x link authentication. All the ‘links’
in the bundle will still need to be authenticated individually before they
are authorized. NDIS6 provides the mechanisms for the platform to interact
with each ‘link’ as a ‘port’ to get it authenticated. I again refer you
to the WDK docs and in particular the Network Design Guide. In the NDIS
Core Functionality section on NDIS Ports you can find some useful background
on how these might influence a LBFO IM driver.
Maybe you can use the LBFO features of NDIS in the Virtual Miniport edge of
an IM driver. I don’t know. I have not tried it.
Good Luck,
Dave
wrote in message news:xxxxx@ntdev…
> Thanks!
> My driver is a fail over driver, which works with a dual port (or two)
> ethernet card. So basically it takes care of choosing a different port (or
> enet card) in case one of them fails or a cable fault on one of the ports
> and it is 1:1 binding.
>
> So I think this has to be an IM driver to acheive this.
>
> -Sunil
>
Honeywell currently has a patented NDIS5.1 IM driver that is fault tolerant which is 1:1 on two NICs. My team is porting this driver to 1:N MUX IM driver for NDIS6.0 on Vista.
Larry,
Can you share with us the reason for the additional upper virtual
miniport(s) per bundle? Is it install convenience or does the failover
occur to (one of) the dormant (upper) virtual miniport?
Cheers,
-Dave
wrote in message news:xxxxx@ntdev…
> Honeywell currently has a patented NDIS5.1 IM driver that is fault
> tolerant which is 1:1 on two NICs. My team is porting this driver to 1:N
> MUX IM driver for NDIS6.0 on Vista.
>
Dave,
I don’t know if you rremember but I spoke with you briefly at DDC. The driver is called Fault Tolerant Ethernet, FTE for short.
Our MUX will expose one virtual miniport to the IP stack with two physical NIC below. This configuration will allow one IP address to be used. We have customers that are very low on the number of IP addresses they have available. Also, application will not have knowledge of multiple NICs nor should they care.
Here is a simple explaination of how FTE works:
The two NICs are connected to two network “trees” with the two trees connected with a crossover cable at the top. This provides 4 possible paths between any to nodes that have FTE. If the NICs are labeled “A” and “B” the paths are A->A, A->B, B->A and B->B. FTE sends a Diagnostic Message (DM) out each NIC via multicast that says how that node “sees” all other FTE nodes. Upon reception of a DM from another node FTE builds a path table between the two nodes. FTE guarantees delievery for all single network faults and for some double faults. FTE also has another table for non-FTE nodes but I’ll leave that processing out for now.
When a packet is to be transmitted FTE check to see which path is valid at that monment and then decides which NIC to send out and which NIC on the other node will receive the packet, changing the headers as necessary.
When a packet is received on the non-MUX version, FTE decides which stack the packet is to go up and change the header if necessary. The MUX version will only have one stack. All this is done transparent to the applications using the network.
Larry,
Thank you for explaining that. Yes, remember our conversation but I was not
sure I was at liberty to recount what we had talked about.
Best Regards,
-Dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@honeywell.com
Sent: Friday, January 23, 2009 4:24 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS 6.0 Intermediate Driver
Dave,
I don’t know if you rremember but I spoke with you briefly at DDC. The
driver is called Fault Tolerant Ethernet, FTE for short.
Our MUX will expose one virtual miniport to the IP stack with two physical
NIC below. This configuration will allow one IP address to be used. We have
customers that are very low on the number of IP addresses they have
available. Also, application will not have knowledge of multiple NICs nor
should they care.
Here is a simple explaination of how FTE works:
The two NICs are connected to two network “trees” with the two trees
connected with a crossover cable at the top. This provides 4 possible paths
between any to nodes that have FTE. If the NICs are labeled “A” and “B” the
paths are A->A, A->B, B->A and B->B. FTE sends a Diagnostic Message (DM) out
each NIC via multicast that says how that node “sees” all other FTE nodes.
Upon reception of a DM from another node FTE builds a path table between the
two nodes. FTE guarantees delievery for all single network faults and for
some double faults. FTE also has another table for non-FTE nodes but I’ll
leave that processing out for now.
When a packet is to be transmitted FTE check to see which path is valid at
that monment and then decides which NIC to send out and which NIC on the
other node will receive the packet, changing the headers as necessary.
When a packet is received on the non-MUX version, FTE decides which stack
the packet is to go up and change the header if necessary. The MUX version
will only have one stack. All this is done transparent to the applications
using the network.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
The algorithm has been published by the Fieldbus Foundation in the document titled “High Speed Ethernet Redundancy FF-593”.
Larry C