Missing DDK Documentation in TDI drivers Section...

NTDEV
1

Hi All,

I am working on a TDI filter driver and while filtering TDI_SET_EVENT_HANDLER i am facing problems .
Actually i found the DDK Docs for Tdi Event Handlers very Confusing Specially for -
[Taken from DDK]
TDI_EVENT_RECEIVE_DATAGRAM
Register the given ClientEventReceive handler to be called when a datagram comes in from a remote node and the transport will give this client the opportunity to copy all or part of the buffered TSDU.

and for TDI_EVENT_RECIEVE it says
[taken from DDK]
TDI_EVENT_RECEIVE
Register the given ClientEventReceive handler to be called when a normal receive comes in on an endpoint-to-endpoint connection from the remote node and the transport will give the client the opportunity to copy all or part of the buffered TSDU.

From TDI_EVENT_RECIEVE Documentation i can understand that it is called for TCP based [aka. when a normal receive comes in on an endpoint-to-endpoint connection from the remote node] sockets. That means while filtering TCP device i will get these IRPs.

and from TDI_EVENT_RECIEVE_DATAGRAM documentation i can understand that it is called for UDP and RawIp based sockets [aka. called when a datagram comes in from a remote node].That means while filtering UDP and RawIp device i will get these IRPs.

But there is absolutely missing information on how and when the ClientEventRecieveDatagram is called and who sets it for recieving datagarams ? for which devices Is it called for [i mean TCP or UDP or RawIp ???].

Again after digging the tdi.h and tdikrnl.h i found these comments -
[found in tdikrnl.h]
//
// TDI_IND_RECEIVE indication handler definition. This client routine is
// called by the transport provider when a connection-oriented TSDU is received
// that should be presented to the client.
//
That means a TCP connection is needed to recieve ClientEventRecieve.As the prototype also shows by having Connection context in it as a parameter which was passed earlier while creating the connection object.

and for ClientEventRecieveDatagram i found -
[found in tdikrnl.h]
//
// TDI_IND_RECEIVE_DATAGRAM indication handler definition. This client routine
// is called by the transport provider when a connectionless TSDU is received
// that should be presented to the client.
//
That means a UDP socket or RawIp socket is needed to recieve ClientEventRecieveDatagram.As the prototype also shows by NOT having connection context in it as a parameter.

But the real question is that what TDI_EVENT_XXXX you need to set it ?
How one can filter this event handler ?
if that is not know to me then how can i filter it ?

Could anybody explain me what exactly happens while setting these event handlers ?

Any help is appreciated…

Regards…
Subodh Radheshyam Gupta

2

Gupta,

It took me time to understand what the docs say, but then
all of it makes sense and they are complete. To filter event handlers
you need to filter SetEventHandler calls and replace the client event
handler routine with your event handler routine. In your event handler
call the clients event handler. This is the only way I can see filtering
event handlers. Event handlers are nothing but call back function.
Visualize the scenario where you are giving a call back function and
asking the stack to call your function every time some event happens,
and the stack religiously calls you every time the event happens by
calling your function. That’s it there is nothing more that this in
event handlers.

Hope this helps,

Srin.

-----Original Message-----
From: subodh gupta [mailto:xxxxx@softhome.net]
Sent: Wednesday, April 23, 2003 7:22 AM
To: NT Developers Interest List
Cc: xxxxx@karchitects.com
Subject: [ntdev] Missing DDK Documentation in TDI drivers Section…

Hi All,

I am working on a TDI filter driver and while filtering
TDI_SET_EVENT_HANDLER i am facing problems .

Actually i found the DDK Docs for Tdi Event Handlers very Confusing
Specially for -

[Taken from DDK]

TDI_EVENT_RECEIVE_DATAGRAM

Register the given ClientEventReceive
mk:CT\1033\network.chm::/35tdicli_7yeq.htm> handler to be called when a
datagram comes in from a remote node and the transport will give this
client the opportunity to copy all or part of the buffered TSDU.

and for TDI_EVENT_RECIEVE it says

[taken from DDK]

TDI_EVENT_RECEIVE

Register the given ClientEventReceive
mk:CT\1033\network.chm::/35tdicli_7yeq.htm> handler to be called when a
normal receive comes in on an endpoint-to-endpoint connection from the
remote node and the transport will give the client the opportunity to
copy all or part of the buffered TSDU.

