Over the past few years I've had many requests to add an interface to allow
user-mode Win32 applications to take advantage of ndis3pkt's "virtual" NDIS
intermediate driver technology.  This could permit applications to pre- and
post-process frames received and sent by Microsoft's tcp/ip stack for filtering,
firewalling, etc.  Back-of-the-hand analysis has always made me believe that
the context switching associated with such an implementation would severely
degrade performance of the tcp/ip system; however, there was so much interest
that I decided to give it a try.  Initial tests suggest that the performance
is not great (as I expected) but the interface may be useful at least for
prototyping filter applications without having to write driver code.

The interface is composed of several new functions and flags.


nd_send_to_tcp(int unit, char *data, int len, int hlen)

This function sends a frame to MSTCP just as if it had been received from
the network.  The len is the total length of the frame and hlen is the
hardware header portion (e.g., 14 for Ethernet and emulations thereof).


nd_send_as_tcp(int unit, char *data, int len)

This function is identical to nd_send_pkt except that ndis3pkt's tcp/ip
multiplexor treats the frame as if it had been generated by MSTCP.


The ACCESS_FLAG_TUNNEL flag is applied to nd_access_type in the typelen
argument.  It indicates that the handle is to receive any packets that MSTCP
sends on the interface.  Only one handle on each interface can be opened in
TUNNEL mode.  As long as such a handle is open, MSTCP's normal reception of
packets is blocked (i.e., it receives packets only from nd_send_to_tcp) and
all packets that it sends are intercepted and rerouted to the handle.  When
the handle is released, MSTCP operation returns to normal.


The ACCESS_FLAG_ASMSTCP flag is applied to nd_access_type in the typelen
argument.  It indicates that, for purposes of ndis3pkt's tcp/ip multiplexor,
received frames are treated as if they were destined for MSTCP.


A typical Win32 intermediate filter would create two handles, one with
ACCESS_FLAG_TUNNEL and one with ACCESS_FLAG_ASMSTCP.  It would read from
the first handle, apply any desired changes to the output packets, and
then forward them to the network with nd_send_as_tcp.  It would read from
the second handle, apply and desired changes to the input packets, and
then forward them to MSCTP with nd_send_to_tcp.  Entire packets can, of
course, be added or deleted from the stream.


Defining WIN32_INTERMEDIATE in ndis3api.c will build a simple null filter
that creates the necessary handles and passes packets unchanged between
MSTCP and the network.