Re: Remote Address query with TDI

NTDEV
1

Nar,
Below is a posting from the archive. Can you please explain a
little about the Sub-note “please don’t filter IRPs on \Device\Tcp”?
Does it mean do not attach to \Device\Tcp? or does it mean do
not write TDI filter drivers?

Thanks,
Srin.

-----Original Message-----
From: Nar Ganapathy [MS] [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, June 27, 2002 11:05 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

Can you explain what you ultimately want to achieve ? Our TCP/IP
developers
don’t want you do this.

"Unfortunately, TDI doesn’t define a mechanism for a client to
retrieve
the
remote address of a connection. Sub-note: “please don’t filter IRPs on
\Device\Tcp”.

Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no
rights.

“Stanislaw Kowalczyk” wrote in message
> news:xxxxx@ntdev…
> >
> >
> > Is there a way to query a established connection FileObject created
by
> the
> > Tcp driver to determine what remote address its connected to?
> >
> > Currently I am filtering the tcp driver and caching this information
for
> > newly created connections, however, for previously established
> connections
> I
> > obviously don’t have it and would like to gather it if possible.
> >
> > Any help, hints or direction appreciated.
> >
> > Stanislaw
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nai.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

2

I cannot answer the question. In fact, I’m interested in the answer. But let
me add a few points:

  1. I’ve heard that TDI is likely to change in the future.

  2. How exactly do you propose filtering IRPs? In a separate posting, you
    mentioned IoAttachDeviceToDeviceStack, which suggests a WDM mechanism, but
    I’m not sure whether TDI is intended for such, that is, whether it is set up
    that way. If, on the other hand, you intend to filter by overlaying the TDI
    driver’s entry points for IRP processing (TDI_FW), that would definitely be
    a no-no.

  3. I believe there is a legitimate need for filter TDI IRPs, at least for
    open. Firewalls, for example, typically require knowing who is the caller of
    a network service, and I think that that information is available only in
    the originating thread, where a routine tries to open a socket or such like.
    I don’t think the information is going to be available at, say, the NDIS
    level, which would ordinarily be the legitimate way of handling network
    traffic.

xxxxx@NAI.com wrote:

Does it mean do not attach to \Device\Tcp? or does it mean do
not write TDI filter drivers?

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

James Antognini
Windows DDK MVP

3

I can’t answer the original question either, but I can tell you I have
attached to
both TCP and UDP using IoAttachDevice, to do TDI filtering. I do believe
the answer
is don’t attach to TCP or UDP or try to do TDI filtering.

In answer to 3 below, yes there is need for TDI filtering because at the
NDIS
layer packets can and are sent in an arbitrary thread context. I made a two
layer driver before that correlated packets being sent to the process that
created
the connection.

It would be nice if Microsoft either added support for TDI filtering, or
the ability to know what process/thread/user opened the connection to NDIS.

-Jeff

-----Original Message-----
From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
Sent: Thursday, July 24, 2003 4:35 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

I cannot answer the question. In fact, I’m interested in the answer. But let
me add a few points:

  1. I’ve heard that TDI is likely to change in the future.

  2. How exactly do you propose filtering IRPs? In a separate posting, you
    mentioned IoAttachDeviceToDeviceStack, which suggests a WDM mechanism, but
    I’m not sure whether TDI is intended for such, that is, whether it is set up
    that way. If, on the other hand, you intend to filter by overlaying the TDI
    driver’s entry points for IRP processing (TDI_FW), that would definitely be
    a no-no.

  3. I believe there is a legitimate need for filter TDI IRPs, at least for
    open. Firewalls, for example, typically require knowing who is the caller of
    a network service, and I think that that information is available only in
    the originating thread, where a routine tries to open a socket or such like.
    I don’t think the information is going to be available at, say, the NDIS
    level, which would ordinarily be the legitimate way of handling network
    traffic.

xxxxx@NAI.com wrote:

Does it mean do not attach to \Device\Tcp? or does it mean do
not write TDI filter drivers?

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

James Antognini
Windows DDK MVP

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

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
the latest virus scan software available for the presence of computer
viruses.
**********************************************************************

4

Jeff,
I am little confused. Are you saying “I do believe the answer is
don’t attach to TCP or UDP or try to do TDI filtering.”?
Right now the ways I know to find the application doing network
activity.

  1. attach to Afd. This is more undocumented than TDI. And you would miss
    those connections the Tdi clients directly make using TDI interface to
    Tcp/udp.
  2. patching the dispatch entry points of Afd. Insane method and I do not
    see any advantage over the first one.
  3. attach to Tcp, udp, rawip. I have done this before and this is better
    way as I know of today. I found one application till now Novell Netware
    client(srvloc.sys) always manages to send requests directly to Tcp
    device object instead of to the attached device object.
  4. patching the dispatch entry points of Tcp. I have not done before,
    and I am not even sure if it is worth the effort to follow this path
    just to capture those connections like I mentioned in third case.

Is there any other way such as writing an upper filter to tcpip driver
and I would receive all the requests before sent to tcp/udp/rawip
devices? Or some other magic which Microsoft approves?

Jeff & James,
I really appreciate your responses. I have been responding to
Tdi filter & Client driver queries on this list, but I my self am not
sure of Microsoft approved way of doing this. I don’t even know if there
is a Microsoft suggested way?

-Srin.

-----Original Message-----
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, July 24, 2003 1:57 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

I can’t answer the original question either, but I can tell you I have
attached to
both TCP and UDP using IoAttachDevice, to do TDI filtering. I do
believe
the answer
is don’t attach to TCP or UDP or try to do TDI filtering.

In answer to 3 below, yes there is need for TDI filtering because at
the
NDIS
layer packets can and are sent in an arbitrary thread context. I made
a
two
layer driver before that correlated packets being sent to the process
that
created
the connection.

It would be nice if Microsoft either added support for TDI filtering,
or
the ability to know what process/thread/user opened the connection to
NDIS.

-Jeff

-----Original Message-----
From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
Sent: Thursday, July 24, 2003 4:35 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

I cannot answer the question. In fact, I’m interested in the answer.
But
let
me add a few points:

  1. I’ve heard that TDI is likely to change in the future.

  2. How exactly do you propose filtering IRPs? In a separate posting,
    you
    mentioned IoAttachDeviceToDeviceStack, which suggests a WDM mechanism,
    but
    I’m not sure whether TDI is intended for such, that is, whether it is
    set
    up
    that way. If, on the other hand, you intend to filter by overlaying
    the
    TDI
    driver’s entry points for IRP processing (TDI_FW), that would
    definitely
    be
    a no-no.

  3. I believe there is a legitimate need for filter TDI IRPs, at least
    for
    open. Firewalls, for example, typically require knowing who is the
    caller
    of
    a network service, and I think that that information is available only
    in
    the originating thread, where a routine tries to open a socket or such
    like.
    I don’t think the information is going to be available at, say, the
    NDIS
    level, which would ordinarily be the legitimate way of handling
    network
    traffic.

xxxxx@NAI.com wrote:

> Does it mean do not attach to \Device\Tcp? or does it mean
do
> not write TDI filter drivers?
>

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

James Antognini
Windows DDK MVP

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

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
the latest virus scan software available for the presence of computer
viruses.
**********************************************************************

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

5

I rather suspect there is no Microsoft-approved way. But, as I said, there
is a legitimate need for one.

xxxxx@NAI.com wrote:

Jeff & James,
I really appreciate your responses. I have been responding to
Tdi filter & Client driver queries on this list, but I my self am not
sure of Microsoft approved way of doing this. I don’t even know if there
is a Microsoft suggested way?

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

James Antognini
Windows DDK MVP

6

Yes that is what I am saying. I don’t think there is any Microsoft
sanctioned way of getting the information you need. Though a winsock
helper DLL may do what you need (I have never written one).

-Jeff

-----Original Message-----
From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
Sent: Thursday, July 24, 2003 5:58 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

Jeff,
I am little confused. Are you saying “I do believe the answer is
don’t attach to TCP or UDP or try to do TDI filtering.”?
Right now the ways I know to find the application doing network
activity.

  1. attach to Afd. This is more undocumented than TDI. And you would miss
    those connections the Tdi clients directly make using TDI interface to
    Tcp/udp.
  2. patching the dispatch entry points of Afd. Insane method and I do not
    see any advantage over the first one.
  3. attach to Tcp, udp, rawip. I have done this before and this is better
    way as I know of today. I found one application till now Novell Netware
    client(srvloc.sys) always manages to send requests directly to Tcp
    device object instead of to the attached device object.
  4. patching the dispatch entry points of Tcp. I have not done before,
    and I am not even sure if it is worth the effort to follow this path
    just to capture those connections like I mentioned in third case.

Is there any other way such as writing an upper filter to tcpip driver
and I would receive all the requests before sent to tcp/udp/rawip
devices? Or some other magic which Microsoft approves?

Jeff & James,
I really appreciate your responses. I have been responding to
Tdi filter & Client driver queries on this list, but I my self am not
sure of Microsoft approved way of doing this. I don’t even know if there
is a Microsoft suggested way?

-Srin.

-----Original Message-----
From: Curless, Jeffrey [mailto:xxxxx@concord.com]
Sent: Thursday, July 24, 2003 1:57 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

I can’t answer the original question either, but I can tell you I have
attached to
both TCP and UDP using IoAttachDevice, to do TDI filtering. I do
believe
the answer
is don’t attach to TCP or UDP or try to do TDI filtering.

In answer to 3 below, yes there is need for TDI filtering because at
the
NDIS
layer packets can and are sent in an arbitrary thread context. I made
a
two
layer driver before that correlated packets being sent to the process
that
created
the connection.

It would be nice if Microsoft either added support for TDI filtering,
or
the ability to know what process/thread/user opened the connection to
NDIS.

-Jeff

-----Original Message-----
From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
Sent: Thursday, July 24, 2003 4:35 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

I cannot answer the question. In fact, I’m interested in the answer.
But
let
me add a few points:

  1. I’ve heard that TDI is likely to change in the future.

  2. How exactly do you propose filtering IRPs? In a separate posting,
    you
    mentioned IoAttachDeviceToDeviceStack, which suggests a WDM mechanism,
    but
    I’m not sure whether TDI is intended for such, that is, whether it is
    set
    up
    that way. If, on the other hand, you intend to filter by overlaying
    the
    TDI
    driver’s entry points for IRP processing (TDI_FW), that would
    definitely
    be
    a no-no.

  3. I believe there is a legitimate need for filter TDI IRPs, at least
    for
    open. Firewalls, for example, typically require knowing who is the
    caller
    of
    a network service, and I think that that information is available only
    in
    the originating thread, where a routine tries to open a socket or such
    like.
    I don’t think the information is going to be available at, say, the
    NDIS
    level, which would ordinarily be the legitimate way of handling
    network
    traffic.

xxxxx@NAI.com wrote:

> Does it mean do not attach to \Device\Tcp? or does it mean
do
> not write TDI filter drivers?
>

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

James Antognini
Windows DDK MVP

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

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
the latest virus scan software available for the presence of computer
viruses.
**********************************************************************

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@concord.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Impossible. You can only save the remote address in filter’s connect() path
for later reuse.
For incoming connection, the remote address is provided to
ClientEventConnect.

Max

----- Original Message -----
From: “Curless, Jeffrey”
To: “Windows System Software Developers Interest List”
Sent: Friday, July 25, 2003 6:20 PM
Subject: [ntdev] Re: Remote Address query with TDI

> Yes that is what I am saying. I don’t think there is any Microsoft
> sanctioned way of getting the information you need. Though a winsock
> helper DLL may do what you need (I have never written one).
>
> -Jeff
>
> -----Original Message-----
> From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
> Sent: Thursday, July 24, 2003 5:58 PM
> To: Windows System Software Developers Interest List
> Subject: [ntdev] Re: Remote Address query with TDI
>
>
> Jeff,
> I am little confused. Are you saying “I do believe the answer is
> don’t attach to TCP or UDP or try to do TDI filtering.”?
> Right now the ways I know to find the application doing network
> activity.
> 1. attach to Afd. This is more undocumented than TDI. And you would miss
> those connections the Tdi clients directly make using TDI interface to
> Tcp/udp.
> 2. patching the dispatch entry points of Afd. Insane method and I do not
> see any advantage over the first one.
> 3. attach to Tcp, udp, rawip. I have done this before and this is better
> way as I know of today. I found one application till now Novell Netware
> client(srvloc.sys) always manages to send requests directly to Tcp
> device object instead of to the attached device object.
> 4. patching the dispatch entry points of Tcp. I have not done before,
> and I am not even sure if it is worth the effort to follow this path
> just to capture those connections like I mentioned in third case.
>
> Is there any other way such as writing an upper filter to tcpip driver
> and I would receive all the requests before sent to tcp/udp/rawip
> devices? Or some other magic which Microsoft approves?
>
> Jeff & James,
> I really appreciate your responses. I have been responding to
> Tdi filter & Client driver queries on this list, but I my self am not
> sure of Microsoft approved way of doing this. I don’t even know if there
> is a Microsoft suggested way?
>
> -Srin.
>
> > -----Original Message-----
> > From: Curless, Jeffrey [mailto:xxxxx@concord.com]
> > Sent: Thursday, July 24, 2003 1:57 PM
> > To: Windows System Software Developers Interest List
> > Subject: [ntdev] Re: Remote Address query with TDI
> >
> > I can’t answer the original question either, but I can tell you I have
> > attached to
> > both TCP and UDP using IoAttachDevice, to do TDI filtering. I do
> believe
> > the answer
> > is don’t attach to TCP or UDP or try to do TDI filtering.
> >
> > In answer to 3 below, yes there is need for TDI filtering because at
> the
> > NDIS
> > layer packets can and are sent in an arbitrary thread context. I made
> a
> > two
> > layer driver before that correlated packets being sent to the process
> that
> > created
> > the connection.
> >
> > It would be nice if Microsoft either added support for TDI filtering,
> or
> > the ability to know what process/thread/user opened the connection to
> > NDIS.
> >
> > -Jeff
> >
> >
> > -----Original Message-----
> > From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
> > Sent: Thursday, July 24, 2003 4:35 PM
> > To: Windows System Software Developers Interest List
> > Subject: [ntdev] Re: Remote Address query with TDI
> >
> >
> > I cannot answer the question. In fact, I’m interested in the answer.
> But
> > let
> > me add a few points:
> >
> > 1) I’ve heard that TDI is likely to change in the future.
> >
> > 2) How exactly do you propose filtering IRPs? In a separate posting,
> you
> > mentioned IoAttachDeviceToDeviceStack, which suggests a WDM mechanism,
> but
> > I’m not sure whether TDI is intended for such, that is, whether it is
> set
> > up
> > that way. If, on the other hand, you intend to filter by overlaying
> the
> > TDI
> > driver’s entry points for IRP processing (TDI_FW), that would
> definitely
> > be
> > a no-no.
> >
> > 3) I believe there is a legitimate need for filter TDI IRPs, at least
> for
> > open. Firewalls, for example, typically require knowing who is the
> caller
> > of
> > a network service, and I think that that information is available only
> in
> > the originating thread, where a routine tries to open a socket or such
> > like.
> > I don’t think the information is going to be available at, say, the
> NDIS
> > level, which would ordinarily be the legitimate way of handling
> network
> > traffic.
> >
> > xxxxx@NAI.com wrote:
> >
> > > Does it mean do not attach to \Device\Tcp? or does it mean
> do
> > > not write TDI filter drivers?
> > >
> >
> > –
> > If replying by e-mail, please remove “nospam.” from the address.
> >
> > James Antognini
> > Windows DDK MVP
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@concord.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the system manager.
> > This footnote also confirms that this email message has been swept by
> > the latest virus scan software available for the presence of computer
> > viruses.
> >
> >
> >
> >
> > —
> > 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@concord.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

