Problems with TdiClientEventReceive

NTDEV
1

Hi,

I am developing a SMTP Filter based on a TDI Driver. The idea is save all
data sent by the email client, and one time the data is revised send it
throught the network. The driver is transparent for applications, so the
smtp client think that the email is being sent although in this time the
email is only be saved.

For this purpose, I implemented to parts. The first one completes all
“TDI_SEND Irps” without pass it to the lower driver, so the smtp client
think that the data is being sent. The second one, call ClientEventReceive
to simulate in the smtp client the responses of the server.

I have made a little smtp client application that implement the basic
commands to send an email and I have tested that all work well. When the
driver call ClientEventReceive handler, the data is received in the test
application. However, I have problems with Microsoft Outlook Express. The
data is intercepted but when I call ClientEventReceive handler it don’t do
nothing. I suppose that highter drivers is receiving the data because
BytesTaken parameter is filled with the total lenght of the data, but it
doens’t seem to arrive to Outlook because it doesn’t send a response.

Is it possible that an application don’t receive the data indicated with
ClientEventReceive although the Event handler for this “Event type” is set?
Do you know any others issues that can be the cause of this problem?

Thanks in advance for your help.

2

I would do all filtering in user service.

The kernel part will only redirect any outgoing 25/TCP connects from any
apps (except the service itself) to the service’s socket.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Josus”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, January 26, 2005 2:00 AM
Subject: [ntdev] Problems with TdiClientEventReceive

>
> Hi,
>
> I am developing a SMTP Filter based on a TDI Driver. The idea is save all
> data sent by the email client, and one time the data is revised send it
> throught the network. The driver is transparent for applications, so the
> smtp client think that the email is being sent although in this time the
> email is only be saved.
>
> For this purpose, I implemented to parts. The first one completes all
> “TDI_SEND Irps” without pass it to the lower driver, so the smtp client
> think that the data is being sent. The second one, call ClientEventReceive
> to simulate in the smtp client the responses of the server.
>
> I have made a little smtp client application that implement the basic
> commands to send an email and I have tested that all work well. When the
> driver call ClientEventReceive handler, the data is received in the test
> application. However, I have problems with Microsoft Outlook Express. The
> data is intercepted but when I call ClientEventReceive handler it don’t do
> nothing. I suppose that highter drivers is receiving the data because
> BytesTaken parameter is filled with the total lenght of the data, but it
> doens’t seem to arrive to Outlook because it doesn’t send a response.
>
> Is it possible that an application don’t receive the data indicated with
> ClientEventReceive although the Event handler for this “Event type” is set?
> Do you know any others issues that can be the cause of this problem?
>
>
> Thanks in advance for your help.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Ok, but although I implement the driver in this way I need to simulate
the responses of the smtp server on the smtp client application in
order it think that the data is being sent well.

Calling TdiClientEventReceive I can simulate the server responses but
when I use it with Microsoft Outlook Express it appears that don’t
receive anything. As I say in my first email, I use a simple smtp
client (developed by me) and this work well. I will test with others
smtp clients… Outlook is become me crazy!! :slight_smile:

Thanks you very much Maxim.

----- Mensaje Original -----
De: “Maxim S. Shatskih”
Fecha: Miercoles, Enero 26, 2005 1:38 am
Asunto: Re: [ntdev] Problems with TdiClientEventReceive

