Re: Problem with matching kind of NDIS driver.
- From: "Witoslaw Jozewicz" <wj78[NoSpaM](at)wp.pl>
- Date: Wed, 11 Jul 2007 20:41:02 +0200
"Anton Bassov" <AntonBassov@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:40E794CB-F50D-46CC-9312-E96B5091394D@xxxxxxxxxxxxxxxx
We are telling you that in a NDIS Intermediate (IM) driver the processApparently, the OP just does not want to take NO as an answer (which is
information simply is not available. This is because NDIS calls (such
as the call to your drivers MPSendPackets...) are made in "arbitrary
thread context". This means that the process information of the
sender simply does cannot be found from the information available in
that call.
good thing in itself). The best thing to do here is to explain to him
WHY his task in infeasible....
When it comes to outgoing packets, the reasons why his task is infeasible
are different for TCP and datagram-based protocols. Once TCP guarantees
delivery of packets in specified order, any TCP operation involves both
sending and receiving data, so that TCPIP will send part of the
transmission and wait for the confirmation from the counter-party
before sending the next part. Therefore, different parts of the same
transmission may get sent in context of different threads.
When it comes to datagrams, the situation is somehow different - once
datagrams never get fragmented, TCPIP always sends them in context of the
client thread. Therefore, NDIS IM filter that is located immediately
below TCPIP will
get these packets in context of the client thread. However, there is no
guarantee that all lower-level will be able to do the same - everything
depends on how the highest-level IM decides to proceed. Taking into
account that highest-level IM filters are packet schedulers, in
practical terms you cannot expect to receive packets in context of the
same thread in lower-level filters.
The above applies to sends. When it comes to receives, incoming packet
may arrive at any moment, so that IM filter cannot expect to receive it
in context of any particular thread, for understandable reasons,
regardless of protocol.
Hopefully, the above explanation is going to convince the OP that his
task is simply infeasible....
Perhaps you would have better luck if you only worked on Vista. MS hasAgain, process context is available only at some certain filtering
invented some new APIs that may be of help there.
levels. For example,
at the level of IP packets (i.e. internal sends and raw socket-related
traffic) you have no chance to relate a packet to its sender process,
although you can do it at higher filtering levels....
Thank you for your exhaustive explanations.
--
With regards
thanks,
Witek
.
- References:
- Problem with matching kind of NDIS driver.
- From: Witoslaw Jozewicz
- Re: Problem with matching kind of NDIS driver.
- From: Witoslaw Jozewicz
- Re: Problem with matching kind of NDIS driver.
- From: Thomas F. Divine
- Re: Problem with matching kind of NDIS driver.
- From: Anton Bassov
- Problem with matching kind of NDIS driver.
- Prev by Date: Re: Problem with matching kind of NDIS driver.
- Next by Date: Re: WinXP USB BULK mode High speed
- Previous by thread: Re: Problem with matching kind of NDIS driver.
- Next by thread: Re: Problem with matching kind of NDIS driver.
- Index(es):
Relevant Pages
|