NDIS_STATUS_BUFFER_TOO_SHORT vs. NDIS_STATUS_INVALID_LENGTH - I have lost my mind (did you find it?)

NTDEV
1

Ever have one of those nights when you lay awake and slowly convince
yourself that you no longer know anything? Well, lately, it has not taken
very much effort …

To wit:

The WDK Docs state quite clearly that for calls to
MiniportQueryInformation() if the supplied buffer length does not match the
required buffer length, the function should return
NDIS_STATUS_INVALID_LENGTH and place the required buffer length in
*BytesNeeded. Strangely, the older W2K3 DDK docs say that either
NDIS_STATUS_INVALID_LENGTH or NDIS_STATUS_BUFFER_TOO_SHORT are returned in
this case. I am not sure I understand the change in docs other than
perhaps the WDK team gets charged by the letter by MSDN to host the
documentation.

Well, for as long as I can remember (oh, lately, about 45 seconds or so),
MiniportQueryInformation() would typically return
NDIS_STATUS_BUFFER_TOO_SHORT in cases where the buffer was too small.

A quick survey of WDK samples shows that both the left and right hands at
MSFT are also just as tied in knots as my weak brain at this point since in
some samples you have one and other samples the other being returned from
MiniportQueryInformation(). Although I feel I am in good company, I still
don’t know how to recover my sanity.

As I think back (through the fog) I recall that the meaning of these two
return values was something like the following:

NDIS_STATUS_INVALID_LENGTH - the buffer you gave me is the wrong size. I
have written nothing or read nothing from it. The request is unprocessed.
I am giving you back the expected size so that you can try again, perhaps
getting it right the next time. Good Luck.

