TDI Filter Driver blocking connections

Hi

I'm a newbie in driver development and after a great deal of effort I
finally managed to implement a pass-through NT4-style filter driver for
\device\tcp. I'm watching the debug output from the driver and I see
that it gets called whenever a TCP connection is made, but although it
passes the IRP down to the lower device successfully (at least, I think
it does) every connection attempt failes with error code 10022: bad
format thing.

Does anyone know what the problem might be?

Steve
Wed Jan 12 18:38:34 CST 2005

There is an excellent example tdi driver called tdi_fw -
try the following URL for the source code -
http://www.ntndis.com/utilities/tdi_fw.shtml.

You can review this code to determine if you are
correctly passing down/processing the irps your are
filtering. When you receive TDI_CONNECT command (or any
command) you must call IoCallDriver() with the irp
pointer that was passed to your dispatch function, and a
pointer to the device object that you are filtering - NOT
the device object pointer that was passed to your
dispatch function but the pointer to the device object
that you are filtering!! - this is returned in the
*AttachedDevice parameter of IoAttachDevice() call.


There are also others things that need to be done if you
want to register completion routines but just get the
basics working for now.

Steve.

>-----Original Message-----
>Hi
>
>I'm a newbie in driver development and after a great
deal of effort I
>finally managed to implement a pass-through NT4-style
filter driver for
>\device\tcp. I'm watching the debug output from the
driver and I see
>that it gets called whenever a TCP connection is made,
but although it
>passes the IRP down to the lower device successfully (at
least, I think
>it does) every connection attempt failes with error code
10022: bad
>format thing.
>
>Does anyone know what the problem might be?
>
>.
>

Dizzy
Thu Jan 13 01:59:16 CST 2005

Thank you very much for replying to my message.

I downloaded tdi_fw, but it is a bit overwhelming for me now when I'm
still strugling with the basics. Anyway, I'll look deeper into it.

I noticed that although there are a lot of people that are developing
TDI filter driveres, there isn't a lot of source code available to get
someone started with a basic driver.

Steve wrote:
> There is an excellent example tdi driver called tdi_fw -
> try the following URL for the source code -
> http://www.ntndis.com/utilities/tdi_fw.shtml.
>
> You can review this code to determine if you are
> correctly passing down/processing the irps your are
> filtering. When you receive TDI_CONNECT command (or any
> command) you must call IoCallDriver() with the irp
> pointer that was passed to your dispatch function, and a
> pointer to the device object that you are filtering - NOT
> the device object pointer that was passed to your
> dispatch function but the pointer to the device object
> that you are filtering!! - this is returned in the
> *AttachedDevice parameter of IoAttachDevice() call.
>
>
> There are also others things that need to be done if you
> want to register completion routines but just get the
> basics working for now.
>
> Steve.
>
> >-----Original Message-----
> >Hi
> >
> >I'm a newbie in driver development and after a great
> deal of effort I
> >finally managed to implement a pass-through NT4-style
> filter driver for
> >\device\tcp. I'm watching the debug output from the
> driver and I see
> >that it gets called whenever a TCP connection is made,
> but although it
> >passes the IRP down to the lower device successfully (at
> least, I think
> >it does) every connection attempt failes with error code
> 10022: bad
> >format thing.
> >
> >Does anyone know what the problem might be?
> >
> >.
> >

James
Thu Jan 20 18:51:28 CST 2005

If this is an exercise purely for yourself, you should use what works. If
you're thinking of releasing the results in the outside, especially as a
product, don't take the hooking approach that this sample contains (at least
when last I looked). Use an NDIS intermediate driver; the DDK has a sample.
NDIS is complicated, but I think that's true of almost anything in
networking.

--
James Antognini
Windows Driver Developer Support

This posting is provided "AS IS" with no warranties, and confers no rights.

