Re: IP Option Header

Getting process context in pre-Vista at NDIS packet level is a hard task,
usually it requires the TDI filter in addition to the NDIS IM.

Probably it is possible to query the TCP connection table by
IOCTL_TCP_QUERY_INFORMATION_EX from kernel mode, but this is a) undocumented,
your only chance is to reverse-engineer the user-mode IP Helper API DLLs which
are wrappers around this IOCTL and b) I have doubts that Windows pre-2003 kept
the process ID in this table, this is possibly introduced with 2003 only.

Gettting the process ID from the TCP connection info on pre-2003 Windows
is, in fact, 100% undocumented, no documented ways at all.

So, you will need a TDI filter or a user-mode WinSock LSP DLL. First is
undocumented.

Injecting the options is by far simpler using an NDIS IM.

Probably WFP in Vista solves this.

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

"rrubino" <rrubino@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:35271EEC-9BB2-4225-92C1-AFDB1C00140D@xxxxxxxxxxxxxxxx
Hello everyone, this is my first post ever on the MSDN managed newsgroups.
I'm moving into the prototype phase of my CS PhD dissertation and I need to
construct a software component which will introduce an IP option header into
each IP packet. Initially I am targeting IPv4, however eventually I will
need to work with IPv6. Windows is my development platform of choice,
however I am flexible in regards to Vista or XP; whichever is easier to
develop this on will be the winner. One of the requirements is that the data
in the option header will be influenced by the process that generated the
packet. I've done some reading and I've seen some implementations as an
intermediate miniport drive on XP. I'm not sure if WFP on Vista will fit the
bill. What I'm looking for is some guidance as to how to go about developing
such a component. What is the preferred technology to use (NDIS, WFP, etc)
in regards to learning curve, ease of development, etc? How would I go about
debugging such a component? Will the inevitable programming errors lead to a
BSOD? Any advice will be greatly appreciated!

.

Relevant Pages

  • Re: Access to NDIS Intermediate Driver from user application
    ... A stream interface with specific Ioctl should do it well ... Windows Embedded Manager ... > We have an NDIS intermediate driver developed for Windows NT. ... The communication between the NDIS IM and packet processing ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Access to NDIS Intermediate Driver from user application
    ... Windows Embedded Manager ... > We have an NDIS intermediate driver developed for Windows NT. ... The communication between the NDIS IM and packet processing ... > with the NDIS IM using Device Objects. ...
    (microsoft.public.windowsce.embedded)
  • Access to NDIS Intermediate Driver from user application
    ... We have an NDIS intermediate driver developed for Windows NT. ... NDIS IM intercepts packets and sends it to another module for packet ... The communication between the NDIS IM and packet processing ...
    (microsoft.public.windowsce.platbuilder)
  • Access to NDIS Intermediate Driver from user application
    ... We have an NDIS intermediate driver developed for Windows NT. ... NDIS IM intercepts packets and sends it to another module for packet ... The communication between the NDIS IM and packet processing ...
    (microsoft.public.windowsce.embedded)
  • RE: about SMB
    ... If you use a Tdi Filter yes you can hold the IRP which contains the packet ... if you use NDIS IM you can hold and Queue the packet internally in the driver. ...
    (microsoft.public.development.device.drivers)
Loading