Hi,
I have to to complete the development of a Mux written by a now departed
consultant and which is probably 98% right. No experience or training in
driver development, so I WILL use the wrong terms in phrasing my questions.

This MUX is designed to be bound only to Ethernet NICs.

When the NICs are bound to the MUX, all other protocols are unbound from the
NICs so that after the user binds whatever protocols he chooses to the MUX,
the protocols-originated packets must pass thru the MUX, possibly undergo
changes, and then get forwarded to both NICs.

When the MUX is Disabled thru the Network Connections, it apparently does
enough to convince NDIS that it is disabled and the "Status" field reflects
that. When an attempt to "Enable" the MUX, the first thing that happens is
that the ProtocolReceive or ProtocolReceivePacket function gets a packet sent
up from one of the bound NICs and eventually BSODs in the call to
NdisMIndicateReceivePacket. My guess is that the MUX does more than what is
required in response to the DISABLE command and frees up too many resources
required for the ENABLE command.

What does NDIS do or call in the protocol side of the MUX to disable it and
what is the minimum required by the MUX to comply?

What happens when an IM is Enabled? Since the packet reception is the first
and last thing I see with WinDbg, I don't know what ENABLING function, if
any, would eventually be called and what it should do.

What's the best way to block the receipt of packets until the IM has
completed the enable process?

THX
Wes

Re: Enabling/Disabling NDIS 5.1 Intermediate Miniport ( 1-2 Mux) by Pavel

Pavel
Tue May 06 16:01:18 CDT 2008

Try to find another consultant.

Good luck,
--PA


"Wes" <muleskynnrDOTgmail.com> wrote in message
news:DA454EEA-06D9-43BC-8F3A-8E025825C3A7@microsoft.com...
> Hi,
> I have to to complete the development of a Mux written by a now departed
> consultant and which is probably 98% right. No experience or training in
> driver development, so I WILL use the wrong terms in phrasing my
> questions.
>
> This MUX is designed to be bound only to Ethernet NICs.
>
> When the NICs are bound to the MUX, all other protocols are unbound from
> the
> NICs so that after the user binds whatever protocols he chooses to the
> MUX,
> the protocols-originated packets must pass thru the MUX, possibly undergo
> changes, and then get forwarded to both NICs.
>
> When the MUX is Disabled thru the Network Connections, it apparently does
> enough to convince NDIS that it is disabled and the "Status" field
> reflects
> that. When an attempt to "Enable" the MUX, the first thing that happens
> is
> that the ProtocolReceive or ProtocolReceivePacket function gets a packet
> sent
> up from one of the bound NICs and eventually BSODs in the call to
> NdisMIndicateReceivePacket. My guess is that the MUX does more than what
> is
> required in response to the DISABLE command and frees up too many
> resources
> required for the ENABLE command.
>
> What does NDIS do or call in the protocol side of the MUX to disable it
> and
> what is the minimum required by the MUX to comply?
>
> What happens when an IM is Enabled? Since the packet reception is the
> first
> and last thing I see with WinDbg, I don't know what ENABLING function, if
> any, would eventually be called and what it should do.
>
> What's the best way to block the receipt of packets until the IM has
> completed the enable process?
>
> THX
> Wes
>

Re: Enabling/Disabling NDIS 5.1 Intermediate Miniport ( 1-2 Mux) by Alireza

Alireza
Thu May 08 22:12:08 CDT 2008

First I like to second the suggestion made by Pavel.

Second, you really need to use the right terminology before anybody can
answer your question without a lot of second guessing on what you did and
what you meant to ask.

A MUX driver has two edges. A protocol edge that registers with NDIS as a
protocol driver and binds to one or more underlying physical adapter(s) and
a miniport edge that registers with NDIS as an NDIS miniport driver and
exposes one or more virtual miniport adapter(s).

You can disable/enable virtual miniport adapters or you can unbind the MUX
protocol from underlying physical adapters. There is no such thing as
"disabling MUX or disabling IM". You may have meant "disabling MUX miniport
adapter", or you may have meant "unbinding the MUX protocol from the
underlying physical adapter" by unchecking the box next to protocol name in
network control panel or you may have meant "uninstalling the MUX protocol".

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Wes" <muleskynnrDOTgmail.com> wrote in message
news:DA454EEA-06D9-43BC-8F3A-8E025825C3A7@microsoft.com...
> Hi,
> I have to to complete the development of a Mux written by a now departed
> consultant and which is probably 98% right. No experience or training in
> driver development, so I WILL use the wrong terms in phrasing my
> questions.
>
> This MUX is designed to be bound only to Ethernet NICs.
>
> When the NICs are bound to the MUX, all other protocols are unbound from
> the
> NICs so that after the user binds whatever protocols he chooses to the
> MUX,
> the protocols-originated packets must pass thru the MUX, possibly undergo
> changes, and then get forwarded to both NICs.
>
> When the MUX is Disabled thru the Network Connections, it apparently does
> enough to convince NDIS that it is disabled and the "Status" field
> reflects
> that. When an attempt to "Enable" the MUX, the first thing that happens
> is
> that the ProtocolReceive or ProtocolReceivePacket function gets a packet
> sent
> up from one of the bound NICs and eventually BSODs in the call to
> NdisMIndicateReceivePacket. My guess is that the MUX does more than what
> is
> required in response to the DISABLE command and frees up too many
> resources
> required for the ENABLE command.
>
> What does NDIS do or call in the protocol side of the MUX to disable it
> and
> what is the minimum required by the MUX to comply?
>
> What happens when an IM is Enabled? Since the packet reception is the
> first
> and last thing I see with WinDbg, I don't know what ENABLING function, if
> any, would eventually be called and what it should do.
>
> What's the best way to block the receipt of packets until the IM has
> completed the enable process?
>
> THX
> Wes
>