Re: modify packet in IM driver

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Although this is true of NDIS5 (that you may not modify a packet in the send path) this is no longer true of NDIS6. On the send path, each component specifies it 'header' requirements and the sender is required to allocate NetBuffer(s) with the required 'head-room' for packet header insertion. The rule as applied in this scenario is that a NetBuffer must be restored to its original form prior to being returned.

At least that is what the NDIS6 documentation says. I think E.Y. has leveraged this 'feature' of NDIS6 NB handling in the MUX sample.

I think, however, that the MUX sample might have been a bit more clear about this.

However, I agree with Stephan that a component should really not be modifying the data. Inserting a VLAN tag might be handled by:

1. Retreate the NetBuffer to 'remove' the MAC header.
2. Clone the NetBuffer.
3. Advance the Clone NetBuffer to open up space for the MAC header + VLAN_TAG.
4. Write the new MAC header+Tag to the Clone NB.
5. Send the Clone NB.

This is essentially the same operation one performs in NDIS5 of

1. Allocate a new NDIS_PACKET.
2. Allocate a NDIS_BUFFER to describe the 'partial' first buffer beyond the MAC header & chain it to the packet at the front.
3. Allocate a NDIS_BUFFER & memory to contain the MAC address + VLAN_TAG & chaint it to the packet at the front.
4. Chain the original packet buffer chain 'second' through 'last' buffers at the back of the packet.


You will not in the sample MUX for NDIS6 that E.Y. has gone to great pains to ensure that the resulting MAC header is contiguous in the resulting MDL and that it does not 'span' a pages described by two MDLs. This, as in NDIS5, is still a requirement on the send path.

But in a single send path the 'header' space in a NB is writeable as long as it is 'restored' before returning. A bit confusing for the NDIS5 world.

Good Luck,
Dave Cattley
Consulting Engineer

"Stephan Wolf [MVP]" <stewo68@xxxxxxxxxxx> wrote in message news:e97a7fc5-99c0-41c6-b6b4-85d5b89631f4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You are right, modifying an NDIS_PACKET in place is illegal by
specification. IIRC, the NDIS 5 IM sample did the same thing.

The MS guy whose initials are EY could probably fix this ;)

Thanks, Stephan
---
On Dec 18, 8:21 pm, vsh <vpal...@xxxxxxxxxxx> wrote:
Hi ,

I want to modify src mac address in the outgoing packet in IM driver.

While looking into vlan (mux) header modification code , in wdk , NDIS
6.0

pEthFrameNew = NdisGetDataBuffer(CurrentNetBuffer,
VLAN_TAG_HEADER_SIZE,
NULL,
1,
0);

if (pEthFrameNew == NULL)
{
NdisAdvanceNetBufferDataStart(CurrentNetBuffer,

VLAN_TAG_HEADER_SIZE,
FALSE,
NULL);

Status = NDIS_STATUS_INVALID_PACKET;
}
else
{
//
// Adjust the header to insert the VLAN tag in the
packet frame
//
NdisMoveMemory(pEthFrameNew, pEthFrame, 2 *
ETH_LENGTH_OF_ADDRESS);
}

the packet is modified in place. Is it the correct behaviour?
How can IM driver modify the packet , that does not belong to it ?

Thanks
Vaishali

.

Relevant Pages