8

Max,
The thread and subject are totally different. The subject line
was took from old posting. The context is lost because some part of the
mail is deleted in responses.
As you have experience in TDI drivers, did you ever got a TDI
filter driver signed/certified from WHQL? I am under the impression that
TDI filter is one of those drivers which is not signed/certified by
WHQL. Am I wrong?

-Srin.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, July 25, 2003 1:57 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

Impossible. You can only save the remote address in filter’s
connect()
path
for later reuse.
For incoming connection, the remote address is provided to
ClientEventConnect.

Max

----- Original Message -----
From: “Curless, Jeffrey”
> To: “Windows System Software Developers Interest List”
>
> Sent: Friday, July 25, 2003 6:20 PM
> Subject: [ntdev] Re: Remote Address query with TDI
>
>
> > Yes that is what I am saying. I don’t think there is any Microsoft
> > sanctioned way of getting the information you need. Though a
winsock
> > helper DLL may do what you need (I have never written one).
> >
> > -Jeff
> >
> > -----Original Message-----
> > From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
> > Sent: Thursday, July 24, 2003 5:58 PM
> > To: Windows System Software Developers Interest List
> > Subject: [ntdev] Re: Remote Address query with TDI
> >
> >
> > Jeff,
> > I am little confused. Are you saying “I do believe the answer is
> > don’t attach to TCP or UDP or try to do TDI filtering.”?
> > Right now the ways I know to find the application doing network
> > activity.
> > 1. attach to Afd. This is more undocumented than TDI. And you would
miss
> > those connections the Tdi clients directly make using TDI interface
to
> > Tcp/udp.
> > 2. patching the dispatch entry points of Afd. Insane method and I do
not
> > see any advantage over the first one.
> > 3. attach to Tcp, udp, rawip. I have done this before and this is
better
> > way as I know of today. I found one application till now Novell
Netware
> > client(srvloc.sys) always manages to send requests directly to Tcp
> > device object instead of to the attached device object.
> > 4. patching the dispatch entry points of Tcp. I have not done
before,
> > and I am not even sure if it is worth the effort to follow this path
> > just to capture those connections like I mentioned in third case.
> >
> > Is there any other way such as writing an upper filter to tcpip
driver
> > and I would receive all the requests before sent to tcp/udp/rawip
> > devices? Or some other magic which Microsoft approves?
> >
> > Jeff & James,
> > I really appreciate your responses. I have been responding to
> > Tdi filter & Client driver queries on this list, but I my self am
not
> > sure of Microsoft approved way of doing this. I don’t even know if
there
> > is a Microsoft suggested way?
> >
> > -Srin.
> >
> > > -----Original Message-----
> > > From: Curless, Jeffrey [mailto:xxxxx@concord.com]
> > > Sent: Thursday, July 24, 2003 1:57 PM
> > > To: Windows System Software Developers Interest List
> > > Subject: [ntdev] Re: Remote Address query with TDI
> > >
> > > I can’t answer the original question either, but I can tell you I
have
> > > attached to
> > > both TCP and UDP using IoAttachDevice, to do TDI filtering. I do
> > believe
> > > the answer
> > > is don’t attach to TCP or UDP or try to do TDI filtering.
> > >
> > > In answer to 3 below, yes there is need for TDI filtering because
at
> > the
> > > NDIS
> > > layer packets can and are sent in an arbitrary thread context. I
made
> > a
> > > two
> > > layer driver before that correlated packets being sent to the
process
> > that
> > > created
> > > the connection.
> > >
> > > It would be nice if Microsoft either added support for TDI
filtering,
> > or
> > > the ability to know what process/thread/user opened the connection
to
> > > NDIS.
> > >
> > > -Jeff
> > >
> > >
> > > -----Original Message-----
> > > From: James Antognini [mailto:xxxxx@mindspring.nospam.com]
> > > Sent: Thursday, July 24, 2003 4:35 PM
> > > To: Windows System Software Developers Interest List
> > > Subject: [ntdev] Re: Remote Address query with TDI
> > >
> > >
> > > I cannot answer the question. In fact, I’m interested in the
answer.
> > But
> > > let
> > > me add a few points:
> > >
> > > 1) I’ve heard that TDI is likely to change in the future.
> > >
> > > 2) How exactly do you propose filtering IRPs? In a separate
posting,
> > you
> > > mentioned IoAttachDeviceToDeviceStack, which suggests a WDM
mechanism,
> > but
> > > I’m not sure whether TDI is intended for such, that is, whether it
is
> > set
> > > up
> > > that way. If, on the other hand, you intend to filter by
overlaying
> > the
> > > TDI
> > > driver’s entry points for IRP processing (TDI_FW), that would
> > definitely
> > > be
> > > a no-no.
> > >
> > > 3) I believe there is a legitimate need for filter TDI IRPs, at
least
> > for
> > > open. Firewalls, for example, typically require knowing who is the
> > caller
> > > of
> > > a network service, and I think that that information is available
only
> > in
> > > the originating thread, where a routine tries to open a socket or
such
> > > like.
> > > I don’t think the information is going to be available at, say,
the
> > NDIS
> > > level, which would ordinarily be the legitimate way of handling
> > network
> > > traffic.
> > >
> > > xxxxx@NAI.com wrote:
> > >
> > > > Does it mean do not attach to \Device\Tcp? or does it
mean
> > do
> > > > not write TDI filter drivers?
> > > >
> > >
> > > –
> > > If replying by e-mail, please remove “nospam.” from the address.
> > >
> > > James Antognini
> > > Windows DDK MVP
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@concord.com
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> > >
> > >

