Can one modify received buffers?

NTDEV
1

The Microsoft Network Load Balancer has a bug that cause it to ?load balance? multicast packets. Consequently only one of the applications listening for the multicast packet in a NLB cluster actually receives it.
Given that the NLB never balances packets where the destination IP address is the machine?s dedicated address then I concluded that if I write a LWF that resides below the NLB (i.e. with a Custom or Diagnostic FilterClass) and have the ReceiveNetBufferListsHandler replace all multicast IP addresses with the dedicated address then I can work around the bug.

My question is can I overwrite the IP address in the received NET_BUFFER or do I have to clone the NBL and data first?

TIA Alan

2

> My question is can I overwrite the IP address in the received NET_BUFFER or do I have to clone the NBL and

data first?

Have to clone.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

That’s what I thought based on other responses here and elsewhere but while reading the docs further I came across this statement:

“Pass it on to the next overlying driver by calling NdisFIndicateReceiveNetBufferLists. The driver can modify the contents of the buffer.”

in Receiving Data in a Filter Driver - http://msdn.microsoft.com/en-us/library/ff570448(v=VS.85).aspx

which would indicate that one can modify the data before passing it up.

4

You don’t have to clone the entire NBL & all the data. You can keep the NBL and NB, advance the NB forward, insert a new MDL into the list, then retreat the NB back again. You need to undo all this on receive-return, which can be a little tricky if you don’t have a way to immediately identify whether any given NBL is one you’ve modified or not. I suppose you can allocate your new MDLs from a larger buffer, then on receive-return check if the CurrentMdl is within that large buffer.

Making a deep clone is way easier.

BTW, I don’t know if it’s any consolation, but the NLB team has actually considered the multicast-to-a-cluster issue, and believe the current behavior of NLB’s LWF to be by design.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@spherecom.com
Sent: Monday, April 18, 2011 5:51 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can one modify received buffers?

That’s what I thought based on other responses here and elsewhere but while reading the docs further I came across this statement:

“Pass it on to the next overlying driver by calling NdisFIndicateReceiveNetBufferLists. The driver can modify the contents of the buffer.”

in Receiving Data in a Filter Driver - http://msdn.microsoft.com/en-us/library/ff570448(v=VS.85).aspx

which would indicate that one can modify the data before passing it up.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Thanks for the response Jeffrey. Now I?m even more confused :frowning:
Can you explain what the doc I quoted above is referring to when it says you can modify the data in the buffer?

WRT to the NBL:
I would love to hear the rationale behind the decision to take multicast traffic which, by its very nature is intended to reach multiple destinations, and treat it as unicast. If an application only wanted to reach a single machine in an NBL environment then it would use unicast targeting the NLB virtual address. Not only does this design break our application but I understand Oracle and at least one other product are similarly broken.