I have been perplexed by a strange issue in an IM driver and was wondering
if perhaps anyone could confirm my suspicions. The platform is WinXP and
this occurs with both RTM and SP1 builds. The symptom was reported (to me)
on SP1, reproduced on RTM, and then debugged (with reproduction) on the RMT
Checked build.
In the upper miniport of my IM driver the following occurs:
-
NDIS calls my MiniportInitialize() to (among other things) discover the
selected media type. MiniportInitialize completes and returns Ethernet. -
Shortly after returning from MiniportInitialize(), my IM driver indicates
that media is disconnected via NdisMIndicateStatus(). -
At some point later, my IM driver indicates that media is connected via
NdisMInidicateStatus(). -
At this point, any packet my IM driver indicates via
NdisMIndicatePacket() is *not* delivered to bound protocols.
Under the covers:
It would appear that NDIS swaps the fields PacketIndicateHandler and
SavedPacketIndicateHandler (both in the _NDIS_MINIPORT_BLOCK) when media
connect indications occur. The idea apparently being to setup an internal
NDIS routine ndisMDummyIndicatePacket() in the PacketIndicateHandler field
whenever the media is disconnected and to set it back to the original value
whenever media is connected.
It would also appear that these two field are initialized in the internal
routine ndisMInitializeAdapter() which calls the MiniportInitialize()
handler to do the adapter specific work and return a media type.
DDK docs suggest that calling NdisMIndicateStatus() is acceptable during
MiniportIntialize() as long as the miniport is deserialized (makes sense)
which this one is.
DDK docs make no mention that I can find that one must refrain from calling
NdisMIndicateStatus() *after* MiniportInitialize() and prior to
MiniportHalt() for any reason (in the case of a deserialzed miniport).
After (3) above (indicating that media is connected) the
_NDIS_MINIPORT_BLOCK forever has the bit-bucket ndisMDummyIndicatePacket()
as the value of the PacketIndicateHandler field (and as well the
SavedPacketIndicateHandler field too!). This sure would explain why my
packets never make it to any bound protocols.
Remedies?
Ok, so a 2 second delay after MiniportInitialize() completes before allowing
any media connect indications prevents this from occurring but geez, what a
hack!
Is there some requirement I am missing on when NDIS is ready for my miniport
to indicate status changes? Should I be waiting for some particular OID
query/set or other handler call?
Perhaps this is just a synchronization bug in the miniport code of NDIS?
Thanks all,
-dave cattley
David R. Cattley
Consulting Engineer
Systems Software Development
mailto:xxxxx@msn.com
Tel: +1 (508) 847-0487