From TDI_EVENT_RECIEVE Documentation i can understand that it is called
for TCP based [aka. when a normal receive comes in on an
endpoint-to-endpoint connection from the remote node] sockets. That
means while filtering TCP device i will get these IRPs.

and from TDI_EVENT_RECIEVE_DATAGRAM documentation i can understand that
it is called for UDP and RawIp based sockets [aka. called when a
datagram comes in from a remote node].That means while filtering UDP and
RawIp device i will get these IRPs.

But there is absolutely missing information on how and when the
ClientEventRecieveDatagram is called and who sets it for recieving
datagarams ? for which devices Is it called for [i mean TCP or UDP or<br>RawIp ???].

Again after digging the tdi.h and tdikrnl.h i found these comments -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE indication handler definition. This client routine
is
// called by the transport provider when a connection-oriented TSDU is
received
// that should be presented to the client.
//

That means a TCP connection is needed to recieve ClientEventRecieve.As
the prototype also shows by having Connection context in it as a
parameter which was passed earlier while creating the connection object.

and for ClientEventRecieveDatagram i found -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE_DATAGRAM indication handler definition. This client
routine
// is called by the transport provider when a connectionless TSDU is
received
// that should be presented to the client.
//

That means a UDP socket or RawIp socket is needed to recieve
ClientEventRecieveDatagram.As the prototype also shows by NOT having
connection context in it as a parameter.

But the real question is that what TDI_EVENT_XXXX you need to set it ?

How one can filter this event handler ?

if that is not know to me then how can i filter it ?

Could anybody explain me what exactly happens while setting these event
handlers ?

Any help is appreciated…

Regards…

Subodh Radheshyam Gupta

—
You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mk:></mk:>

3

Hi Srin,

Thanks for the response…I agree with the filtering technique you described for event handlers and infact i am doint the same ,But you missed what i actually wanted to know…?

what I want to know is that for a UDP communication one must have a control channel object…Now to recieve datagrams one need to set an ClientEventReciveDatagram Event Handler on it. right ?

for TCP based communication one must have a connection object and an address object both associated with it and Needs ClientEventRecieve Event Handler to recieve these connection oriented datagrams. {atleast what i understood from docs.:-)}

Now my question is that DDK says that TDI_EVENT_RECEIVE_DATAGRAM and TDI_EVENT_RECEIVE both set a ClientEventRecieve for the client…NOT ClientEventRecieveDatagram for case 1 [connectionless TDI_EVENT_RECEIVE_DATAGRAM] and ClientEventRecieve for case 2[connection oriented TDI_EVENT_RECIEVE].

Then what is the use of having ClientEventRecieveDatagram Event handler?and how could be it set for some address or control channel ?

That’s what i want to know because if dont i know whether this event handler is actually utilized in Tdi Clients or Not ? and if yes then which type of address and / or connection objects are needed to set this event handler ?

It makes sense because if a set blindly MyCustomClientEventRecieve For every TDI_EVENT_RECIEVE_DATAGRAM and TDI_EVENT_RECIEVE It generates a DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check.That surely means that the wrong handler is being called ?

Pls throw some light on it…

Regards…

Subodh Radheshyam Gupta

----- Original Message -----
From: xxxxx@NAI.com
To: NT Developers Interest List
Cc: xxxxx@karchitects.com
Sent: Wednesday, April 23, 2003 10:18 PM
Subject: [ntdev] RE: Missing DDK Documentation in TDI drivers Section…

Gupta,

It took me time to understand what the docs say, but then all of it makes sense and they are complete. To filter event handlers you need to filter SetEventHandler calls and replace the client event handler routine with your event handler routine. In your event handler call the clients event handler. This is the only way I can see filtering event handlers. Event handlers are nothing but call back function. Visualize the scenario where you are giving a call back function and asking the stack to call your function every time some event happens, and the stack religiously calls you every time the event happens by calling your function. That’s it there is nothing more that this in event handlers.

Hope this helps,

Srin.

-----Original Message-----
From: subodh gupta [mailto:xxxxx@softhome.net]
Sent: Wednesday, April 23, 2003 7:22 AM
To: NT Developers Interest List
Cc: xxxxx@karchitects.com
Subject: [ntdev] Missing DDK Documentation in TDI drivers Section…