> I would do all filtering in user service.
>
> The kernel part will only redirect any outgoing 25/TCP
> connects from any
> apps (except the service itself) to the service’s socket.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Josus”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, January 26, 2005 2:00 AM
> Subject: [ntdev] Problems with TdiClientEventReceive
>
>
> >
> > Hi,
> >
> > I am developing a SMTP Filter based on a TDI Driver. The idea is
> save all
> > data sent by the email client, and one time the data is revised
> send it
> > throught the network. The driver is transparent for
> applications, so the
> > smtp client think that the email is being sent although in this
> time the
> > email is only be saved.
> >
> > For this purpose, I implemented to parts. The first one
> completes all
> > “TDI_SEND Irps” without pass it to the lower driver, so the smtp
> client> think that the data is being sent. The second one, call
> ClientEventReceive> to simulate in the smtp client the responses
> of the server.
> >
> > I have made a little smtp client application that implement the
> basic> commands to send an email and I have tested that all work
> well. When the
> > driver call ClientEventReceive handler, the data is received in
> the test
> > application. However, I have problems with Microsoft Outlook
> Express. The
> > data is intercepted but when I call ClientEventReceive handler
> it don’t do
> > nothing. I suppose that highter drivers is receiving the data
> because> BytesTaken parameter is filled with the total lenght of
> the data, but it
> > doens’t seem to arrive to Outlook because it doesn’t send a
> response.>
> > Is it possible that an application don’t receive the data
> indicated with
> > ClientEventReceive although the Event handler for this “Event
> type” is set?
> > Do you know any others issues that can be the cause of this problem?
> >
> >
> > Thanks in advance for your help.
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.co
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to leave-ntdev-
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.co
> You are currently subscribed to ntdev as: xxxxx@telefonica.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

4

Josus,

First, I must agree with Maxim. You are most likely in the wrong place for
you application. You might look into writing a ‘filtering’ WINSOCK provider
to do this as an alternative if you don’t need to catch kernel mode clients
sending SMTP requests.

But with respect to your question: Make sure you can answer yes to all of
these.

  1. Are you completing any IRP returned from the call to
    ClientEventReceive?
  2. Are you processing TDI_RECEIVE Irps presented at
    DispatchInternalDeviceControl?
  3. Are you calling TdiMapUserRequest() in DispatchDeviceControl and dealing
    with the possiblity of an TDI_RECIEVE Irp?
  4. Are you setting the flags properly in ClientEventRecieve() call?
  5. Did the TDI Client (AFD.SYS most likely in this case) register a Chained
    Recieve handler? Perhaps you should be calling it instead…

Good Luck,

Dave Cattley
Consulting Engineer
Systems Software Development

“Josus” wrote in message news:xxxxx@ntdev…
>
> Hi,
>
> I am developing a SMTP Filter based on a TDI Driver. The idea is save all
> data sent by the email client, and one time the data is revised send it
> throught the network. The driver is transparent for applications, so the
> smtp client think that the email is being sent although in this time the
> email is only be saved.
>
> For this purpose, I implemented to parts. The first one completes all
> “TDI_SEND Irps” without pass it to the lower driver, so the smtp client
> think that the data is being sent. The second one, call ClientEventReceive
> to simulate in the smtp client the responses of the server.
>
> I have made a little smtp client application that implement the basic
> commands to send an email and I have tested that all work well. When the
> driver call ClientEventReceive handler, the data is received in the test
> application. However, I have problems with Microsoft Outlook Express. The
> data is intercepted but when I call ClientEventReceive handler it don’t do
> nothing. I suppose that highter drivers is receiving the data because
> BytesTaken parameter is filled with the total lenght of the data, but it
> doens’t seem to arrive to Outlook because it doesn’t send a response.
>
> Is it possible that an application don’t receive the data indicated with
> ClientEventReceive although the Event handler for this “Event type” is
> set?
> Do you know any others issues that can be the cause of this problem?
>
>
> Thanks in advance for your help.
>
>
>

5

Hi,

I take in count others alternatives like develop an NDIS IM driver or an
LSP, but for others client requirements I think the best solution is a TDI
Filter. As Maxim, I think that is a better idea to implement the filtering
process into user service but I as I say before I have to comply with
client requirements (an old story…).

An answering these questions…

1.- Yes, I take in count that I must complete this IRPs. Anyway, because I
am indicating all packet content and using receive entire message flag the
client always set the IRP to NULL.

