I am implementing software encryption for certain 802.11 frames in a Native
Wi-Fi NDIS miniport. In order to encrypt a frame, some additional data
needs to be inserted between the 802.11 MAC header and the rest of the
frame data.
During miniport initialization I’ve asked for sufficient DataBackFillSize.
In order to insert the additional data in MiniportSendNetBufferLists, I
want to retreat with NdisRetreatNetBufferDataStart by the size of
additional data, move the 802.11 MAC header back to the new data offset,
and fill the newly available space between the header and the rest of the
frame data with the additional data.
With the additional data in place, I can go ahead and send the NET_BUFFER
to the hardware. After the hardware completes the send, the documentation
topic “Extending Packet Data During Send Operations” makes it clear that
before calling NdisMSendNetBufferListsComplete, I must advance the data
offset with NdisAdvanceNetBufferDataStart back to the original data offset.
What is unclear to me is whether I am required to actually move back the
802.11 MAC header back to its original offset. If I simply advance to the
same offset without moving the header, when the sending layer (e.g.,
nwifi.sys) sees the send completion, the NET_BUFFER’s data offset doesn’t
actually point to the MAC header. This feels wrong, but on the other hand
the entire purpose of the data back fill size facility is to allow you to
do things like extending the MAC header (e.g., to introduce the 802.11 QoS
control field). Is it the case that whenever you extend the MAC header in
such a manner you are required to undo your changes before indicating send
completion so the sending layer still sees the original MAC header in the
same position as before?
In general is a miniport even allowed to modify the data of a NET_BUFFER it
is handed to send in-place? E.g., if I modify the frame data and replace it
with encrypted data am I required to restore the original contents before
returning the NET_BUFFER to the sender?
Regards,
Koby