Hi All,

I am working on a TDI filter driver and while filtering TDI_SET_EVENT_HANDLER i am facing problems .

Actually i found the DDK Docs for Tdi Event Handlers very Confusing Specially for -

[Taken from DDK]

TDI_EVENT_RECEIVE_DATAGRAM

Register the given ClientEventReceive handler to be called when a datagram comes in from a remote node and the transport will give this client the opportunity to copy all or part of the buffered TSDU.

and for TDI_EVENT_RECIEVE it says

[taken from DDK]

TDI_EVENT_RECEIVE

Register the given ClientEventReceive handler to be called when a normal receive comes in on an endpoint-to-endpoint connection from the remote node and the transport will give the client the opportunity to copy all or part of the buffered TSDU.

From TDI_EVENT_RECIEVE Documentation i can understand that it is called for TCP based [aka. when a normal receive comes in on an endpoint-to-endpoint connection from the remote node] sockets. That means while filtering TCP device i will get these IRPs.

and from TDI_EVENT_RECIEVE_DATAGRAM documentation i can understand that it is called for UDP and RawIp based sockets [aka. called when a datagram comes in from a remote node].That means while filtering UDP and RawIp device i will get these IRPs.

But there is absolutely missing information on how and when the ClientEventRecieveDatagram is called and who sets it for recieving datagarams ? for which devices Is it called for [i mean TCP or UDP or RawIp ???].

Again after digging the tdi.h and tdikrnl.h i found these comments -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE indication handler definition. This client routine is
// called by the transport provider when a connection-oriented TSDU is received
// that should be presented to the client.
//

That means a TCP connection is needed to recieve ClientEventRecieve.As the prototype also shows by having Connection context in it as a parameter which was passed earlier while creating the connection object.

and for ClientEventRecieveDatagram i found -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE_DATAGRAM indication handler definition. This client routine
// is called by the transport provider when a connectionless TSDU is received
// that should be presented to the client.
//

That means a UDP socket or RawIp socket is needed to recieve ClientEventRecieveDatagram.As the prototype also shows by NOT having connection context in it as a parameter.

But the real question is that what TDI_EVENT_XXXX you need to set it ?

How one can filter this event handler ?

if that is not know to me then how can i filter it ?

Could anybody explain me what exactly happens while setting these event handlers ?

Any help is appreciated…

Regards…

Subodh Radheshyam Gupta

You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@softhome.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

>what I want to know is that for a UDP communication one must have a
control channel

object.

No. Address object is enough.

Max

5

Hi Subodth,

See my comments in line.

what I want to know is that for a UDP communication one must have a
control channel object…Now to recieve datagrams one need to set an
ClientEventReciveDatagram Event Handler on it. right ?

[SRIN]–> No. You do not need a control channel object for UDP
communication. You need only an address object and this is what you use
to set ClientEventReceiveDatagram Event Handler.

for TCP based communication one must have a connection object and an
address object both associated with it and Needs ClientEventRecieve
Event Handler to recieve these connection oriented datagrams. {atleast
what i understood from docs.:-)}

[SRIN] –> Yes. You are right here.

Now my question is that DDK says that TDI_EVENT_RECEIVE_DATAGRAM and
TDI_EVENT_RECEIVE both set a ClientEventRecieve for the client…NOT
ClientEventRecieveDatagram for case 1 [connectionless
TDI_EVENT_RECEIVE_DATAGRAM] and ClientEventRecieve for case 2[connection
oriented TDI_EVENT_RECIEVE ].

[SRIN] –> Could you refer to me the exact location in docs where this
is said. I read them long time before.

Then what is the use of having ClientEventRecieveDatagram Event
handler?and how could be it set for some address or control channel ?

[SRIN] –> What I have seen in practice is. UDP communication sets a
ClientEventRecevieDatagram handler on address object, and TCP
communication sets a ClientEventReceive on connection object.

That’s what i want to know because if dont i know whether this event
handler is actually utilized in Tdi Clients or Not ? and if yes then
which type of address and / or connection objects are needed to set this
event handler ?

It makes sense because if a set blindly MyCustomClientEventRecieve For
every TDI_EVENT_RECIEVE_DATAGRAM and TDI_EVENT_RECIEVE It generates a
DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check.That surely means that the wrong
handler is being called ?

