Re: Problem with matching kind of NDIS driver.
- From: Anton Bassov <AntonBassov@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 10 Jul 2007 13:16:00 -0700
We are telling you that in a NDIS Intermediate (IM) driver the process
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.
Apparently, the OP just does not want to take NO as an answer (which is 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 has
invented some new APIs that may be of help there.
Again, process context is available only at some certain filtering 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....
Anton Bassov
"Thomas F. Divine" wrote:
I think we understand what you want..
We are telling you that in a NDIS Intermediate (IM) driver the process
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.
Process information is only available at higher layers when the process
information is actually valid.
For all protocols that use TDI you can use a TDI filter to identify the
process. Even in TDI process information is only actually valid ad a few
specific moments. In particular, you can only actually identify the process
at the point that objects are initially created. You must keep a database of
process information around if you want to know PID later.
Going further, it is certainly possible for folks to write a NDIS protocol
that operates solely in the kernel attached to the system process. All you
will know is that "the system" sent the packet.
Good luck. It is a project that Windows simply isn't designed to support
conveniently.
Perhaps you would have better luck if you only worked on Vista. MS has
invented some new APIs that may be of help there.
Thomas F. Divine
"Witoslaw Jozewicz" <wj78[NoSpaM](at)wp.pl> wrote in message
news:uGeIbCywHHA.1484@xxxxxxxxxxxxxxxxxxxxxxx
"mirage2k2" <mirage2k2@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E5F3B882-1DD7-45A2-909D-97DC4E02FECD@xxxxxxxxxxxxxxxx
With TDI driver and NDIS IM you can match traffic to PID via port number
only. What does your driver really need to do? If you need to queue
That is them of my Master of Science Job, I have to find a way how to
solve that problem on NDIS driver layer.
packets then you must use NDIS IM driver. If you just want to
sniff/modify packets then there are some other options, i.e. filter
hook, etc. Note also that you will not see any packets in the TDI
driver, rather you see IOCTRLs for operations such as connect, send,
receive, etc. Filtering such commands will allow you to obtain
PID/TID, port numbers and for some, remote ip addresses. Mirage2k2
I need a driver which will catch all packets going through network card,
find PID's for that, and sends all the informations for application on
users layer (that application will be logging all network activieties - it
has to work as the "netstat -anb" application but in real time). Thanks
for your advices, Mirage2k2.
--
With regards
thanks,
Witek
- Follow-Ups:
- Re: Problem with matching kind of NDIS driver.
- From: Witoslaw Jozewicz
- Re: Problem with matching kind of NDIS driver.
- 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
- Problem with matching kind of NDIS driver.
- Prev by Date: Re: WinXP USB BULK mode High speed
- Next by Date: What is the Proper Newsgroup to ask Driver Installation Questions?
- 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
|
