Hi All,
Please can someone give me some information on how to associate the Address File Object and the Connection Endpoint file Object, which are created when a connection is requested at the TDI layer. I am not building a snoop or anything of the sort but need to be able to intercept data at the tdi level.
your help would really be appreciated.
Thanks
Justin
Click here to get your free domain name
and personal portal from NAMEzero™:
http://www.namezero.com
Justin,
Unfortunately, filtering TDI is fairly messy. In addition, there are no
standard reference samples that we can talk to. PCAUSA licenses some, but
that doesn’t help you.
From reading your previous messages it appears that at least one of your
problems seems to be how to relate the ConnectionContext in an Event
callback to something meaningful.
The steps that work for us include:
1.) Filter creation of address objects. Create a structure in the TDI filter
to track each created address object.
2.) Filter SetEvent calls on each address object. In this filter we save the
original caller’s EventHandler and EventContext and replace both with our
own proxies. This info is saved in our address object tracking structure.
3.) When an event callback is made it goes to our hook. There we lookup our
proxy EventContext to find the unfiltered EventContext, the unfiltered
EventHandler and, or course, the address object.
Hope this helps a little.
Regards,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:
----- Original Message -----
From: justin white
To: NT Developers Interest List
Sent: Thursday, October 26, 2000 3:39 AM
Subject: [ntdev] TDI Question
> Hi All,
>
> Please can someone give me some information on how to associate the
Address File Object and the Connection Endpoint file Object, which are
created when a connection is requested at the TDI layer. I am not building a
snoop or anything of the sort but need to be able to intercept data at the
tdi level.
>
> your help would really be appreciated.
>
> Thanks
> Justin
></http:>
Thanks,
I have found that the TDI filtering is quite messy. I also save the original address object in my event handler and so can easily get to it when my event is called. Unfortunately the ConnectionContext receive in the call does not correlate to any other context I ‘see’ previously (like from a TDI_CONNECT for instance). This also leads to my next question, why is TDI_ASSOCIATE_ADDRESS not always called. According to the TDI spec, it should be called.
On Thu, 26 October 2000, “Thomas F. Divine” wrote:
Justin,
Unfortunately, filtering TDI is fairly messy. In addition, there are no
standard reference samples that we can talk to. PCAUSA licenses some, but
that doesn’t help you.From reading your previous messages it appears that at least one of your
problems seems to be how to relate the ConnectionContext in an Event
callback to something meaningful.The steps that work for us include:
1.) Filter creation of address objects. Create a structure in the TDI filter
to track each created address object.
2.) Filter SetEvent calls on each address object. In this filter we save the
original caller’s EventHandler and EventContext and replace both with our
own proxies. This info is saved in our address object tracking structure.
3.) When an event callback is made it goes to our hook. There we lookup our
proxy EventContext to find the unfiltered EventContext, the unfiltered
EventHandler and, or course, the address object.Hope this helps a little.
Regards,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:
>
> ----- Original Message -----
> From: justin white
> To: NT Developers Interest List
> Sent: Thursday, October 26, 2000 3:39 AM
> Subject: [ntdev] TDI Question
>
>
> > Hi All,
> >
> > Please can someone give me some information on how to associate the
> Address File Object and the Connection Endpoint file Object, which are
> created when a connection is requested at the TDI layer. I am not building a
> snoop or anything of the sort but need to be able to intercept data at the
> tdi level.
> >
> > your help would really be appreciated.
> >
> > Thanks
> > Justin
> >
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@namezero.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
_______________________________________
Click here to get your free domain name
and personal portal from NAMEzero™:
http://www.namezero.com</http:>
Hi Justin,
If you simply want associate Address FileObject and Connection EndPoint
FileObject to make it working same as user mode socket, you can build an IRP
using TdiBuildAssociateAddress() and submit it.
aman.
justin white wrote:
Hi All,
Please can someone give me some information on how to associate the Address
File Object and the Connection Endpoint file Object, which are created when a
connection is requested at the TDI layer. I am not building a snoop or
anything of the sort but need to be able to intercept data at the tdi level.
your help would really be appreciated.
Thanks
Justin
Click here to get your free domain name
and personal portal from NAMEzero™:
http://www.namezero.com
—
You are currently subscribed to ntdev as: xxxxx@usa.net
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
_____________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
I haven’t noted the problem that you mention. Perhaps you can give an
example situation where you observe it.
On the other hand, note that the context that I lookup for event handlers is
neither the address object nor the connection context. It is the (possibly)
arbirtary context that was specified when the event handler was set on the
address object.
Sorry I can’t be of more help.
Thomas
----- Original Message -----
From: justin white
To: NT Developers Interest List
Sent: Thursday, October 26, 2000 11:35 AM
Subject: [ntdev] Re: TDI Question
> Thanks,
> I have found that the TDI filtering is quite messy. I also save the
original address object in my event handler and so can easily get to it when
my event is called. Unfortunately the ConnectionContext receive in the call
does not correlate to any other context I ‘see’ previously (like from a
TDI_CONNECT for instance). This also leads to my next question, why is
TDI_ASSOCIATE_ADDRESS not always called. According to the TDI spec, it
should be called.
>
> On Thu, 26 October 2000, “Thomas F. Divine” wrote:
>
> >
> > Justin,
> >
> > Unfortunately, filtering TDI is fairly messy. In addition, there are no
> > standard reference samples that we can talk to. PCAUSA licenses some,
but
> > that doesn’t help you.
> >
> > From reading your previous messages it appears that at least one of your
> > problems seems to be how to relate the ConnectionContext in an Event
> > callback to something meaningful.
> >
> > The steps that work for us include:
> >
> > 1.) Filter creation of address objects. Create a structure in the TDI
filter
> > to track each created address object.
> > 2.) Filter SetEvent calls on each address object. In this filter we save
the
> > original caller’s EventHandler and EventContext and replace both with
our
> > own proxies. This info is saved in our address object tracking
structure.
> > 3.) When an event callback is made it goes to our hook. There we lookup
our
> > proxy EventContext to find the unfiltered EventContext, the unfiltered
> > EventHandler and, or course, the address object.
> >
> > Hope this helps a little.
> >
> > Regards,
> >
> > Thomas F. Divine
> >
> > PCAUSA - Toolkits & Resources For Network Software Developers
> > NDIS Protocol - TDI Client - Windows 95 Redirector
> > http:
> >
> > ----- Original Message -----
> > From: justin white
> > To: NT Developers Interest List
> > Sent: Thursday, October 26, 2000 3:39 AM
> > Subject: [ntdev] TDI Question
> >
> >
> > > Hi All,
> > >
> > > Please can someone give me some information on how to associate the
> > Address File Object and the Connection Endpoint file Object, which are
> > created when a connection is requested at the TDI layer. I am not
building a
> > snoop or anything of the sort but need to be able to intercept data at
the
> > tdi level.
> > >
> > > your help would really be appreciated.
> > >
> > > Thanks
> > > Justin
> > >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
xxxxx@namezero.com
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
> _______________________________________
> Click here to get your free domain name
> and personal portal from NAMEzero™:
> http://www.namezero.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@pcausa.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
></http:>
The poster is filtering TDI calls. He is wondering why the upper-level isn’t
(apparently) making the TdiBuildAssociateAddress call.
Thomas
----- Original Message -----
From: Aman Gupta
To: NT Developers Interest List
Sent: Thursday, October 26, 2000 11:41 AM
Subject: [ntdev] Re: [TDI Question]
Hi Justin,
If you simply want associate Address FileObject and Connection EndPoint
FileObject to make it working same as user mode socket, you can build an IRP
using TdiBuildAssociateAddress() and submit it.
aman.
justin white wrote:
Hi All,
Please can someone give me some information on how to associate the Address
File Object and the Connection Endpoint file Object, which are created when
a
connection is requested at the TDI layer. I am not building a snoop or
anything of the sort but need to be able to intercept data at the tdi level.
your help would really be appreciated.
Thanks
Justin
Click here to get your free domain name
and personal portal from NAMEzero™:
http://www.namezero.com
—
You are currently subscribed to ntdev as: xxxxx@usa.net
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
_____________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
—
You are currently subscribed to ntdev as: xxxxx@pcausa.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Thank you very much for the assistance,
When you receive an event notification, there are two context values received with it.
The one context (known as the TdiEventContext in the MSDN) is used to store information specific for that event, as setup by the client.
The other context (Known as the ConnectionContext in the MSDN) is supposed to be the Connection Context which was created by a previous call to ZwCreateFile in order to create a connection endpoint. This context value (or FileObject) is then supposed to be passed to the ClientEventHandlers, so that the Clients can recognize that particular connection.
The ConnectionContext is however merely passed as a type CONNECTION_CONTEXT to the event handlers, which is defined as a type PVOID. My question is therefore, what does this ConnectionContext mean to the client, and how can i use it to associate this Event Handler with a particular connection endpoint. Perhaps I am looking at the inappropriate variables, but this seems to be the only one relating back to the original connection end-point.
Essentially, what I am attempting to do is associate the address and connection end-point so that I can establish on-the-fly (in the Receive handler) what received data is associated with what transmitted data on an valid ‘connection’.
Thanks in advance
Justin.
Thanks,
I have found that the TDI filtering is quite messy. I also save the original address object in my event handler and so can easily get to it when my event is called. Unfortunately the ConnectionContext receive in the call does not correlate to any other context I ‘see’ previously (like from a TDI_CONNECT for instance). This also leads to my next question, why is TDI_ASSOCIATE_ADDRESS not always called. According to the TDI spec, it should be called.On Thu, 26 October 2000, “Thomas F. Divine” wrote:
>
> Justin,
>
> Unfortunately, filtering TDI is fairly messy. In addition, there are no
> standard reference samples that we can talk to. PCAUSA licenses some, but
> that doesn’t help you.
>
> From reading your previous messages it appears that at least one of your
> problems seems to be how to relate the ConnectionContext in an Event
> callback to something meaningful.
>
> The steps that work for us include:
>
> 1.) Filter creation of address objects. Create a structure in the TDI filter
> to track each created address object.
> 2.) Filter SetEvent calls on each address object. In this filter we save the
> original caller’s EventHandler and EventContext and replace both with our
> own proxies. This info is saved in our address object tracking structure.
> 3.) When an event callback is made it goes to our hook. There we lookup our
> proxy EventContext to find the unfiltered EventContext, the unfiltered
> EventHandler and, or course, the address object.
>
> Hope this helps a little.
>
> Regards,
>
> Thomas F. Divine
>
> PCAUSA - Toolkits & Resources For Network Software Developers
> NDIS Protocol - TDI Client - Windows 95 Redirector
> http:
> >
> > ----- Original Message -----
> > From: justin white
> > To: NT Developers Interest List
> > Sent: Thursday, October 26, 2000 3:39 AM
> > Subject: [ntdev] TDI Question
> >
> >
> > > Hi All,
> > >
> > > Please can someone give me some information on how to associate the
> > Address File Object and the Connection Endpoint file Object, which are
> > created when a connection is requested at the TDI layer. I am not building a
> > snoop or anything of the sort but need to be able to intercept data at the
> > tdi level.
> > >
> > > your help would really be appreciated.
> > >
> > > Thanks
> > > Justin
> > >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@namezero.com
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>
> Click here to get your free domain name
> and personal portal from NAMEzero™:
> http://www.namezero.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@namezero.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Click here to get your free domain name
and personal portal from NAMEzero™:
http://www.namezero.com</http:>
----- Original Message -----
From: justin white
To: NT Developers Interest List
Sent: Thursday, October 26, 2000 12:18 PM
Subject: [ntdev] Re: TDI Question
> Thank you very much for the assistance,
>
…
> The ConnectionContext is however merely passed as a type
CONNECTION_CONTEXT to the event handlers, which is defined as a type PVOID.
My question is therefore, what does this ConnectionContext mean to the
client, and how can i use it to associate this Event Handler with a
particular connection endpoint. Perhaps I am looking at the inappropriate
variables, but this seems to be the only one relating back to the original
connection end-point.
>
To answer this question you simply have to look from the perspective of a
TDI Client. Basically, the client can use the PVOID for any purpose desired.
It’s his, and TDI will give it back when it’s needed. More then likely it’s
just a pointer to some internal structure that the TDI client keeps around
for it’s own use. There are no rules for what the TDI client might use the
field for, so no way to interpret it safely…
In my filters I always substitute my own value for this context and stash
the original caller’s value. So, In my hook function callbacks I know what
CONNECTION_CONTEXT means to ME. If the call is passed on upwards I fetch the
stashed original context and give him that.
Sorry,
Thomas
Justin,
It’s a long time since I did a TDI filter, so my memory is a bit
rusty. But I created my own context which included storage to save the
upper level context passed down to me and the address of the upper event
handler. I then created my own receive event handler for the lower layer
and passed my own context pointer in.
When the handler triggered I could retrieve the upper level context from my
own context record and proceed with the receive. If the upper level
decides to follow this up with an Irp to retrieve the data, it becomes a
multi-phase sequence that more or less requires your own intermediate
context to store all the relevant information.
HTH,
Mark
At 09:18 26/10/2000 -0700, justin white wrote:
Thank you very much for the assistance,
When you receive an event notification, there are two context values
received with it.The one context (known as the TdiEventContext in the MSDN) is used to
store information specific for that event, as setup by the client.The other context (Known as the ConnectionContext in the MSDN) is supposed
to be the Connection Context which was created by a previous call to
ZwCreateFile in order to create a connection endpoint. This context value
(or FileObject) is then supposed to be passed to the ClientEventHandlers,
so that the Clients can recognize that particular connection.The ConnectionContext is however merely passed as a type
CONNECTION_CONTEXT to the event handlers, which is defined as a type
PVOID. My question is therefore, what does this ConnectionContext mean to
the client, and how can i use it to associate this Event Handler with a
particular connection endpoint. Perhaps I am looking at the inappropriate
variables, but this seems to be the only one relating back to the original
connection end-point.Essentially, what I am attempting to do is associate the address and
connection end-point so that I can establish on-the-fly (in the Receive
handler) what received data is associated with what transmitted data on an
valid ‘connection’.Thanks in advance
Justin.>
> Thanks,
> I have found that the TDI filtering is quite messy. I also save the
original address object in my event handler and so can easily get to it
when my event is called. Unfortunately the ConnectionContext receive in
the call does not correlate to any other context I ‘see’ previously (like
from a TDI_CONNECT for instance). This also leads to my next question,
why is TDI_ASSOCIATE_ADDRESS not always called. According to the TDI
spec, it should be called.
>
> On Thu, 26 October 2000, “Thomas F. Divine” wrote:
>
> >
> > Justin,
> >
> > Unfortunately, filtering TDI is fairly messy. In addition, there are no
> > standard reference samples that we can talk to. PCAUSA licenses some, but
> > that doesn’t help you.
> >
> > From reading your previous messages it appears that at least one of your
> > problems seems to be how to relate the ConnectionContext in an Event
> > callback to something meaningful.
> >
> > The steps that work for us include:
> >
> > 1.) Filter creation of address objects. Create a structure in the TDI
filter
> > to track each created address object.
> > 2.) Filter SetEvent calls on each address object. In this filter we
save the
> > original caller’s EventHandler and EventContext and replace both with our
> > own proxies. This info is saved in our address object tracking structure.
> > 3.) When an event callback is made it goes to our hook. There we
lookup our
> > proxy EventContext to find the unfiltered EventContext, the unfiltered
> > EventHandler and, or course, the address object.
> >
> > Hope this helps a little.
> >
> > Regards,
> >
> > Thomas F. Divine
> >
> > PCAUSA - Toolkits & Resources For Network Software Developers
> > NDIS Protocol - TDI Client - Windows 95 Redirector
> > http:
> > >
> > > ----- Original Message -----
> > > From: justin white
> > > To: NT Developers Interest List
> > > Sent: Thursday, October 26, 2000 3:39 AM
> > > Subject: [ntdev] TDI Question
> > >
> > >
> > > > Hi All,
> > > >
> > > > Please can someone give me some information on how to associate the
> > > Address File Object and the Connection Endpoint file Object, which are
> > > created when a connection is requested at the TDI layer. I am not
> building a
> > > snoop or anything of the sort but need to be able to intercept data
> at the
> > > tdi level.
> > > >
> > > > your help would really be appreciated.
> > > >
> > > > Thanks
> > > > Justin
> > > >
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> xxxxx@namezero.com
> > > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
> >
> >
> > Click here to get your free domain name
> > and personal portal from NAMEzero™:
> > http://www.namezero.com
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@namezero.com
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>
>Click here to get your free domain name
>and personal portal from NAMEzero™:
>http://www.namezero.com
>
>—
>You are currently subscribed to ntdev as: xxxxx@muttsnuts.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)</http:>
Thanks for all the help Thomas, and the rest.
I guess I’ll have to work out another way to create the association that I need. It would seem that not all TDI Clients obey the rules laid out by the specification. I could be missing some valid information though so I guess I’ll just have to read the DDK documentation again. Thanks for all the help though.
One other question. Is it normal practice to make Tdi Queries from an event handler, or are they generally made from the IOCTL requests.
I apologise for all the newbie questions, but I am pretty new to TDI.
Thanks again
Justin.
----- Original Message -----
From: justin white
> To: NT Developers Interest List
> Sent: Thursday, October 26, 2000 12:18 PM
> Subject: [ntdev] Re: TDI Question
>
>
> > Thank you very much for the assistance,
> >
> …
> > The ConnectionContext is however merely passed as a type
> CONNECTION_CONTEXT to the event handlers, which is defined as a type PVOID.
> My question is therefore, what does this ConnectionContext mean to the
> client, and how can i use it to associate this Event Handler with a
> particular connection endpoint. Perhaps I am looking at the inappropriate
> variables, but this seems to be the only one relating back to the original
> connection end-point.
> >
>
> To answer this question you simply have to look from the perspective of a
> TDI Client. Basically, the client can use the PVOID for any purpose desired.
> It’s his, and TDI will give it back when it’s needed. More then likely it’s
> just a pointer to some internal structure that the TDI client keeps around
> for it’s own use. There are no rules for what the TDI client might use the
> field for, so no way to interpret it safely…
>
> In my filters I always substitute my own value for this context and stash
> the original caller’s value. So, In my hook function callbacks I know what
> CONNECTION_CONTEXT means to ME. If the call is passed on upwards I fetch the
> stashed original context and give him that.
>
> Sorry,
>
> Thomas
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@namezero.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
_______________________________________
Click here to get your free domain name
and personal portal from NAMEzero™:
http://www.namezero.com
Hi All,
I am trying to learn File System Drivers. Can any one provide me with a
well commented sample program on NTFS or FAT file system driver. Any suggestions
on online reading materials would be extremely helpful.
Thanking you all in advance.
> ----- Original Message -----
From: justin white
> Thanks,
> I have found that the TDI filtering is quite messy. I also save the
> original address object in my event handler and so can easily get to it
> when my event is called. Unfortunately the ConnectionContext receive
> in the call does not correlate to any other context I ‘see’
> previously (like from a TDI_CONNECT for instance). This also leads to
> my next question, why is TDI_ASSOCIATE_ADDRESS not always called.
> According to the TDI spec, it should be called.
I came across this case recently, and I suspect this is what you are
seeing. Connection endpoints created for use accepting connections are
NOT pre-bound to an address object.
Typically, the transport will call the client’s ClientEventConnect
handler. The reply to this function call is a TdiAccept IRP AND a
ConnectionContext value, AND this IRP is directed to one of the
unbound endpoints setup earlier — ie. the client supplies the
endpoint that it wants the incoming connection to be bound to.
As the ClientEventConnect function that is called is registered
by TdiSetEvent with an Address object, the endpoint that the client
uses in the returned TdiAccept message is implicitly associated with
this address object.
And your right, the docs are seriously unclear on this point.
Hope that helps.
Jason
–
Jason O’Broin, Member of Technical Staff, Server Products Group
Wind River Networks, 500 Wind River Way, Alameda, CA 94501-1147 USA
Phone: +1 (510) 749 2466 Fax: +1 (510) 749 2914 Email: xxxxx@wrs.com
Thanks Jason,
This does help a bit, although as far as i know, a TDI_ACCEPT does not
have to be used if a ClientEventConnect handler is registered. The
ClientEventConnect handler does however fill in the ConnectionContext
value and then return to the transport with this value set. This context
value is then supposed to be NULL if the connection is refused. My
problem is that the TDI_ACCEPT is not being called and so although I
have the open address object, if the ACCEPT call is not made, I can’t
make the association.
Thanks again,
Justin