"Dizzy" <bcristi@gmail.com> wrote in message
news:1105603156.153399.77660@c13g2000cwb.googlegroups.com...
> Thank you very much for replying to my message.
>
> I downloaded tdi_fw, but it is a bit overwhelming for me now when I'm
> still strugling with the basics. Anyway, I'll look deeper into it.
>
> I noticed that although there are a lot of people that are developing
> TDI filter driveres, there isn't a lot of source code available to get
> someone started with a basic driver.
>
> Steve wrote:
>> There is an excellent example tdi driver called tdi_fw -
>> try the following URL for the source code -
>> http://www.ntndis.com/utilities/tdi_fw.shtml.
>>
>> You can review this code to determine if you are
>> correctly passing down/processing the irps your are
>> filtering. When you receive TDI_CONNECT command (or any
>> command) you must call IoCallDriver() with the irp
>> pointer that was passed to your dispatch function, and a
>> pointer to the device object that you are filtering - NOT
>> the device object pointer that was passed to your
>> dispatch function but the pointer to the device object
>> that you are filtering!! - this is returned in the
>> *AttachedDevice parameter of IoAttachDevice() call.
>>
>>
>> There are also others things that need to be done if you
>> want to register completion routines but just get the
>> basics working for now.
>>
>> Steve.
>>
>> >-----Original Message-----
>> >Hi
>> >
>> >I'm a newbie in driver development and after a great
>> deal of effort I
>> >finally managed to implement a pass-through NT4-style
>> filter driver for
>> >\device\tcp. I'm watching the debug output from the
>> driver and I see
>> >that it gets called whenever a TCP connection is made,
>> but although it
>> >passes the IRP down to the lower device successfully (at
>> least, I think
>> >it does) every connection attempt failes with error code
>> 10022: bad
>> >format thing.
>> >
>> >Does anyone know what the problem might be?
>> >
>> >.
>> >
>

Cristian
Fri Jan 21 03:08:01 CST 2005

Hello and thank you for your advice.

I'm interested in monitoring network data send over TCP. Is there a big
reason why a TDI filter driver will not do the job?

James Antognini [MSFT} wrote:
> If this is an exercise purely for yourself, you should use what
works. If
> you're thinking of releasing the results in the outside, especially
as a
> product, don't take the hooking approach that this sample contains
(at least
> when last I looked). Use an NDIS intermediate driver; the DDK has a
sample.
> NDIS is complicated, but I think that's true of almost anything in
> networking.
>
> --
> James Antognini
> Windows Driver Developer Support

Maxim
Fri Jan 21 12:21:42 CST 2005

> I'm interested in monitoring network data send over TCP. Is there a big
> reason why a TDI filter driver will not do the job?

They are not supported by Microsoft and rely on reverse-engineering results.
So, they lack in stability, and can be broken by the next service pack.

Use NDIS IM instead.

BTW - UNIX firewalls are also conceptually closer to NDIS IM and not to TDI
filtering.

TDI filtering is just plain a bad idea. The only sane purpose it can serve is
associate processes to TCP/UDP port numbers. Nothing more.

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

Arkady
Sat Jan 22 02:01:45 CST 2005

Additionally
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/network/hh/
network/firewall_5932d4d9-b61d-472d-8f27-c6a1d26ddc36.xml.asp
( aware of wrap )
Arkady

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:u#o$oX#$EHA.1908@TK2MSFTNGP15.phx.gbl...
> > I'm interested in monitoring network data send over TCP. Is there a big
> > reason why a TDI filter driver will not do the job?
>
> They are not supported by Microsoft and rely on reverse-engineering
results.
> So, they lack in stability, and can be broken by the next service pack.
>
> Use NDIS IM instead.
>
> BTW - UNIX firewalls are also conceptually closer to NDIS IM and not to
TDI
> filtering.
>
> TDI filtering is just plain a bad idea. The only sane purpose it can serve
is
> associate processes to TCP/UDP port numbers. Nothing more.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>