Thomas,
Since you mention that you are looking for the client packet on a TDI_SEND, I am going to assume (the most difficult case) of the send occuring on a TCP connection.
The file object that the TDI_SEND has been issued against is a TDI Connection File Object. At some point it was associated with a TDI Address File Object via a TDI_ASSOCIATE_ADDRESS minor IRP. Your filter driver must ensure that it has filtered the creation (IRP_MJ_CREATE) of both of those objects and ‘tracked’ the association between the two.
Your filter driver must be sure to take note of TDI_SET_EVENT calls made against the Address File Object. The ‘Context’ parameters you would need to invoke the event callback will be provided during the appropriate TDI_SET_EVENT call. Keep in mind, this Context value is the clients ‘handle’ to the associated address, not the connection.
The ConnectionContext value is assigned to the TDI Connection File Object by the client and is made available to the Transport Driver (and any filter drivers) during IRP_MJ_CREATE as the ‘value’ of the Extended Attribute with name TdiConnectionContext in the FILE_FULL_EA_INFORMATION buffer. I believe quite recently on the list was some sample code that showed how to extract this. The ConnectionContext is a DWORD_PTR immediately following the EA Name “TdiConnectionContext”. Beware that it does not need to be aligned. This value is needed in the event callback to identify to the client which connection (by the client’s handle) is being referenced.
The client may accept all, some, or none of the data during the recieve callback. It may return an IRP for a TDI_RECIEVE operation that you would need to complete to satisfy the read.
The client registers the event handler on the address object. All connections associated with that address object will be serviced by the same event handler and identified to the client with the same Context value. Each connection, however, will have (should have, must have?) a separate ConnectionContext value that identifes the particular connection to the client.
The receive event callback is an indication to the client that data is available on the connection. The client is presented with look-ahead data (usually the entire segment of available data but no necessarily) and an OUT parameter to specify an IRP to be completed by the Transport (filter). The client may do one of three things:
- Refuse the data.
- Accept the entire segment if the lookahead amount is the entire segment.
- Accept part of the segment and return a IRP to ‘recieve’ the remainder.
(1) and (2) are pretty easy (no additional work for you, I think) and (3) is not terribly difficult other than that you are probably going to complete the entire TDI_RECEIVE (or IRP_MJ_READ sometimes) immediately (you have the data).
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
“Handal, Thomas” wrote in message news:xxxxx@ntdev…
Hi All,
I currently have a TDI filter driver that I am writing. What I am doing is looking for a certain packet on my TDI_SEND. I find the packet that I am looking for and I complete the IRP right there so the application thinks the send worked, but it doesn’t really get sent out. This all works fine. What I want to do now is I want to send a packet back to the application, which looks like it came from the remote machine. I think I can do this by calling the registered receive event handler. Can anyone explain to me how this receive event handler works, and how I can call it in order to send data to the application? Also, what are the context and connection context pointers?
Thanks
Tom