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