> > > This email and any files transmitted with it are confidential and
> > > intended solely for the use of the individual or entity to whom
they
> > > are addressed. If you have received this email in error please
notify
> > > the system manager.
> > > This footnote also confirms that this email message has been swept
by
> > > the latest virus scan software available for the presence of
computer
> > > viruses.
> > >
> > >
> > >
> > >
> > > —
> > > 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@concord.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@nai.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

9

> As you have experience in TDI drivers, did you ever got a TDI

filter driver signed/certified from WHQL? I am under the impression that
TDI filter is one of those drivers which is not signed/certified by
WHQL. Am I wrong?

WHQL has the “H” letter, which is “Hardware”. I don’t think there are any WHQL
for non-hardware drivers.

I only written the kernel sockets library, not TDI filters.

Max

10

Anti-virus filters can now be certified, I believe… this may be the
single exception.

Maxim S. Shatskih wrote:

>As you have experience in TDI drivers, did you ever got a TDI
>filter driver signed/certified from WHQL? I am under the impression that
>TDI filter is one of those drivers which is not signed/certified by
>WHQL. Am I wrong?

WHQL has the “H” letter, which is “Hardware”. I don’t think there are any WHQL
for non-hardware drivers.

I only written the kernel sockets library, not TDI filters.

Max

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

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

–

  • Nick Ryan (MVP for DDK)
11

Max,
That is wrong, if you see the WHQL site Microsoft certifies
software only NDIS IM drivers for Windows 2000 and XP.

-Srin.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, July 25, 2003 5:11 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Remote Address query with TDI

> As you have experience in TDI drivers, did you ever got a TDI
> filter driver signed/certified from WHQL? I am under the impression
that
> TDI filter is one of those drivers which is not signed/certified by
> WHQL. Am I wrong?

WHQL has the “H” letter, which is “Hardware”. I don’t think there are
any
WHQL
for non-hardware drivers.

I only written the kernel sockets library, not TDI filters.

Max

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

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