Strange packet size returned by NdisQueryPacket

Skaramush · March 5, 2009, 8:08am

Hi all,

I’m working on NDIS miniport driver based on kmdf ndisedge sample from WDK. I observe a strange problem.

From my SendPacketsHandler callback, I use the NdisQueryPacket(packet, NULL, NULL, NULL, &packetLen) call to retrieve the length of the current size of each packet.

Then, I use the following sequence to fill the data from the packet to be sent to the device:

NdisQueryPacket(packet, NULL, NULL, &currentBuf, NULL);

while (currentBuf)
{
NdisQueryBufferSafe(currentBuf, &virtualAddr, &currentLen,
NormalPagePriority);
check_validity(vitrualAddr, currentLen, packetLen);

/* Copy the data. */
NdisMoveMemory(ethFrame, virtualAddr, currentLen);
ethFrame += currentLen;
NdisGetNextBuffer(currentBuf, &currentBuf);
}

In general, it works fine, but sometimes when I call for
NdisQueryPacket(packet, NULL, NULL, NULL, &packetLen)

I get strange values, like 0x3f00000. I can assume that NDIS packet may be larger then the included Ethernet frame it contains, but I would assume a spare of a couple of bytes. The value I get seems to me illegal.

This is NDIS 5.1 miniport, and I observed the problem on Vista (didn’t meet it in XP yet).
What could it be?

Thanks,
S.

Skaramush · March 5, 2009, 10:11am

From additional review of the code it seems that the problem occurs when postponing the packets handling, i.e:
Store packet in a list:
NdisInterlockedInsertTailList(&adapter->sendWaitList,
(PLIST_ENTRY)&packet->MiniportReserved[0],
&adapter->sendLock);
and call for
NdisMSendComplete(adapter, packet, NDIS_STATUS_PENDING);
Then call for:
pEntry = (PLIST_ENTRY) NdisInterlockedRemoveHeadList(
&adapter->sendWaitList,
&adapter->sendLock);
if (!pEntry)
error;
packet = CONTAINING_RECORD(pEntry, NDIS_PACKET, MiniportReserved);
NdisQueryPacket(packet, NULL, NULL, NULL, &packetLen);
Here the problem occurs.

Also, If I call for NdisQueryPacket(packet, NULL, NULL, NULL, &packetLen) before storing the
packet in the list, then when I call for it again, it returns the correct value, but then the following
calls for
NdisQueryPacket(packet, NULL, NULL, &currentBuf, NULL);
and
NdisQueryBufferSafe(currentBuf, &virtualAddr, &currentLen, NormalPagePriority);
fail - the currentLen size holds incorrect value (4718593), as well does virtualAddr (00000002).

Is here any problem with storing the packets for postponed processing?

Thanks,
S.

David_R_Cattley · March 5, 2009, 12:03pm

First of all

Indicates that you have a serious misunderstanding. This is illegal. You
cannot simultaneously tell NDIS that the send is complete and is pending.

In any event, the packet is no longer yours after calling this routine. Any
access to it is going to result in failure (like yours).

You only call NdisMSendComplete() when you have *COMPLETED* sending the
packet.

The mere fact that the upper bound protocol gave you a packet to send is an
act of transfer of ownership - the packet is yours, and is ‘pending’ until
you give it back. Once NdisMSendComplete() is called, the packet ownership
is transferred back to the sending protocol (or at least it relinquished by
your driver).

Too bad you don’t have the checked build of NDIS installed. I believe it
would have thrown a nutty when you called NdisMSendComplete(…,
NDIS_STATUS_PENDING).

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, March 05, 2009 10:12 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Strange packet size returned by NdisQueryPacket

From additional review of the code it seems that the problem occurs when
postponing the packets handling, i.e:
Store packet in a list:
NdisInterlockedInsertTailList(&adapter->sendWaitList,
(PLIST_ENTRY)&packet->MiniportReserved[0],
&adapter->sendLock);
and call for
NdisMSendComplete(adapter, packet, NDIS_STATUS_PENDING);
Then call for:
pEntry = (PLIST_ENTRY) NdisInterlockedRemoveHeadList(
&adapter->sendWaitList,
&adapter->sendLock);
if (!pEntry)
error;
packet = CONTAINING_RECORD(pEntry, NDIS_PACKET, MiniportReserved);