2.- Yes, I am processing TDI_RECEIVE, although in general, no call to
TDI_RECEIVE is received.

3.- Yes, I am calling TdiMapUserRequest.

4.- Flag: I test all, first wiht TDI_RECEIVE_NORMAL |
TDI_RECEIVE_ENTIRE_MESSAGE . Second with TDI_RECEIVE_ENTIRE_MESSAGE only.

5.- The tdi client is registering both handler: ClientEventReceive and
ClientEventChainedReceive. I am not using ClientEventChainedReceive because
I don’t know how to work with TsduDescriptor parameter. I have seen that in
the same connection always is set to the same value, but because I don’t
know if the client are going to call to TdiReturnChainedReceive with this
value I don’t think it is a good solution. Do you know more about this
parameter?

Anyway, I want to remember my problem. The driver is working well for some
smtp clients I have used (a basic client and Thunderbird mail client) but
when I use Microsoft Outlook Express, appears that the receive indication
doesn’t arrive. I suppose all of this clients send/receive data trhought
afd.sys, so I don’t find any reason to my problem. The only one is that
microsoft outlook express is accessing the network using another way. I have
develop some others tdi filters and I never have found similar problem…
The life is too hard for developers… :).

Thanks for all!!!

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de David R. Cattley
Enviado el: s?bado, 29 de enero de 2005 0:46
Para: Windows System Software Devs Interest List
Asunto: Re:[ntdev] Problems with TdiClientEventReceive

Josus,

First, I must agree with Maxim. You are most likely in the wrong place for
you application. You might look into writing a ‘filtering’ WINSOCK provider
to do this as an alternative if you don’t need to catch kernel mode clients
sending SMTP requests.

But with respect to your question: Make sure you can answer yes to all of
these.

  1. Are you completing any IRP returned from the call to
    ClientEventReceive?
  2. Are you processing TDI_RECEIVE Irps presented at
    DispatchInternalDeviceControl?
  3. Are you calling TdiMapUserRequest() in DispatchDeviceControl and dealing
    with the possiblity of an TDI_RECIEVE Irp?
  4. Are you setting the flags properly in ClientEventRecieve() call?
  5. Did the TDI Client (AFD.SYS most likely in this case) register a Chained
    Recieve handler? Perhaps you should be calling it instead…

Good Luck,

Dave Cattley
Consulting Engineer
Systems Software Development

“Josus” wrote in message news:xxxxx@ntdev…
>
> Hi,
>
> I am developing a SMTP Filter based on a TDI Driver. The idea is save
> all data sent by the email client, and one time the data is revised
> send it throught the network. The driver is transparent for
> applications, so the smtp client think that the email is being sent
> although in this time the email is only be saved.
>
> For this purpose, I implemented to parts. The first one completes all
> “TDI_SEND Irps” without pass it to the lower driver, so the smtp
> client think that the data is being sent. The second one, call
> ClientEventReceive to simulate in the smtp client the responses of the
server.
>
> I have made a little smtp client application that implement the basic
> commands to send an email and I have tested that all work well. When
> the driver call ClientEventReceive handler, the data is received in
> the test application. However, I have problems with Microsoft Outlook
> Express. The data is intercepted but when I call ClientEventReceive
> handler it don’t do nothing. I suppose that highter drivers is
> receiving the data because BytesTaken parameter is filled with the
> total lenght of the data, but it doens’t seem to arrive to Outlook because
it doesn’t send a response.
>
> Is it possible that an application don’t receive the data indicated
> with ClientEventReceive although the Event handler for this “Event
> type” is set?
> Do you know any others issues that can be the cause of this problem?
>
>
> Thanks in advance for your help.
>
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

6

Josus,

The ClientEventChainedXxxx routines are simply a way of letting a TDI client
receive the NDIS_PACKET directly. The Tsdu parameter is an MDL chain from
an NDIS_PACKET. The TsduDescriptor is simply an NDIS_PACKET.

