Hello Experts,
I’m a new windows developer working on redesigning the MUX
Intermediate driver sample (from WINDDK 2600.1106) to have
a 1-to-N virtual to physical adapter relationship.
The MUX IM driver is receiving packets from only one adapter.
Both adapters/miniports are receiving packets in from the line,
confirmed with Ethereal, but only one of the miniports is
passing the packets up to the MUX layer.
Both physical adapters use the same MAC address and are on
isolated networks.
The NDIS packet filters are set to non-zero values for both
the virtual and physical adapters.
I am using an Intel dual port gigabit Ethernet card and I don’t have
the source code for the miniport driver.
All suggestions are appreciated.
Craig
For limitations on the use and distribution of this message, please visit www.sbs.com/emaildisclaimer.
“Craig Rocca” wrote in message news:xxxxx@ntdev…
Hello Experts,
I’m a new windows developer working on redesigning the MUX
Intermediate driver sample (from WINDDK 2600.1106) to have
a 1-to-N virtual to physical adapter relationship.
The MUX IM driver is receiving packets from only one adapter.
Both adapters/miniports are receiving packets in from the line,
confirmed with Ethereal, but only one of the miniports is
passing the packets up to the MUX layer.
Both physical adapters use the same MAC address and are on
isolated networks.
The NDIS packet filters are set to non-zero values for both
the virtual and physical adapters.
I am using an Intel dual port gigabit Ethernet card and I don’t have
the source code for the miniport driver.
All suggestions are appreciated.
Craig
The basic idea behind a 1:N MUX is that there are N real adapters and only one virtual adapter. Only the one virtual adapter is actually bound to TCP/IP, etc.
One common approach is to identify one of the N real adapters as the “primary adapter”. The one-and-only MUX virtual adapter is layered over the primary adapter. All other real adapters are called “secondary”. The call to NdisMSetMiniportSecondary establishes the relationship between the primary and secondary adapters. Protocol drivers can only bind to the MUX primary adapter. All bindings to MUX secondary adapters are torn down.
So, there is no reason to expect packets received on a secondary to go anywhere unless your MUX indicates it upwards on the primary.
When a packet is received on ANY of the N real adapters the 1:N MUX will indicate it upwards (by calling NdisMIndicateReceivePacket) on the PRIMARY adapter - REGARDLESS of which of the N real adapters it was actually received on.
Good luck,
Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com
Thanks for the response Thomas.
I’m still not quite clear on what I can and cannot do from
The MUX IM driver with regards to incoming packets.
I would like the MUX IM driver to receive packets from both
adapters concurrently. Is this possible?
Did you say that this could be accomplished if my “secondary”
adapter indicates packets up on the primary adapter from the
lower miniport?
Is there a way for the MUX IM driver to tell a lower “secondary”
miniport driver to indicate packets up on the primary adapter?
Craig
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, October 12, 2005 11:07 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Receiving packets/Mux IM driver sample
“Craig Rocca” wrote in message
news:xxxxx@ntdev…
Hello Experts,
I’m a new windows developer working on redesigning the MUX
Intermediate driver sample (from WINDDK 2600.1106) to have
a 1-to-N virtual to physical adapter relationship.
The MUX IM driver is receiving packets from only one
adapter.
Both adapters/miniports are receiving packets in from the
line,
confirmed with Ethereal, but only one of the miniports is
passing the packets up to the MUX layer.
Both physical adapters use the same MAC address and are on
isolated networks.
The NDIS packet filters are set to non-zero values for both
the virtual and physical adapters.
I am using an Intel dual port gigabit Ethernet card and I
don’t have
the source code for the miniport driver.
All suggestions are appreciated.
Craig
The basic idea behind a 1:N MUX is that there are N real adapters and
only one virtual adapter. Only the one virtual adapter is actually bound
to TCP/IP, etc.
One common approach is to identify one of the N real adapters as the
“primary adapter”. The one-and-only MUX virtual adapter is layered over
the primary adapter. All other real adapters are called “secondary”. The
call to NdisMSetMiniportSecondary establishes the relationship between
the primary and secondary adapters. Protocol drivers can only bind to
the MUX primary adapter. All bindings to MUX secondary adapters are torn
down.
So, there is no reason to expect packets received on a secondary to go
anywhere unless your MUX indicates it upwards on the primary.
When a packet is received on ANY of the N real adapters the 1:N MUX will
indicate it upwards (by calling NdisMIndicateReceivePacket) on the
PRIMARY adapter - REGARDLESS of which of the N real adapters it was
actually received on.
Good luck,
Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This message has been scanned for virus, spam, and undesirable
content.
For further information, contact your mail administrator.
For limitations on the use and distribution of this message, please visit www.sbs.com/emaildisclaimer.
“Craig Rocca” wrote in message news:xxxxx@ntdev…
Thanks for the response Thomas.
I’m still not quite clear on what I can and cannot do from
The MUX IM driver with regards to incoming packets.
I would like the MUX IM driver to receive packets from both
adapters concurrently. Is this possible?
Yes. You may have to set the lower adapter’s NDIS packet filter on secondary yourself since the higher-levels don’t know about secondary adapters.
Did you say that this could be accomplished if my “secondary”
adapter indicates packets up on the primary adapter from the
lower miniport?
Is there a way for the MUX IM driver to tell a lower “secondary”
miniport driver to indicate packets up on the primary adapter?
No, you cannot tell lower adapters to do that.
Instead, you must keep track of which adapter is primary (visible to the system) and which ones are secondary (not visible to higher levels). When you receive on a secondary, find the primary. Indicate the packet upwards using packets and handles from the primary instead of the secondary.
Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com
Craig
------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, October 12, 2005 11:07 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Receiving packets/Mux IM driver sample
“Craig Rocca” wrote in message news:xxxxx@ntdev…
Hello Experts,
I’m a new windows developer working on redesigning the MUX
Intermediate driver sample (from WINDDK 2600.1106) to have
a 1-to-N virtual to physical adapter relationship.
The MUX IM driver is receiving packets from only one adapter.
Both adapters/miniports are receiving packets in from the line,
confirmed with Ethereal, but only one of the miniports is
passing the packets up to the MUX layer.
Both physical adapters use the same MAC address and are on
isolated networks.
The NDIS packet filters are set to non-zero values for both
the virtual and physical adapters.
I am using an Intel dual port gigabit Ethernet card and I don’t have
the source code for the miniport driver.
All suggestions are appreciated.
Craig
The basic idea behind a 1:N MUX is that there are N real adapters and only one virtual adapter. Only the one virtual adapter is actually bound to TCP/IP, etc.
One common approach is to identify one of the N real adapters as the “primary adapter”. The one-and-only MUX virtual adapter is layered over the primary adapter. All other real adapters are called “secondary”. The call to NdisMSetMiniportSecondary establishes the relationship between the primary and secondary adapters. Protocol drivers can only bind to the MUX primary adapter. All bindings to MUX secondary adapters are torn down.
So, there is no reason to expect packets received on a secondary to go anywhere unless your MUX indicates it upwards on the primary.
When a packet is received on ANY of the N real adapters the 1:N MUX will indicate it upwards (by calling NdisMIndicateReceivePacket) on the PRIMARY adapter - REGARDLESS of which of the N real adapters it was actually received on.
Good luck,
Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This message has been scanned for virus, spam, and undesirable content.
For further information, contact your mail administrator.
For limitations on the use and distribution of this message, please visit www.sbs.com/emaildisclaimer.