[SRIN] –> There may be a bug in your code. Your event handler can be
and most probably will be called at DISPATCH_LEVEL. So, you are not
supposed to access any paged memory, mutexes, etc… The bug check you
referred to most of the time means that you are accessing paged memory
at elevated IRQL

Hope this helps,

Srin.

----- Original Message -----

From: xxxxx@NAI.com

To: NT Developers mailto:xxxxx Interest List

Cc: xxxxx@karchitects.com

Sent: Wednesday, April 23, 2003 10:18 PM

Subject: [ntdev] RE: Missing DDK Documentation in TDI drivers Section…

Gupta,

It took me time to understand what the docs say, but then
all of it makes sense and they are complete. To filter event handlers
you need to filter SetEventHandler calls and replace the client event
handler routine with your event handler routine. In your event handler
call the clients event handler. This is the only way I can see filtering
event handlers. Event handlers are nothing but call back function.
Visualize the scenario where you are giving a call back function and
asking the stack to call your function every time some event happens,
and the stack religiously calls you every time the event happens by
calling your function. That’s it there is nothing more that this in
event handlers.

Hope this helps,

Srin.

-----Original Message-----
From: subodh gupta [mailto:xxxxx@softhome.net]
Sent: Wednesday, April 23, 2003 7:22 AM
To: NT Developers Interest List
Cc: xxxxx@karchitects.com
Subject: [ntdev] Missing DDK Documentation in TDI drivers Section…

Hi All,

I am working on a TDI filter driver and while filtering
TDI_SET_EVENT_HANDLER i am facing problems .

Actually i found the DDK Docs for Tdi Event Handlers very Confusing
Specially for -

[Taken from DDK]

TDI_EVENT_RECEIVE_DATAGRAM

Register the given ClientEventReceive
mk:CT\1033\network.chm::/35tdicli_7yeq.htm> handler to be called when a
datagram comes in from a remote node and the transport will give this
client the opportunity to copy all or part of the buffered TSDU.

and for TDI_EVENT_RECIEVE it says

[taken from DDK]

TDI_EVENT_RECEIVE

Register the given ClientEventReceive
mk:CT\1033\network.chm::/35tdicli_7yeq.htm> handler to be called when a
normal receive comes in on an endpoint-to-endpoint connection from the
remote node and the transport will give the client the opportunity to
copy all or part of the buffered TSDU.

From TDI_EVENT_RECIEVE Documentation i can understand that it is called
for TCP based [aka. when a normal receive comes in on an
endpoint-to-endpoint connection from the remote node] sockets. That
means while filtering TCP device i will get these IRPs.

and from TDI_EVENT_RECIEVE_DATAGRAM documentation i can understand that
it is called for UDP and RawIp based sockets [aka. called when a
datagram comes in from a remote node].That means while filtering UDP and
RawIp device i will get these IRPs.

But there is absolutely missing information on how and when the
ClientEventRecieveDatagram is called and who sets it for recieving
datagarams ? for which devices Is it called for [i mean TCP or UDP or<br>RawIp ???].

Again after digging the tdi.h and tdikrnl.h i found these comments -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE indication handler definition. This client routine
is
// called by the transport provider when a connection-oriented TSDU is
received
// that should be presented to the client.
//

That means a TCP connection is needed to recieve ClientEventRecieve.As
the prototype also shows by having Connection context in it as a
parameter which was passed earlier while creating the connection object.

and for ClientEventRecieveDatagram i found -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE_DATAGRAM indication handler definition. This client
routine
// is called by the transport provider when a connectionless TSDU is
received
// that should be presented to the client.
//

That means a UDP socket or RawIp socket is needed to recieve
ClientEventRecieveDatagram.As the prototype also shows by NOT having
connection context in it as a parameter.

But the real question is that what TDI_EVENT_XXXX you need to set it ?

How one can filter this event handler ?

if that is not know to me then how can i filter it ?

Could anybody explain me what exactly happens while setting these event
handlers ?

Any help is appreciated…

Regards…

Subodh Radheshyam Gupta

—
You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@softhome.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mk:></mk:></mailto:xxxxx>

6

