NDIS intermediate driver to TDI question

device driver

    Sponsored Links


  • 1. sign a VPN driver
    Hi, We have a VPN driver that is a "virtual" NDIS miniport driver. Is it possible to get it signed by Microsoft so that no warning pops up at installation time? Thanks, Ning
  • 2. serial device driver communicating with java comm api.
    I am writing a serial device driver for a custom piece of hardware on Windows XP. I am interfacing to an application that uses the java comm api. I am wondering how the driver is supposed to notify the application when data is received. I believe there is event listener and the driver is supposed to trigger a DATA_AVAILABLE event somehow in the java api. I have looked at the serial port driver that ships with the windows xp ddk and it looks like if there is no read IRP outstanding the rx data just gets dumped in an internal interrupt buffer. How does the serial device driver get the rx data to the java comm. api? Any help would be greatly appreciated.
  • 3. Replace olde OEM*.INF or not?
    I am using SetupCopyOEMINF, but it adds a new OEM*.INF to the %systemroot%\inf folder and later the user is presented with a choice of which driver to select for his device. I am writing a windows installer custom action to update device drivers from an original install. These are 1394 devices which can stack so there may be several present and nonpresent devices. I am using the DDK's toaster as an example. I am using SetupCopyOEMINF, but it adds a new OEM*.INF to the %systemroot%\inf folder and later the user is presented with a choice of which driver to select for his device. Later I find all the present or nonpresent devices, update the present degvices using UpdateDriverForPlugAndPlayDevices and mark the nonpresent devices for later update. I have seen driver updaters that do not present the user with this choice and am wondering if that was because the old OEM*.INF was removed or overwritten or if there was some other technique for getting the driver update to recognize the newer driver without asking the user. Thanks. ARGold

NDIS intermediate driver to TDI question

Postby Pawan Singh » Tue, 05 Aug 2003 03:35:31 GMT


We are trying to write an NDIS intermediate driver which intercepts certain
packets before hitting miniport driver and changes IP address and other
stuff and we want to send it over another interface on the machine. In order
to do this, we probably have to send the packet up the stack through the TDI
interface so that it is properly routed through the NDIS stack once again.

My question is:
1. Is it even possible to do this? I am assuming it is because certain IPsec
VPN drivers do similar stuff.
2. Is it possible to do this in reverse direction - i.e. once the reply
packets are at the top of TCP stack, I want to process them and re-insert
them at the low level intermediate driver?

Pawan Singh

Re: NDIS intermediate driver to TDI question

Postby stewo68 » Wed, 06 Aug 2003 02:01:13 GMT

NDIS intermediate drivers operate below the TDI level. Thus, in your
case, you can think of an IM as if it was a router outside the
machine. The router can manipluate and forward any packets to any port
as required. The router will of course not return a manipulated packet
back to the host's TCP/IP stack.

If you can manage to implement your IM such that it can operate as if
it was running in an independant router (gateway) then the answer to
1) is yes.

 host <--> router <===> other IP segments

Same for 2). No way I can (currently) think of to "filter" packets
above the TCP/IP (WinSock) level.

On Sun, 3 Aug 2003 11:35:31 -0700, "Pawan Singh" < XXXX@XXXXX.COM >

NDIS intermediate driver to TDI question

Postby Steve Jackowski » Wed, 06 Aug 2003 06:11:15 GMT

Hi Pawan,

Our DNE product is a generic NDIS shim that allows you to 
develop plugin drivers that run under our WHQL digital 
signature.  DNE allows you to inspect, modify, redirect, 
insert and delete packets.  A plugin written for one OS 
runs on all Windows platforms (95, 98, ME, NT, 2K, XP, 
2003), and on Linux, Solaris, HP-UX, CE/PocketPC, etc.  
You can change addresses and redirect over LAN or WAN 
connections.  Most IPSEC drivers are DNE plugins.

From what you've described, you don't need to go up 
through the stack.  You can query the route table if you 
need to do routing.  Or, if you know the interface you 
want to send over, you can do that directly.  

Wrt using TDI, first, keep in mind that TDI is different 
on each Windows platform.  Next, TDI uses an IOCTL 
interface from user space to access the stack.  While it 
is possible to provide an IOCTL to IOCTL interface to 
facilitate driver to TDI interaction (we have done this), 
it's not easy. You could conceivably use and IOCTL 
interface to an application and then have the app use 
TDI, but I think performance would be a problem.  Plus, 
IOCTLs are application driven, meaning you need to 
request the driver data explicitly.

If you can tell me more about exactly what you're trying 
to do, I may be able to give more detailed answers.  If 
you're thinking DNE might be worth exploring, feel free 
to email me directly.


intercepts certain
address and other
the machine. In order
stack through the TDI
stack once again.
because certain IPsec
once the reply
them and re-insert

Re: NDIS intermediate driver to TDI question

Postby Pawan Singh » Wed, 06 Aug 2003 10:17:37 GMT

i Steve,

This is what I am trying to do:

Assume that the PC has a physical adapter with a public IP address: and all its routing tables are properly set for proper IP
communication. I want to create a private tunnel over a UDP port or TCP port
over this public network. But I want to create a virtual adapter with an
internal IP address e.g. So now to all the user applications it
looks like that the PC has two interfaces - one connecting it to public IP
network and the other one connecting it to a private IP network. When an
application sends packet to private 10 network, my intermediate driver will
receive this packet from TCP and modify this packet to correct source public
IP address and correct pre-configured public destination IP address. (sort
of like VPN tunnels). Similarly when the packet is received by the
intermediate driver from lower layer, I need to undo the IP address
translation based on certain characteristics of the packet e.g. certain UDP
or TCP port.

