Re:NDIS Irda protocol driver
- From: "anton bassov"<xxx@xxxxxxx>
- Date: Thu, 30 Mar 2006 06:07:21 -0600
Hi mate
I have a feeling that missing packets get lost somewhere
in between miniport driver's indication of packets to NDIS library and NDIS
library's notification of your driver about incoming packets.
At this point one important question arises- what do you mean by the term
"miniport"??? If your protocol driver is bound to NDIS IM, then, as far as
your protocol driver is concerned, NDIS IM is miniport - your driver does
not deal with actual miniport driver, does it??? I think that NDIS IM may
be a culprit - it sometimes fails to inform your driver about incoming
packet, but always informs it about the completion. This explains the
mismatch between ProtocolReceive() and ProtocolReceiveComplete() calls.
Strictly speaking, the software that plays this trick does not necessarily
have to be a conventional NDIS IM - it can take NDIS-hooking approach, which
may be the case if your target machine has some third-party AV/PF software
installed.
I would advise you to solve the problem via NDIS hooking ( I predict an
awful lot of outraged messages on this thread, but let me do it anyway). You
can do the following:
1. When your driver calls miniport functions, it passes
an opaque NDIS_HANDLE( which has been returned by NdisOpenAdapter()), as an
argument. Cast this handle to
PNDIS_OPEN_BLOCK
2. Cast the resulting openblock's AdapterHandle member to
PNDIS_MINIPORT_BLOCK (this member points to NDIS_MINIPORT_BLOCK, rather
than to NDIS_ADAPTER_BLOCK -
declaration of NDIS_OPEN_BLOCK in ndis.h is a bit buggy).
3. Walk the chain of miniports, until you arrive to the point when
PNDIS_MINIPORT_BLOCK's NextMiniport member is NULL. At this point you will
arrive to the ACTUAL miniport
( don't forget that your driver may be bound to NDIS IM, rather than to
actual miniport)
All the above can be summarized with the following lines
(Handle is NDIS_HANDLE that has been returned by NdisOpenAdapter()):
PNDIS_MINIPORT_BLOCK miniport=(PNDIS_MINIPORT_BLOCK)((PNDIS_OPEN_BLOCK)
Handle)->AdapterHandle;
while(miniport->NextMiniport)miniport=miniport->NextMiniport;
4. Now, once you got a pointer to underlying miniport, you can replace
NdisMndicate....()member with the address of your proxy function. Which
member do you have to replace??? It depends on underlying media
(EthRxIndicateHandler if indication is done by NdisMEthIndicateReceive();
TrRxIndicateHandler if indication is done by NdisMTrIndicateReceive();etc...)
Looks at ndis.h for more info
As a result, you will be able to capture all packets right at the moment
when ACTUAL miniport driver indicates them to NDIS library.
As you can see, we don't have to deal with any undeclared structers or
functions here. Therefore, this approach is perfectly safe(although this is
still "unsupported technology")
Regards
Anton Bassov
.
- Prev by Date: Re: MSN Messenger
- Next by Date: Re: MSN Messenger
- Previous by thread: Re: Executing cscript
- Next by thread: Hook Windows Events
- Index(es):
Relevant Pages
|
Loading