NDIS_STATUS_BUFFER_TOO_SHORT - the buffer you gave me is too short. I may
or may not have written or read a partial result from it. Check the
*BytesRead/*BytesWritten return if you care. In any event, I have returned
the length of the buffer that would allow the entire result to fit in
*BytesRequired. If you wish to try again, perhaps you could send me a
buffer of at least that size next time.

So let’s say that a protocol queries OID_802_3_CURRENT_ADDRESS and supplies
a request buffer with length less than ETH_ADDRESS_LEN (that is 6 for you
marketing types who read this list trying to play along .) , I would expect
NDIS_STATUS_INVALID_LENGTH but I cannot say that
NDIS_STATUS_BUFFER_TOO_SHORT is wrong.

However, for an OID_802_11_BSSID_LIST query that has *at least* the required
number of bytes to hold the header of the result, I would expect that if all
the BSSID entries did not fit in the supplied buffer, that the result could
plausibly be NDIS_STATUS_BUFFER_TOO_SHORT and maybe (depending on the
Miniport) the buffer would get a partial list. This could, of course, be
fantasy and I have no intentions of testing it. I use it as an illustration
of what I once thought the difference between the two status codes were.

Now the real question, of course, is what is NDIS expecting, what is WHQL
and NDISTest expecting, and just what is going to get me back to a restful
sleep tonight (Bookers, Bakers or Basil Haden perhaps)?

So if any of you can help me out here with a definitive clarification, I
greatly appreciate it. If it turns out that (as I have been apparently
treating it for 15+ years) that it does not matter, well, that is great too.

Cheers,

-dave

2

> I still don’t know how to recover my sanity.

I would say the best approach is just to do something that is not related to programming in any possible way…

So let’s say that a protocol queries OID_802_3_CURRENT_ADDRESS and supplies
a request buffer with length less than ETH_ADDRESS_LEN (that is 6 for you marketing
types who read this list trying to play along .) , I would expect NDIS_STATUS_INVALID_LENGTH
but I cannot say that NDIS_STATUS_BUFFER_TOO_SHORT is wrong.

… and, when you start thinking about Windows programming again, you will immediately realize that, as long as you return 0 bytes with NDIS_STATUS_BUFFER_TOO_SHORT, it is equivalent to NDIS_STATUS_INVALID_LENGTH…

Anton Bassov

3

Probably if you are generating error messages, then you should follow the
matching WDK/DDK advice. It seems that NDIS_STATUS_INVALID_LENGTH is
acceptable on all platforms.

If you are interpreting NDIS status codes, then treat both
NDIS_STATUS_INVALID_LENGTH and NDIS_STATUS_BUFFER_TOO_SHORT then same.
Personally, I treat both as if the buffer was too short, but. I also ignore
the “bytes needed” and just double the size of the query buffer. I do that
because in at least some cases bytes needed may be misleading. For example,
when querying a BSSID list the more BSSID items could (conceivably) be added
to the list since the previous query. So, even if you used bytes needed as
intended, the newt query could (conceivably) still come up short.

Alternative ideas is that the W2K3 documentation actually describes the
behavior of NDIS 5 miniports and the newer WDK documentation describes the
behavior of NDIS 6 miniports. Of course, on Vista you have both NDIS 5 and
NDIS 6 miniports. So, if you pre-fetched the miniport driver version you
could (waste of time IMHO.) perform NDIS version-dependent interpretation of
these two return values.

I think I found your mind. It was on an old DDK CD.

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, June 27, 2008 10:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS_STATUS_BUFFER_TOO_SHORT vs. NDIS_STATUS_INVALID_LENGTH

  • I have lost my mind (did you find it?)

Ever have one of those nights when you lay awake and slowly convince
yourself that you no longer know anything? Well, lately, it has not taken
very much effort …

To wit:

The WDK Docs state quite clearly that for calls to
MiniportQueryInformation() if the supplied buffer length does not match the
required buffer length, the function should return
NDIS_STATUS_INVALID_LENGTH and place the required buffer length in
*BytesNeeded. Strangely, the older W2K3 DDK docs say that either
NDIS_STATUS_INVALID_LENGTH or NDIS_STATUS_BUFFER_TOO_SHORT are returned in
this case. I am not sure I understand the change in docs other than
perhaps the WDK team gets charged by the letter by MSDN to host the
documentation.

Well, for as long as I can remember (oh, lately, about 45 seconds or so),
MiniportQueryInformation() would typically return
NDIS_STATUS_BUFFER_TOO_SHORT in cases where the buffer was too small.

A quick survey of WDK samples shows that both the left and right hands at
MSFT are also just as tied in knots as my weak brain at this point since in
some samples you have one and other samples the other being returned from
MiniportQueryInformation(). Although I feel I am in good company, I still
don’t know how to recover my sanity.

As I think back (through the fog) I recall that the meaning of these two
return values was something like the following:

NDIS_STATUS_INVALID_LENGTH - the buffer you gave me is the wrong size. I
have written nothing or read nothing from it. The request is unprocessed.
I am giving you back the expected size so that you can try again, perhaps
getting it right the next time. Good Luck.

NDIS_STATUS_BUFFER_TOO_SHORT - the buffer you gave me is too short. I may
or may not have written or read a partial result from it. Check the
*BytesRead/*BytesWritten return if you care. In any event, I have returned
the length of the buffer that would allow the entire result to fit in
*BytesRequired. If you wish to try again, perhaps you could send me a
buffer of at least that size next time.

So let’s say that a protocol queries OID_802_3_CURRENT_ADDRESS and supplies
a request buffer with length less than ETH_ADDRESS_LEN (that is 6 for you
marketing types who read this list trying to play along .) , I would expect
NDIS_STATUS_INVALID_LENGTH but I cannot say that
NDIS_STATUS_BUFFER_TOO_SHORT is wrong.

However, for an OID_802_11_BSSID_LIST query that has *at least* the required
number of bytes to hold the header of the result, I would expect that if all
the BSSID entries did not fit in the supplied buffer, that the result could
plausibly be NDIS_STATUS_BUFFER_TOO_SHORT and maybe (depending on the
Miniport) the buffer would get a partial list. This could, of course, be
fantasy and I have no intentions of testing it. I use it as an illustration
of what I once thought the difference between the two status codes were.

Now the real question, of course, is what is NDIS expecting, what is WHQL
and NDISTest expecting, and just what is going to get me back to a restful
sleep tonight (Bookers, Bakers or Basil Haden perhaps)?

So if any of you can help me out here with a definitive clarification, I
greatly appreciate it. If it turns out that (as I have been apparently
treating it for 15+ years) that it does not matter, well, that is great too.

Cheers,

-dave

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

4

Thomas, you don’t really mean to completely ignore the BytesNeed, do you?
Consider for example that in first call you give 512 bytes, and miniport
returns BytesNeed = 4KB.
Then, if you just double the size, it will take you 3 more attempts at least.

Maybe, the following recipe can be recommended for reading OID_802_11_BSSID_LIST
and similar data:

  • Start with a large buffer.
    The RAM is cheap; speed matters.Try to get the data from the first attempt.

  • Use BytesNeeded, if it looks reasonable
    (greater than the input size, and not TOO large: OID_802_3_CURRENT_ADDRESS
    can’t require 10 MBytes, neither OID_802_11_BSSID_LIST )

Add some extra, in case the data can grew up since the previous call:
at least, one max. size of the data item (not just 512 bytes, like WZC does).

  • When using partial input, check it well. The last item can be truncated.
    In case the total size or number of items is returned in the data header, it may be
    wrong (contain also the items that don’t fit).

Best regards,

–PA

“Thomas F. Divine” wrote in message news:xxxxx@ntdev…
Probably if you are generating error messages, then you should follow the matching WDK/DDK advice. It seems that NDIS_STATUS_INVALID_LENGTH is acceptable on all platforms.

If you are interpreting NDIS status codes, then treat both NDIS_STATUS_INVALID_LENGTH and NDIS_STATUS_BUFFER_TOO_SHORT then same. Personally, I treat both as if the buffer was too short, but. I also ignore the “bytes needed” and just double the size of the query buffer. I do that because in at least some cases bytes needed may be misleading. For example, when querying a BSSID list the more BSSID items could (conceivably) be added to the list since the previous query. So, even if you used bytes needed as intended, the newt query could (conceivably) still come up short.

Alternative ideas is that the W2K3 documentation actually describes the behavior of NDIS 5 miniports and the newer WDK documentation describes the behavior of NDIS 6 miniports. Of course, on Vista you have both NDIS 5 and NDIS 6 miniports. So, if you pre-fetched the miniport driver version you could (waste of time IMHO.) perform NDIS version-dependent interpretation of these two return values.

I think I found your mind. It was on an old DDK CD.

Thomas F. Divine

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, June 27, 2008 10:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS_STATUS_BUFFER_TOO_SHORT vs. NDIS_STATUS_INVALID_LENGTH - I have lost my mind (did you find it?)

Ever have one of those nights when you lay awake and slowly convince yourself that you no longer know anything? Well, lately, it has not taken very much effort …

To wit:

The WDK Docs state quite clearly that for calls to MiniportQueryInformation() if the supplied buffer length does not match the required buffer length, the function should return NDIS_STATUS_INVALID_LENGTH and place the required buffer length in *BytesNeeded. Strangely, the older W2K3 DDK docs say that either NDIS_STATUS_INVALID_LENGTH or NDIS_STATUS_BUFFER_TOO_SHORT are returned in this case. I am not sure I understand the change in docs other than perhaps the WDK team gets charged by the letter by MSDN to host the documentation.

Well, for as long as I can remember (oh, lately, about 45 seconds or so), MiniportQueryInformation() would typically return NDIS_STATUS_BUFFER_TOO_SHORT in cases where the buffer was too small.

A quick survey of WDK samples shows that both the left and right hands at MSFT are also just as tied in knots as my weak brain at this point since in some samples you have one and other samples the other being returned from MiniportQueryInformation(). Although I feel I am in good company, I still don’t know how to recover my sanity.

As I think back (through the fog) I recall that the meaning of these two return values was something like the following:

NDIS_STATUS_INVALID_LENGTH - the buffer you gave me is the wrong size. I have written nothing or read nothing from it. The request is unprocessed. I am giving you back the expected size so that you can try again, perhaps getting it right the next time. Good Luck.

NDIS_STATUS_BUFFER_TOO_SHORT - the buffer you gave me is too short. I may or may not have written or read a partial result from it. Check the *BytesRead/*BytesWritten return if you care. In any event, I have returned the length of the buffer that would allow the entire result to fit in *BytesRequired. If you wish to try again, perhaps you could send me a buffer of at least that size next time.

So let’s say that a protocol queries OID_802_3_CURRENT_ADDRESS and supplies a request buffer with length less than ETH_ADDRESS_LEN (that is 6 for you marketing types who read this list trying to play along .) , I would expect NDIS_STATUS_INVALID_LENGTH but I cannot say that NDIS_STATUS_BUFFER_TOO_SHORT is wrong.

However, for an OID_802_11_BSSID_LIST query that has at least the required number of bytes to hold the header of the result, I would expect that if all the BSSID entries did not fit in the supplied buffer, that the result could plausibly be NDIS_STATUS_BUFFER_TOO_SHORT and maybe (depending on the Miniport) the buffer would get a partial list. This could, of course, be fantasy and I have no intentions of testing it. I use it as an illustration of what I once thought the difference between the two status codes were.

Now the real question, of course, is what is NDIS expecting, what is WHQL and NDISTest expecting, and just what is going to get me back to a restful sleep tonight (Bookers, Bakers or Basil Haden perhaps)?

So if any of you can help me out here with a definitive clarification, I greatly appreciate it. If it turns out that (as I have been apparently treating it for 15+ years) that it does not matter, well, that is great too.

Cheers,

-dave

—
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

Actually, for BSSID lists I start with a 64KB buffer. If that fails, I
double it to 128KB.

I’d be interested to know if you have seen a BSSID list that takes more than
64KB.

Thomas

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Friday, June 27, 2008 8:31 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS_STATUS_BUFFER_TOO_SHORT vs.
NDIS_STATUS_INVALID_LENGTH - I have lost my mind (did you find it?)

Thomas, you don’t really mean to completely ignore the BytesNeed, do you?

Consider for example that in first call you give 512 bytes, and miniport

returns BytesNeed = 4KB.

Then, if you just double the size, it will take you 3 more attempts at
least.

Maybe, the following recipe can be recommended for reading
OID_802_11_BSSID_LIST

and similar data:

  • Start with a large buffer.

The RAM is cheap; speed matters.Try to get the data from the first attempt.

  • Use BytesNeeded, if it looks reasonable

(greater than the input size, and not TOO large: OID_802_3_CURRENT_ADDRESS

can’t require 10 MBytes, neither OID_802_11_BSSID_LIST )

Add some extra, in case the data can grew up since the previous call:

at least, one max. size of the data item (not just 512 bytes, like WZC
does).

  • When using partial input, check it well. The last item can be truncated.

In case the total size or number of items is returned in the data header, it
may be

wrong (contain also the items that don’t fit).

Best regards,

–PA

“Thomas F. Divine” wrote in message
news:xxxxx@ntdev…

Probably if you are generating error messages, then you should follow the
matching WDK/DDK advice. It seems that NDIS_STATUS_INVALID_LENGTH is
acceptable on all platforms.

If you are interpreting NDIS status codes, then treat both
NDIS_STATUS_INVALID_LENGTH and NDIS_STATUS_BUFFER_TOO_SHORT then same.
Personally, I treat both as if the buffer was too short, but. I also ignore
the “bytes needed” and just double the size of the query buffer. I do that
because in at least some cases bytes needed may be misleading. For example,
when querying a BSSID list the more BSSID items could (conceivably) be added
to the list since the previous query. So, even if you used bytes needed as
intended, the newt query could (conceivably) still come up short.

Alternative ideas is that the W2K3 documentation actually describes the
behavior of NDIS 5 miniports and the newer WDK documentation describes the
behavior of NDIS 6 miniports. Of course, on Vista you have both NDIS 5 and
NDIS 6 miniports. So, if you pre-fetched the miniport driver version you
could (waste of time IMHO.) perform NDIS version-dependent interpretation of
these two return values.

I think I found your mind. It was on an old DDK CD.

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, June 27, 2008 10:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS_STATUS_BUFFER_TOO_SHORT vs. NDIS_STATUS_INVALID_LENGTH
- I have lost my mind (did you find it?)

Ever have one of those nights when you lay awake and slowly convince
yourself that you no longer know anything? Well, lately, it has not taken
very much effort …

To wit:

The WDK Docs state quite clearly that for calls to
MiniportQueryInformation() if the supplied buffer length does not match the
required buffer length, the function should return
NDIS_STATUS_INVALID_LENGTH and place the required buffer length in
*BytesNeeded. Strangely, the older W2K3 DDK docs say that either
NDIS_STATUS_INVALID_LENGTH or NDIS_STATUS_BUFFER_TOO_SHORT are returned in
this case. I am not sure I understand the change in docs other than
perhaps the WDK team gets charged by the letter by MSDN to host the
documentation.

Well, for as long as I can remember (oh, lately, about 45 seconds or so),
MiniportQueryInformation() would typically return
NDIS_STATUS_BUFFER_TOO_SHORT in cases where the buffer was too small.

A quick survey of WDK samples shows that both the left and right hands at
MSFT are also just as tied in knots as my weak brain at this point since in
some samples you have one and other samples the other being returned from
MiniportQueryInformation(). Although I feel I am in good company, I still
don’t know how to recover my sanity.

As I think back (through the fog) I recall that the meaning of these two
return values was something like the following:

NDIS_STATUS_INVALID_LENGTH - the buffer you gave me is the wrong size. I
have written nothing or read nothing from it. The request is unprocessed.
I am giving you back the expected size so that you can try again, perhaps
getting it right the next time. Good Luck.

NDIS_STATUS_BUFFER_TOO_SHORT - the buffer you gave me is too short. I may
or may not have written or read a partial result from it. Check the
*BytesRead/*BytesWritten return if you care. In any event, I have returned
the length of the buffer that would allow the entire result to fit in
*BytesRequired. If you wish to try again, perhaps you could send me a
buffer of at least that size next time.

So let’s say that a protocol queries OID_802_3_CURRENT_ADDRESS and supplies
a request buffer with length less than ETH_ADDRESS_LEN (that is 6 for you
marketing types who read this list trying to play along .) , I would expect
NDIS_STATUS_INVALID_LENGTH but I cannot say that
NDIS_STATUS_BUFFER_TOO_SHORT is wrong.

However, for an OID_802_11_BSSID_LIST query that has at least the required
number of bytes to hold the header of the result, I would expect that if all
the BSSID entries did not fit in the supplied buffer, that the result could
plausibly be NDIS_STATUS_BUFFER_TOO_SHORT and maybe (depending on the
Miniport) the buffer would get a partial list. This could, of course, be
fantasy and I have no intentions of testing it. I use it as an illustration
of what I once thought the difference between the two status codes were.

Now the real question, of course, is what is NDIS expecting, what is WHQL
and NDISTest expecting, and just what is going to get me back to a restful
sleep tonight (Bookers, Bakers or Basil Haden perhaps)?

So if any of you can help me out here with a definitive clarification, I
greatly appreciate it. If it turns out that (as I have been apparently
treating it for 15+ years) that it does not matter, well, that is great too.

Cheers,

-dave

—
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

—
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

6

“Thomas F. Divine” wrote in message
news:xxxxx@ntdev…
> Actually, for BSSID lists I start with a 64KB buffer. If that fails, I
> double it to 128KB.
>
> I’d be interested to know if you have seen a BSSID list that takes more
> than 64KB.
>
> Thomas

Ok, let’s see…
A BSSID element represents a 802.11 beacon.
The max. size of a beacon is ~ 2.5 KB. It has a fixed header ~ 16 bytes,
all the rest can be filled by so called information elements.
Typical beacons seen at wild these days are under 200 bytes.

The max. number of stations I’ve seen in the lab was ~ 60,
and the max. buffer size needed was 12K.

The max. number of stored beacons depends on the driver; some
drivers use max. number of beacons and some - max. amount of
memory. If this limit is hit, oldest entries are replaced.

Now, when people more actively use wi-fi on Linux (duh!)
we must expect them to go wild with the information
elements. So, same number of stations and max. size of beacon
would give 2500*60=146KB (still a reasonable size).
With 64KB, you can get ~ 26 max.sized beacons.

Regards,
–PA

7

Thanks, PA.

What I see mostly here is that DOT11_BSS_ENTRY size is less than 256 bytes
(typically less than 136 bytes) and that NDIS_WLAN_BSSID is fixed at 104
bytes.

I will re-think my strategy based on your thoughts. Apparently it would work
OK in my local airport terminal (Atlanta, Georgia, USA) as long as all the
notebooks were running Windows, but would fall over if all were running
Linux.

Warmest regards,

Thomas

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-328499-
xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Friday, June 27, 2008 9:45 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS_STATUS_BUFFER_TOO_SHORT vs.
NDIS_STATUS_INVALID_LENGTH - I have lost my mind (did you find it?)

“Thomas F. Divine” wrote in message
> news:xxxxx@ntdev…
> > Actually, for BSSID lists I start with a 64KB buffer. If that fails,
> I
> > double it to 128KB.
> >
> > I’d be interested to know if you have seen a BSSID list that takes
> more
> > than 64KB.
> >
> > Thomas
>
> Ok, let’s see…
> A BSSID element represents a 802.11 beacon.
> The max. size of a beacon is ~ 2.5 KB. It has a fixed header ~ 16
> bytes,
> all the rest can be filled by so called information elements.
> Typical beacons seen at wild these days are under 200 bytes.
>
> The max. number of stations I’ve seen in the lab was ~ 60,
> and the max. buffer size needed was 12K.
>
> The max. number of stored beacons depends on the driver; some
> drivers use max. number of beacons and some - max. amount of
> memory. If this limit is hit, oldest entries are replaced.
>
> Now, when people more actively use wi-fi on Linux (duh!)
> we must expect them to go wild with the information
> elements. So, same number of stations and max. size of beacon
> would give 2500*60=146KB (still a reasonable size).
> With 64KB, you can get ~ 26 max.sized beacons.
>
> Regards,
> --PA
>
>
> —
> 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

8

“Thomas F. Divine” wrote in message
news:xxxxx@ntdev…

> What I see mostly here is that DOT11_BSS_ENTRY size is less than 256 bytes
> (typically less than 136 bytes) and that NDIS_WLAN_BSSID is fixed at 104
> bytes.

NDIS_WLAN_BSSID is an older struct that does not contain information
elements.
The new docum even does not mention it, in favor of NDIS_WLAN_BSSID_EX
which is variable size.

OID_802_11_BSSID_LIST can hold both types of entries.
If the Length member == sizeof(NDIS_WLAN_BSSID), it is NDIS_WLAN_BSSID,
otherwise it’s NDIS_WLAN_BSSID_EX.

(ndis.h defines OID_802_11_BSSID_LIST and OID_802_11_BSSID_LIST_EX,
but they are exactly same)

Now, some open source wi-fi drivers have API that allows to transmit
arbitrary
information elements - which enables a lot of interesting ideas…
Undocumented OID_DOT11_UPDATE_IE seems to do same to Vista :slight_smile:

Regards,
–PA

9

Thanks Thomas.

I do indeed take the approach in Protocol edge code of treating the two
values as acceptable. This was more a question of ‘correctness’ in the
Miniport implementation. And likewise, I try to ensure that the output
value of the *BytesRequired is setup to be sensible.

I guess I was looking more for text-book answer more than a practical one.
I too code to the practical interpretation at the Protocol edge but since a
Miniport can only return a single value, I have to pick. I can only hope
that everyone else has chosen to accept either value as essentially
equivalent at the Protocol edge but I find that hardly likely to be assured.

I like the idea of choosing NDIS_STATUS_INVALID_LENGTH as the ‘CYA’ value
since as you point out, both DOC-Sets indicate it as acceptable (and so one
could, presumably, argue with WHQL if they ever balked).

But *somebody* once had a reason for the two status return codes and
perhaps that distinction is lost to history and imprecise usage. Maybe I
should go look in the NE2000 MAC driver in the NT 3.1 DDK J

Cheers,

-dave

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Friday, June 27, 2008 1:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS_STATUS_BUFFER_TOO_SHORT vs.
NDIS_STATUS_INVALID_LENGTH - I have lost my mind (did you find it?)

Probably if you are generating error messages, then you should follow the
matching WDK/DDK advice. It seems that NDIS_STATUS_INVALID_LENGTH is
acceptable on all platforms.

If you are interpreting NDIS status codes, then treat both
NDIS_STATUS_INVALID_LENGTH and NDIS_STATUS_BUFFER_TOO_SHORT then same.
Personally, I treat both as if the buffer was too short, but. I also ignore
the “bytes needed” and just double the size of the query buffer. I do that
because in at least some cases bytes needed may be misleading. For example,
when querying a BSSID list the more BSSID items could (conceivably) be added
to the list since the previous query. So, even if you used bytes needed as
intended, the newt query could (conceivably) still come up short.

Alternative ideas is that the W2K3 documentation actually describes the
behavior of NDIS 5 miniports and the newer WDK documentation describes the
behavior of NDIS 6 miniports. Of course, on Vista you have both NDIS 5 and
NDIS 6 miniports. So, if you pre-fetched the miniport driver version you
could (waste of time IMHO.) perform NDIS version-dependent interpretation of
these two return values.

I think I found your mind. It was on an old DDK CD.

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, June 27, 2008 10:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS_STATUS_BUFFER_TOO_SHORT vs. NDIS_STATUS_INVALID_LENGTH

  • I have lost my mind (did you find it?)

Ever have one of those nights when you lay awake and slowly convince
yourself that you no longer know anything? Well, lately, it has not taken
very much effort …

To wit:

The WDK Docs state quite clearly that for calls to
MiniportQueryInformation() if the supplied buffer length does not match the
required buffer length, the function should return
NDIS_STATUS_INVALID_LENGTH and place the required buffer length in
*BytesNeeded. Strangely, the older W2K3 DDK docs say that either
NDIS_STATUS_INVALID_LENGTH or NDIS_STATUS_BUFFER_TOO_SHORT are returned in
this case. I am not sure I understand the change in docs other than
perhaps the WDK team gets charged by the letter by MSDN to host the
documentation.

Well, for as long as I can remember (oh, lately, about 45 seconds or so),
MiniportQueryInformation() would typically return
NDIS_STATUS_BUFFER_TOO_SHORT in cases where the buffer was too small.

A quick survey of WDK samples shows that both the left and right hands at
MSFT are also just as tied in knots as my weak brain at this point since in
some samples you have one and other samples the other being returned from
MiniportQueryInformation(). Although I feel I am in good company, I still
don’t know how to recover my sanity.

As I think back (through the fog) I recall that the meaning of these two
return values was something like the following:

NDIS_STATUS_INVALID_LENGTH - the buffer you gave me is the wrong size. I
have written nothing or read nothing from it. The request is unprocessed.
I am giving you back the expected size so that you can try again, perhaps
getting it right the next time. Good Luck.

NDIS_STATUS_BUFFER_TOO_SHORT - the buffer you gave me is too short. I may
or may not have written or read a partial result from it. Check the
*BytesRead/*BytesWritten return if you care. In any event, I have returned
the length of the buffer that would allow the entire result to fit in
*BytesRequired. If you wish to try again, perhaps you could send me a
buffer of at least that size next time.

So let’s say that a protocol queries OID_802_3_CURRENT_ADDRESS and supplies
a request buffer with length less than ETH_ADDRESS_LEN (that is 6 for you
marketing types who read this list trying to play along .) , I would expect
NDIS_STATUS_INVALID_LENGTH but I cannot say that
NDIS_STATUS_BUFFER_TOO_SHORT is wrong.

However, for an OID_802_11_BSSID_LIST query that has *at least* the required
number of bytes to hold the header of the result, I would expect that if all
the BSSID entries did not fit in the supplied buffer, that the result could
plausibly be NDIS_STATUS_BUFFER_TOO_SHORT and maybe (depending on the
Miniport) the buffer would get a partial list. This could, of course, be
fantasy and I have no intentions of testing it. I use it as an illustration
of what I once thought the difference between the two status codes were.

Now the real question, of course, is what is NDIS expecting, what is WHQL
and NDISTest expecting, and just what is going to get me back to a restful
sleep tonight (Bookers, Bakers or Basil Haden perhaps)?

So if any of you can help me out here with a definitive clarification, I
greatly appreciate it. If it turns out that (as I have been apparently
treating it for 15+ years) that it does not matter, well, that is great too.

Cheers,

-dave

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

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