If TDI is deprecated on vista platform, are there alternative technologies to replace tdi as netwo

Discussion in 'Windows Vista Drivers' started by flyingco, Jun 16, 2007.

  1. flyingco

    flyingco Guest

    Thomas F. Divine have said :
    Vista kernel-mode network is (almost) completely new. In the new
    architecture TDI is deprecated. There is only limited TDI support in
    Vista
    for legacy TDI clients.

    I have known that one of the best merits of TDI technology is that
    it can relate network data package with the process. it means that we
    can identify the process name and the using ports which is
    communicating by intercepting the data package.

    Now , microsoft has deprecated the use of tdi client. whether
    Microsoft has provided other technologies to implement the same goal.
     
    flyingco, Jun 16, 2007
    #1
    1. Advertisements

  2. flyingco

    Anton Bassov Guest

    Vista kernel-mode network is (almost) completely new. In the new
    Well, according to MSFT, "proper" TDI filters still work under Vista,
    although the ones that hook functions in TCPIP.SYS's DRIVER_OBJECT do not
    (under Vista,
    \\Device\\Tcp and friends are created not by TCPIP.SYS but by TDX.SYS,
    which happens to be just a kernel-socket client of TCPIP.SYS). According to
    MSFT, if you attach your filtering device objects to the ones created by
    TDX.SYS, all calls to TCPIP.SYS that AFD.SYS makes will be routed via
    TDX.SYS, so that your TDI filter will still work.....


    Actually, the above is not some "merit" of TDI, but a basic feature of TCPIP
    - combination of the local address, protocol and port number uniquely
    indentifies a process. The above info *may* be supplied by a client with
    IRP_MJ_CREATE request that always gets received by TCPIP.SYS in context of
    the requesting process - this is why you can identify the target process at a
    lower level simply by analyzing packet headers. However, please note that a
    process is not required to submit either local address or port number with
    IRP_MJ_CREATE, and if it does not, TCPIP will choose the local address and
    port number itself (unless your filter does it on its own initiative before
    passing the request down to TCPIP, of course). In such case, you are unable
    to identify the target process simply by analyzing a packet header - the only
    one who can do it is TCPIP.SYS itself
    Well, it did provide a filtering platform that offers quite a few filtering
    levels and, *at some certain levels*, allows you to relate a packet to a
    process. Please check
    WFP documentation. Unfortunately it is, softly speaking, "imprecise" (if you
    call things with their real names, it is just inadequate, at least the one
    that comes with WDK, although MSFT later provided an update on their site)

    Anton Bassov
     
    Anton Bassov, Jun 16, 2007
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.