Enabling/Disabling NDIS 5.1 Intermediate Miniport ( 1-2 Mux)
in [Device Drivers]
|
Prev: Problem while performing StretchBlt on HP 1010, HP 1018, HP 1020 and HP 3050
Next: DDK version question
From: Wes on 6 May 2008 13:16 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
From: Pavel A. on 6 May 2008 17:01 Try to find another consultant. Good luck, --PA "Wes" <muleskynnrDOTgmail.com> wrote in message news:DA454EEA-06D9-43BC-8F3A-8E025825C3A7(a)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 >
From: Alireza Dabagh [MS] on 8 May 2008 23:12
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(a)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 > |