Perhaps you might consider simply using your filter to change the
destination host/port in the client’s TDI_CONNECT to a local (127.0.0.1)
host / port combination and have your SMTP ‘agent’ run as a user-mode
program that is listening for connects on that address/port. In this way
your driver would be minimally invasive (it would not process data or
control behavior). The behavior of TCPIP (and OE using
WINSOCK/AFD/TDI/TCPIP) would be preserved.

I can also recommend that you search the Microsoft Research web-site for the
original NT4/2K experimental IPv6 project source-code. At one time the full
source of a TDI implementation of IPv6 was available for download. The TDI
portions of this driver seem to be a “very close cousin” of the IPv4 driver.
Inspecting this may provide some insight into why your current approach has
trouble with OE.

Good Luck,

Dave Cattley
Consulting Engineer
Systems Software Development

7

Ok Dave, Thanks you very much for your information. I am going to think in
the idea of divide the project in kernel+user components in order to
simplify it.

I have downloaded the ipv6 implementations. I will dedicate it some time to
know more about tdi.

Regards.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de David R. Cattley
Enviado el: domingo, 30 de enero de 2005 16:18
Para: Windows System Software Devs Interest List
Asunto: Re:[ntdev] Problems with TdiClientEventReceive

Josus,

The ClientEventChainedXxxx routines are simply a way of letting a TDI client
receive the NDIS_PACKET directly. The Tsdu parameter is an MDL chain from
an NDIS_PACKET. The TsduDescriptor is simply an NDIS_PACKET.

Perhaps you might consider simply using your filter to change the
destination host/port in the client’s TDI_CONNECT to a local (127.0.0.1)
host / port combination and have your SMTP ‘agent’ run as a user-mode
program that is listening for connects on that address/port. In this way
your driver would be minimally invasive (it would not process data or
control behavior). The behavior of TCPIP (and OE using
WINSOCK/AFD/TDI/TCPIP) would be preserved.

I can also recommend that you search the Microsoft Research web-site for the
original NT4/2K experimental IPv6 project source-code. At one time the full
source of a TDI implementation of IPv6 was available for download. The TDI
portions of this driver seem to be a “very close cousin” of the IPv4 driver.

Inspecting this may provide some insight into why your current approach has
trouble with OE.

Good Luck,

Dave Cattley
Consulting Engineer
Systems Software Development

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

8

TDI filters cannot properly filter this function.

This is because the reciprocal for it is TdiReturnChainedReceives, it will
be called by the client above the filter, and this is is - voila - macro
defined to NdisReturnPackets and not filterable.

One more additional point to consider the TDI filter idea as brain-damaged.
Sorry, TDI was never designed for filtering. But NDIS was.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “David R. Cattley”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Sunday, January 30, 2005 6:18 PM
Subject: Re:[ntdev] Problems with TdiClientEventReceive

> Josus,
>
> The ClientEventChainedXxxx routines are simply a way of letting a TDI client
> receive the NDIS_PACKET directly. The Tsdu parameter is an MDL chain from
> an NDIS_PACKET. The TsduDescriptor is simply an NDIS_PACKET.
>
> Perhaps you might consider simply using your filter to change the
> destination host/port in the client’s TDI_CONNECT to a local (127.0.0.1)
> host / port combination and have your SMTP ‘agent’ run as a user-mode
> program that is listening for connects on that address/port. In this way
> your driver would be minimally invasive (it would not process data or
> control behavior). The behavior of TCPIP (and OE using
> WINSOCK/AFD/TDI/TCPIP) would be preserved.
>
> I can also recommend that you search the Microsoft Research web-site for the
> original NT4/2K experimental IPv6 project source-code. At one time the full
> source of a TDI implementation of IPv6 was available for download. The TDI
> portions of this driver seem to be a “very close cousin” of the IPv4 driver.
> Inspecting this may provide some insight into why your current approach has
> trouble with OE.
>
> Good Luck,
>
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com