Hi Srin ,
See My Comments Inline…
----- Original Message -----
From: xxxxx@NAI.com
To: NT Developers Interest List
Cc: xxxxx@karchitects.com
Sent: Thursday, April 24, 2003 11:40 PM
Subject: [ntdev] RE: Missing DDK Documentation in TDI drivers Section…

Hi Subodth,

See my comments in line.

what I want to know is that for a UDP communication one must have a control channel object…Now to recieve datagrams one need to set an ClientEventReciveDatagram Event Handler on it. right ?

[SRIN]? No. You do not need a control channel object for UDP communication. You need only an address object and this is what you use to set ClientEventReceiveDatagram Event Handler.

[Subodh]- Hmmm,Yeah you are right.

for TCP based communication one must have a connection object and an address object both associated with it and Needs ClientEventRecieve Event Handler to recieve these connection oriented datagrams. {atleast what i understood from docs.:-)}

[SRIN] ? Yes. You are right here.

Now my question is that DDK says that TDI_EVENT_RECEIVE_DATAGRAM and TDI_EVENT_RECEIVE both set a ClientEventRecieve for the client…NOT ClientEventRecieveDatagram for case 1 [connectionless TDI_EVENT_RECEIVE_DATAGRAM] and ClientEventRecieve for case 2[connection oriented TDI_EVENT_RECIEVE].

[SRIN] ? Could you refer to me the exact location in docs where this is said. I read them long time before.

[Subodh]- Sure.Just look TDI_SET_EVENT_HANDLER Documentation. and pay attention to TDI_EVENT_RECIEVE_DATAGRAM and TDI_EVENT_RECIEVE in it. it is located in the" TDI IOCTLs for Transport Drivers section".

and also see “Sending and Receiving Connectionless Data” first paragraph in “Tdi Operations” section in Network Drivers design guide.

Then what is the use of having ClientEventRecieveDatagram Event handler?and how could be it set for some address or control channel ?

[SRIN] ? What I have seen in practice is. UDP communication sets a ClientEventRecevieDatagram handler on address object, and TCP communication sets a ClientEventReceive on connection object.

[Subodh]-Yes, What i see in TDImon Output is that the clients can create the control channel or address object by either using IoGetDeviceObjectPointer to get the file object associated with any of the Tcp, RawIp or UDP device and start using it directly, or use IRP_MJ_CREATE [on either TCP,RawIp Or UDP] for explicitly creating a control channel object [for sending and recieving UDP or RawIp Datagrams]. and start connectionless communication by using TDI_SEND_DATAGRAM and Setting a ClientEventRecieveDatagram. Is my observation correct ?

Or then later May choose to either Associate it with Connection Object for TCP based connection orieted communication set the ClientEventRecieve on it.

Now this is the point where Filter driver can decide that which protocol is to be utilized for the communication. Am i right ?.Because if client chooses to use TDI_SEND_DATAGRAM without creating a connection object and associating it to address object in hand ,it indicates UDP or RawIp protocol based communication and if client chooses to employ TDI_SEND and ClientEventRecieve, it indicates TCP based connection oriented communcation [along with the creation of connection object and association of address with it.].isnt it ?

That’s what i want to know because if dont i know whether this event handler is actually utilized in Tdi Clients or Not ? and if yes then which type of address and / or connection objects are needed to set this event handler ?

It makes sense because if a set blindly MyCustomClientEventRecieve For every TDI_EVENT_RECIEVE_DATAGRAM and TDI_EVENT_RECIEVE It generates a DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check.That surely means that the wrong handler is being called ?

[SRIN] ? There may be a bug in your code. Your event handler can be and most probably will be called at DISPATCH_LEVEL. So, you are not supposed to access any paged memory, mutexes, etc… The bug check you referred to most of the time means that you are accessing paged memory at elevated IRQL

[Subodh]- Hmmm, I Looked in to this possibility also and could not found any thing like that in the code. If you will allow me i would like show you the code .

Hope this helps,

Srin.

thanks for the help…

Pls do revert back…

Regrards…

Subodh Radheshyam Gupta

----- Original Message -----

From: xxxxx@NAI.com

To: NT Developers Interest List

Cc: xxxxx@karchitects.com

Sent: Wednesday, April 23, 2003 10:18 PM