My questions are:
1. Is it possible to do this without touching TDI? Is it possible to do this
completely inside a single intermediate driver which creates a virtual
adapter and handles both inbound and outbound traffic seemlessly?

2. My lack of knowledge of NT TCP stack raises another question: when a top
layer application wants to send packets to the private network, who handles
"ARP". E.g. if my virtual address is and other end of the tunnel
is and I go to a command window and type "ping" - how
are the ARP packet and ICMP Echo packets going to be handled since my driver
is only going to intercept packets for certain TCP or UDP ports. Are these
handled by Windows TCP/IP stack automatically? I think my IM driver would
need special case code so that these packets are sent over the public
network in the tunnel.

3. How does the virtual adapter get its virtual "MAC address"? I guess
another way of asking #2 is who handles layer two and ICMP stuff?

I would be interested in using your DNE product if you think your product
can help me achieve some of these goals.

Thanks in advance,
Pawan Singh

"Steve Jackowski" < XXXX@XXXXX.COM > wrote in message
news:04da01c35acc$f1063550$ XXXX@XXXXX.COM ...

Re: NDIS intermediate driver to TDI question

Postby Maxim S. Shatskih » Thu, 07 Aug 2003 13:21:39 GMT

> 2. My lack of knowledge of NT TCP stack raises another question: when a top

ARP packets are sent by TCPIP to the same underlying adapter as the IP packets.
So, your virtual adapter or IM code must be ready for this.


Similar Threads:

1.Understanding Differences between NDIS intermediate and TDI Drivers

Hi all,
I have recently started researching into windows xp drivers, trying to
understand the possible driver types to use for the project I am
working on. This project is to create a firewall, and I wish it to be
able to filter with regard to IP headers, as well as TCP, UDP, ICMP
etc. Initially I looked into a filter hook, but I believe an NDIS
intermediate driver would be a lot more suitable method to use as it
is directly in the network stream, rather than hooking into the

Now I want to stress that I have limited knowledge on drivers,
especially limited understanding of them. I have tried reading the DDK
and various sources I can find, but things are still a bit hazzy. I
*think* the NDIS intermediate driver catches all packets received/sent
before the protocol drivers etc, and TDI's are further above here, but
I understand them less.

What I really need to understand quickly, is what can be filtered via
a NDIS intermediate driver, and what can be filtered at TDI. Can NDIS
filter with regard to network and transport headers? (ip, and
TCP/UDP/ICMP...) If so, is it more advantageous to use them since they
catch traffic before it gets to the TCP/IP stack?

Sorry for sounding like i know nothing, I really would love to
research it better and understand it better myself before bugging
others, but I need to grasp these concepts a bit quicker for my
research deadlines.

Thanks in advance for any help/tips/info :)

2.NDIS-TDI Example Question

Hey There,
    Thanks for the info. I was wondering if anyone out there knows of
any good TDI-NDIS examples. I'm not sure how to implement TDI to be
used above NDIS.

(patelj27b at gmail dot com)

3.question about NDIS intermediate driver

Hi all,
    I am writing a NDIS intermediate driver, I faced a strange problem. the
driver worked normal, Howerver, the computer which installed the driver
can't connect the internet(http, Email, and so on) sometime. Please guide...


4.Ndis Intermediate driver questions

As I said before, I'm using the Passthru example as my basis, and this is my
first drive (woo hoo).

Got some more questions:

The passthru example calls NdisFreePacket() after calling NdisSend() instead
of calling NdisReinitializePacket() and re-using the packet as suggested in
the docs. Any reason for this or just laziness? Are there any limitations on
either method or is the NdisReinitializePacket() preferred simply for
performance reasons?

At the very least, I want to support Windows XP and Windows 2000. I don't
care about Windows 98, but Windows NT support would be nice (though not
crucial). If I go with NT, I'm relegated to NDIS 4.0. or 4.1 (if I assume
SP3). How does one usually handle this? Develop for the lowest common
denominator or do a different build for each version?

My last question is in regards to something I read regarding modifying
packets. It basically said you can't modify packets sent by the miniport.
Does this apply to copies I make of that packet? In other words, if I make a
copy of the packet and then modify it, and then call NdisSend() with my
modified packet, it's the modifed packet that's going to go out, right?

Just trying to ensure I understand what's going on here. Thanks.


5.NDIS Intermediate Drivers (Ndis.lib library conflicts)


I built(config is Pocket PC) the NDIS intermediate driver under 
eVC 3.0 and linked to ndis.lib, ntcompat.lib etc. from PPC 2002

It works fine for PPC 2002 device

1. Under Pocket PC (PPC 2000) - Stops at
When I looked at Ndis.lib under Pocket PC, its different from PPC2002
and in fact NdisIMRegisterLayeredMiniport function is NOT there in
PPC2000 ndis.lib. If I link with ndis.lib from PPC2000, I get few
linker errors for missing functions like

2. Under Pocket PC 2003 - Underlying miniport Resets at the first
MiniportQueryInformation call.

How to build or write a NDIS Intermediate driver that runs across
these different devices?

Any suggestions?? 

Note: Its not a complex driver using too many functionalities. Basic


6. NDIS Intermediate Driver (Ndis.lib conflicts)

7. NDIS 5.x to NDIS 6 migration - some questions

8. Traffic Monitor Using TDI or NDIS

Return to device driver


Who is online

Users browsing this forum: No registered users and 19 guest