Re: Question about modifing the NDIS packet?

From: William Ingle (williamingle_at_comcast.net)
Date: 07/05/04 

Date: Mon, 05 Jul 2004 15:00:33 GMT

Rajesh

A complete answer to your question requires us to know the OS you are
targeting because there are some differences between win98/ME, Win2k, WinXP
and Win2003

In general you need to allocate your own buffers if you are re-trasmitting a
packet FROM a miniport BACK of the net. If your driver is an intermediate
driver and it merely modifies the packet on its way to the protocol driver
or to a miniport then you only need to allocate a new buffer if

1. you driver changes the length of the ndis packet buffer - here you
allocate the appropriate packet buffer, not the packet structure
2. your driver changes the length of the ip header or oob data - here you
allocate the data buffer
3. your driver is not a registered ndis driver. In general ndis doesn't
notify a miniport or protocol to release buffers until all consumers have
indicated they are done with it. But you would have to be a registered
consumer (i.e. a miniport, protocol or intermediate driver) so ndis knew you
were part of the data flow.

If you are merely querying the packet from ndis through IoCallDriver or
DeviceIoControl then ndis assumes you are done with it when you return.
Futhermore modifications you make to the ndis packet may or may not be
passed on to other ndis drivers. This is why you should register your
driver with ndis during initialization and support one of the ndis driver
types.

This is a simplification because protocols often allocate data in their own
buffer pools and perform buffer integrity checks (like checking the internal
pointers of complex structures). Miniports often use memory on the card to
reduce the number of buffer copies. So if you are going to change some of
the internal pointers in the ndis packet structure you may want to create
your own copy if you can't re-assign the original pointer value when the
consumer returns. I haven't played with this in over a year so please
perform your own tests.

Have a great day
Bill

"Rajesh Gupta" <guptar@gmail.com> wrote in message
news:uXzZ5dWWEHA.3988@tk2msftngp13.phx.gbl...
> Hi everyone,
>
> I am trying to modify the NDIS packet. Do i need to allocate new buffers?
>

Relevant Pages

  • Re: NDIS functionality details
    ... In my driver I need to decompress compressed video data and provide ... >> NDIS subsystem exports a lot of functions with Ndis* prefix. ... >> DDK says, that there is two ways, one is to copy each packet to driver ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS functionality details
    ... Maxim Shatskih, Windows DDK MVP ... >>> possible to mix NDIS API with API, ... using any non-NDIS functions makes the driver fail ... >>> DDK says, that there is two ways, one is to copy each packet to driver ...
    (microsoft.public.development.device.drivers)
  • Cannot receive faked UDP packet (from NDIS filter driver, using select & recvfrom)
    ... I have a NDIS filter driver sitting on top of Ethernet connections (based on ... Host_B replies with a TCP SYN ACK packet, which is trapped by the NDIS ... NDIS driver repackages the TCP packet in a UDP packet (changes are ...
    (microsoft.public.development.device.drivers)
  • Re: xPC Serial Communication Problems
    ... never seen bytes get wrapped like you're seeing with the new driver. ... Everything about the packet looks just fine, ... reasonable facsimile) so the hardware buffer should be 16 bytes. ... does it wait until there are at least 15 characters in the receive ...
    (comp.soft-sys.matlab)
  • Re: Direct Copying To Share Memory In NDIS ProtocolReceive
    ... Application allocates large structured buffer with room for seveveral packets. ... Driver fills buffer with multiple packets and eventually completes the read IRP. ... This, or variations on this, should work for you withoug having to have shared memory and events that are not part of the standard I/O scheme. ... I am wondering if I can obviate much of the NDIS packet allocation by ...
    (microsoft.public.development.device.drivers)