Subject: [ntdev] RE: Missing DDK Documentation in TDI drivers Section…

Gupta,

It took me time to understand what the docs say, but then all of it makes sense and they are complete. To filter event handlers you need to filter SetEventHandler calls and replace the client event handler routine with your event handler routine. In your event handler call the clients event handler. This is the only way I can see filtering event handlers. Event handlers are nothing but call back function. Visualize the scenario where you are giving a call back function and asking the stack to call your function every time some event happens, and the stack religiously calls you every time the event happens by calling your function. That’s it there is nothing more that this in event handlers.

Hope this helps,

Srin.

-----Original Message-----
From: subodh gupta [mailto:xxxxx@softhome.net]
Sent: Wednesday, April 23, 2003 7:22 AM
To: NT Developers Interest List
Cc: xxxxx@karchitects.com
Subject: [ntdev] Missing DDK Documentation in TDI drivers Section…

Hi All,

I am working on a TDI filter driver and while filtering TDI_SET_EVENT_HANDLER i am facing problems .

Actually i found the DDK Docs for Tdi Event Handlers very Confusing Specially for -

[Taken from DDK]

TDI_EVENT_RECEIVE_DATAGRAM

Register the given ClientEventReceive handler to be called when a datagram comes in from a remote node and the transport will give this client the opportunity to copy all or part of the buffered TSDU.

and for TDI_EVENT_RECIEVE it says

[taken from DDK]

TDI_EVENT_RECEIVE

Register the given ClientEventReceive handler to be called when a normal receive comes in on an endpoint-to-endpoint connection from the remote node and the transport will give the client the opportunity to copy all or part of the buffered TSDU.

From TDI_EVENT_RECIEVE Documentation i can understand that it is called for TCP based [aka. when a normal receive comes in on an endpoint-to-endpoint connection from the remote node] sockets. That means while filtering TCP device i will get these IRPs.

and from TDI_EVENT_RECIEVE_DATAGRAM documentation i can understand that it is called for UDP and RawIp based sockets [aka. called when a datagram comes in from a remote node].That means while filtering UDP and RawIp device i will get these IRPs.

But there is absolutely missing information on how and when the ClientEventRecieveDatagram is called and who sets it for recieving datagarams ? for which devices Is it called for [i mean TCP or UDP or RawIp ???].

Again after digging the tdi.h and tdikrnl.h i found these comments -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE indication handler definition. This client routine is
// called by the transport provider when a connection-oriented TSDU is received
// that should be presented to the client.
//

That means a TCP connection is needed to recieve ClientEventRecieve.As the prototype also shows by having Connection context in it as a parameter which was passed earlier while creating the connection object.

and for ClientEventRecieveDatagram i found -

[found in tdikrnl.h]

//
// TDI_IND_RECEIVE_DATAGRAM indication handler definition. This client routine
// is called by the transport provider when a connectionless TSDU is received
// that should be presented to the client.
//

That means a UDP socket or RawIp socket is needed to recieve ClientEventRecieveDatagram.As the prototype also shows by NOT having connection context in it as a parameter.

But the real question is that what TDI_EVENT_XXXX you need to set it ?

How one can filter this event handler ?

if that is not know to me then how can i filter it ?

Could anybody explain me what exactly happens while setting these event handlers ?

Any help is appreciated…

Regards…

Subodh Radheshyam Gupta

You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@softhome.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@softhome.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Hi Max,

Yeah,My mistake Max.Address object is enogh.
Pls shed some light on the problem in this mail.
Regards…
Subodh

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Thursday, April 24, 2003 9:38 PM
Subject: [ntdev] RE: Missing DDK Documentation in TDI drivers Section…

> >what I want to know is that for a UDP communication one must have a
> control channel
> >object.
>
> No. Address object is enough.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@softhome.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

8

You’re asking these questions in more than one group, which confuses
things. At least point to all the groups in a single posting.

Anyway, you may want to look at, and play with, TCIClient.zip at
http://home.mindspring.com/~antognini/drivers/.

A more fundamental question: Why the interest in filtering TDI activity?
For a general solution, which I assume you’re aiming at, doesn’t one
want an NDIS filter? If I’m completely off-base in thinking this,
please, someone, tell me and explain.

–
If replying by e-mail, please remove “nospam.” from the address.

James Antognini

9