NdisQueryPacket(packet, NULL, NULL, NULL, &packetLen);
Here the problem occurs.

Also, If I call for NdisQueryPacket(packet, NULL, NULL, NULL, &packetLen)
before storing the
packet in the list, then when I call for it again, it returns the correct
value, but then the following
calls for
NdisQueryPacket(packet, NULL, NULL, &currentBuf, NULL);
and
NdisQueryBufferSafe(currentBuf, &virtualAddr, &currentLen,
NormalPagePriority);
fail - the currentLen size holds incorrect value (4718593), as well does
virtualAddr (00000002).

Is here any problem with storing the packets for postponed processing?

Thanks,
S.

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

Skaramush · March 8, 2009, 5:11am

Hello David,

Thanks a lot for your input. Indeed, I didn’t understand that part correctly.
I’ll change my code and check it.

Too bad you don’t have the checked build of NDIS installed. I believe it would have thrown a nutty
when you called NdisMSendComplete(…, NDIS_STATUS_PENDING).
Do I need the checked version of OS for that?

Thanks,
S.

David_R_Cattley · March 8, 2009, 1:20pm

In the past (2K3 and earlier) to replace just NDIS.SYS with it’s checked
build version. I don’t know about Vista/LH+. I generally just run the
full checked build when possible during early development and only switch to
the free build when necessary and for DTM testing. Not all circumstances
allow this of course.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

wrote in message news:xxxxx@ntdev…
> Hello David,
>
> Thanks a lot for your input. Indeed, I didn’t understand that part
> correctly.
> I’ll change my code and check it.
>
>> Too bad you don’t have the checked build of NDIS installed. I believe it
>> would have thrown a nutty
>> when you called NdisMSendComplete(…, NDIS_STATUS_PENDING).
> Do I need the checked version of OS for that?
>
> Thanks,
> S.
>
>

OSR_Community_User · March 9, 2009, 9:43am

I assume that you can just change the ‘ImagePath’ entry for ndis.sys without getting in to the
problems of replacing a system file on Vista+.

mm

David R. Cattley wrote:

In the past (2K3 and earlier) to replace just NDIS.SYS with it’s checked
build version. I don’t know about Vista/LH+. I generally just run the
full checked build when possible during early development and only
switch to the free build when necessary and for DTM testing. Not all
circumstances allow this of course.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

wrote in message news:xxxxx@ntdev…
>> Hello David,
>>
>> Thanks a lot for your input. Indeed, I didn’t understand that part
>> correctly.
>> I’ll change my code and check it.
>>
>>> Too bad you don’t have the checked build of NDIS installed. I believe
>>> it would have thrown a nutty
>>> when you called NdisMSendComplete(…, NDIS_STATUS_PENDING).
>> Do I need the checked version of OS for that?
>>
>> Thanks,
>> S.
>>
>>
>

David_R_Cattley · March 9, 2009, 10:31am

I can’t say that I ever tried that. My target systems just go through a
lifecycle of

Full Checked Build
Limited Checked Components (NT, HAL, NDIS)
Free Build
Lather-Rinse-Repeat (they only live for the 30/60/90 day timebomb)

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, March 09, 2009 9:44 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Strange packet size returned by NdisQueryPacket

I assume that you can just change the ‘ImagePath’ entry for ndis.sys without
getting in to the
problems of replacing a system file on Vista+.

mm

David R. Cattley wrote:

In the past (2K3 and earlier) to replace just NDIS.SYS with it’s checked
build version. I don’t know about Vista/LH+. I generally just run the
full checked build when possible during early development and only
switch to the free build when necessary and for DTM testing. Not all
circumstances allow this of course.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

wrote in message news:xxxxx@ntdev…
>> Hello David,
>>
>> Thanks a lot for your input. Indeed, I didn’t understand that part
>> correctly.
>> I’ll change my code and check it.
>>
>>> Too bad you don’t have the checked build of NDIS installed. I believe
>>> it would have thrown a nutty
>>> when you called NdisMSendComplete(…, NDIS_STATUS_PENDING).
>> Do I need the checked version of OS for that?
>>
>> Thanks,
>> S.
>>
>>
>

—
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

Skaramush · March 10, 2009, 3:59am

People,

Thanks a lot for the info.

S.