TDI question about connects

NTDEV
1

I’m wondering about ClientEventConects …
Lets consider atguard
It’s known fact, that it can intersept incoming connects and to
indicate to UserModeApp about it.
If I’m not mistaken, this can be done at PASSIVE_LEVEL only. but
ClientEventConnect occures at DISPATCH_LEVEL.
How does atguard solve this problem, I wonder ???

Could You say a few words about it ?

thanks in advance !!!
Foxgen.

2

Hi,

Why don’t you try to call TDI stuff at DISPATCH_LEVEL?

Regards,
Anton Kolomyeytsev

3

> If I’m not mistaken, this can be done at PASSIVE_LEVEL only. but

No. This usually requires completing the app’s IRP. This can be done on DISPATCH_LEVEL.

Max

4

I want this task to be done by UserModeApp …
that’s why DISPATCH_LEVEL is unacceptable … :frowning:

AK> Why don’t you try to call TDI stuff at DISPATCH_LEVEL?

AK> Regards,
AK> Anton Kolomyeytsev

AK> —
AK> You are currently subscribed to ntdev as: xxxxx@yandex.ru
AK> To unsubscribe send a blank email to %%email.unsub%%

–
Best regards,
foxgen mailto:xxxxx@yandex.ru

5

At 14.26 11/04/2002, you wrote:

I’m wondering about ClientEventConects …
Lets consider atguard
It’s known fact, that it can intersept incoming connects and to indicate
to UserModeApp about it.
If I’m not mistaken, this can be done at PASSIVE_LEVEL only. but
ClientEventConnect occures at DISPATCH_LEVEL.
How does atguard solve this problem, I wonder ???

I don’t know the NT I/O manager good enough, but I think it goes like this:

  • the event handler puts the request on hold, and queues the pending
    request in some internal queue (or delegates the operation to a worker
    thread, if it’s too time-expensive)
  • the administration service tries to read the next request in the queue
    from the appropriate device object. It parses the request and decides its
    fate, and communicates its decision through the device object
  • the dispatcher of the device object finally accepts/refuses/ignores the
    request

It’s the “put on hold” part that I’m not sure about

6

> I don’t know the NT I/O manager good enough, but I think it goes like this:

This is not NT IO, this is TDI which is a different thing. IO manager has no “event handlers”.

The reality is:

  • ClientEventConnect is called by TCPIP on “incoming connection offer” (cite from DDK) - i.e. on SYN packet arrival.
  • if the client wants to accept the connection, it must find some preallocated connection file object (from listen backlog),
    assemble a TDI_ACCEPT IRP with this file object, register a completion routine in it and return it to TCPIP. Note that
    IoCallDriver is never used for TDI_ACCEPT.
  • the completion routine from TDI_ACCEPT is called when the connection is fully established or failed.

Max