Hi James,
Naaaaaaaaa,i dont think it may confuse someone…infact having views from
Gurus from all the sides is benificial for me.{one of the reasons of posting
at several places is that i am not sure where i will get the desired answer
as on comp.ms you have totally missed what i am trying to know about…Srin
and thomas both have replied up to certain extent what i am really confused
about and both at different groups…:)}All you need is to go back and read
all the postings so that the confusion may get cleared…
Now the answer to the fundamental question , i am working on a TDI based
firewall…One of the primary requirements is controlling program’s socket
endpoints on the current system…and not allowing the process to even create
a socket endpoint that is the reason i have to choose TDI to filter.{just
like zone alarm}…
I looked in to the NDIS filter earlier but i found it very difficult (using
documented ways) to know the program name and / or process id at NDIS
level…and then controlling accordingly them…
Hope this helps…
Regards…
Subodh Radheshyam Gupta

----- Original Message -----
From: “James Antognini”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Friday, April 25, 2003 11:00 PM
Subject: [ntdev] Re: Missing DDK Documentation in TDI drivers Section…

> You’re asking these questions in more than one group, which confuses
> things. At least point to all the groups in a single posting.
>
> Anyway, you may want to look at, and play with, TCIClient.zip at
> http://home.mindspring.com/~antognini/drivers/.
>
> A more fundamental question: Why the interest in filtering TDI activity?
> For a general solution, which I assume you’re aiming at, doesn’t one
> want an NDIS filter? If I’m completely off-base in thinking this,
> please, someone, tell me and explain.
>
> –
> If replying by e-mail, please remove “nospam.” from the address.
>
> James Antognini
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@softhome.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

10

Hi Subodth,

Sorry for replying late, I am busy and frustrated in getting
up WinCE 3.0 up with PB 3.0. Coming back to your questions see my
comments.

[Subodh]- Sure.Just look TDI_SET_EVENT_HANDLER Documentation. and pay
attention to TDI_EVENT_RECIEVE_DATAGRAM and TDI_EVENT_RECIEVE in it. it
is located in the" TDI IOCTLs for Transport Drivers section".

and also see “Sending and Receiving Connectionless Data” first
paragraph in “Tdi Operations” section in Network Drivers design guide.

[SRIN] –> I believe the first reference you pointed out is an error in
the documentation. The second reference looks good to me. Correct me if
I am wrong…ClientEventReceive call back takes the second parameter as
ConnectionContext. I believe this would not be possible with the address
object. I never tested the other path but see if you could open a UDP
address object, UDP connection object and associate the connection
object with address object and register a ClientEventReceive handler on
this. This would mean you are interested in UDP datagrams but only from
a specific sender.

[Subodh]-Yes, What i see in TDImon Output is that the clients can
create the control channel or address object by either using
IoGetDeviceObjectPointer to get the file object associated with any of
the Tcp, RawIp or UDP device and start using it directly, or use
IRP_MJ_CREATE [on either TCP,RawIp Or UDP] for explicitly creating a
control channel object [for sending and recieving UDP or RawIp
Datagrams]. and start connectionless communication by using
TDI_SEND_DATAGRAM and Setting a ClientEventRecieveDatagram. Is my
observation correct ?

[SRIN] –> My knowledge regarding control objects is rusted.

Now this is the point where Filter driver can decide that which protocol
is to be utilized for the communication. Am i right ?.Because if client
chooses to use TDI_SEND_DATAGRAM without creating a connection object
and associating it to address object in hand ,it indicates UDP or RawIp
protocol based communication and if client chooses to employ TDI_SEND
and ClientEventRecieve, it indicates TCP based connection oriented
communcation [along with the creation of connection object and
association of address with it.].isnt it ?

[SRIN] –> I would not decide the protocol based on the type of event
handler, instead I would use the file object on which the
SetEventHandler is received to know which protocol is being used. Using
the file object you could find the device object and the device object
would tell you which protocol it belongs too.

[Subodh]- Hmmm, I Looked in to this possibility also and could not
found any thing like that in the code. If you will allow me i would like
show you the code .

[SRIN] –> Subodth, did you debug the code using windbg? Do you know
where the code is crashing? Is it in your routines or is it crashing in
tcpip dispatch routines?

Hope this helps,

Srin.