NDIS 5.1 - NDIS_BUFFER length - is it always <= PAGE_SIZE?

Is an NDIS_BUFFER attached to an NDIS_PACKET in SendPackets always <=
PAGE_SIZE in length, at least for NDIS 5.1?

I’m reviewing my code, and I think that there is a bug that would cause
my driver to break if it ever received an NDIS_BUFFER with a length >
PAGE_SIZE… and so far it hasn’t broken. The conclusion I draw from
that is that no NDIS_BUFFER is > PAGE_SIZE in length…

Is my above conclusion:
. wrong, and I’m misinterpreting my code?
. right, but the behaviour is not guaranteed - it just happens to be
that way in NDIS 5.1?
. right, and the behaviour is documented somewhere and I just haven’t
found it.

Thanks

James

If the MTU is usually ~1500 bytes - then surely yes :slight_smile:


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

“James Harper” wrote in message news:xxxxx@ntdev…
Is an NDIS_BUFFER attached to an NDIS_PACKET in SendPackets always <=
PAGE_SIZE in length, at least for NDIS 5.1?

I’m reviewing my code, and I think that there is a bug that would cause
my driver to break if it ever received an NDIS_BUFFER with a length >
PAGE_SIZE… and so far it hasn’t broken. The conclusion I draw from
that is that no NDIS_BUFFER is > PAGE_SIZE in length…

Is my above conclusion:
. wrong, and I’m misinterpreting my code?
. right, but the behaviour is not guaranteed - it just happens to be
that way in NDIS 5.1?
. right, and the behaviour is documented somewhere and I just haven’t
found it.

Thanks

James

… but ‘no’ if TCP offload is enabled and doing a large send. In that
case, the packet you get could very large indeed.

I am going guess that your Virtual Miniport does not enable large send and
that it is reasonable to assume that a bound protocol will otherwise only
send you something less than the MTU.

You should, however, ‘enforce’ this by checking the packet length in the
MiniportSendXxx handlers and rejecting packets that are too big. That way
your ‘assumption’ is validated at ingress to your driver. If a protocol
requests a send you cannot handle, write an event log entry.

-Dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Sunday, January 25, 2009 6:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS 5.1 - NDIS_BUFFER length - is it always <=
PAGE_SIZE?

If the MTU is usually ~1500 bytes - then surely yes :slight_smile:


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

“James Harper” wrote in message
news:xxxxx@ntdev…
Is an NDIS_BUFFER attached to an NDIS_PACKET in SendPackets always <=
PAGE_SIZE in length, at least for NDIS 5.1?

I’m reviewing my code, and I think that there is a bug that would cause
my driver to break if it ever received an NDIS_BUFFER with a length >
PAGE_SIZE… and so far it hasn’t broken. The conclusion I draw from
that is that no NDIS_BUFFER is > PAGE_SIZE in length…

Is my above conclusion:
. wrong, and I’m misinterpreting my code?
. right, but the behaviour is not guaranteed - it just happens to be
that way in NDIS 5.1?
. right, and the behaviour is documented somewhere and I just haven’t
found it.

Thanks

James


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

A scenerio that might happen:

  1. you have NIC bridging enabled
  2. you have jumbo packets enabled (you support jumbo packets, right?)
  3. a packet is received, is indicated up, and is forwarded to the bridged
    NIC at dispatch_level

In the above case, you conceivable will receive a jumbo size packet in a
single (possibly physically contiguous) buffer. This buffer could span 4
pages (the beginning, 2 pages of middle, the rest).

Bridging is also one of the cases that requires per packet control over
checksum offload. If you receive a packet with a bad TCP checksum, you
should not fix that checksum before forwarding it.

Another scenario is some intermediate driver (by a third party) modifies a
copy of the packet, so it may all in a single segment because it was copied.

Because there are potentially filters from other vendors layered above you,
empirical testing of the base OS is a bad method to determine what might
happen.

Jan

Is an NDIS_BUFFER attached to an NDIS_PACKET in SendPackets
always <= PAGE_SIZE in length, at least for NDIS 5.1?

I’m reviewing my code, and I think that there is a bug that
would cause my driver to break if it ever received an
NDIS_BUFFER with a length > PAGE_SIZE… and so far it hasn’t
broken. The conclusion I draw from that is that no
NDIS_BUFFER is > PAGE_SIZE in length…

Is my above conclusion:
. wrong, and I’m misinterpreting my code?
. right, but the behaviour is not guaranteed - it just
happens to be that way in NDIS 5.1?
. right, and the behaviour is documented somewhere and I just
haven’t found it.

>

… but ‘no’ if TCP offload is enabled and doing a large send. In
that
case, the packet you get could very large indeed.

I am going guess that your Virtual Miniport does not enable large send
and
that it is reasonable to assume that a bound protocol will otherwise
only
send you something less than the MTU.

I am doing large send, but the packet appears to be broken up into
PAGE_SIZE’d NDIS_BUFFERS’s by NDIS anyway.

You should, however, ‘enforce’ this by checking the packet length in
the
MiniportSendXxx handlers and rejecting packets that are too big. That
way
your ‘assumption’ is validated at ingress to your driver. If a
protocol
requests a send you cannot handle, write an event log entry.

Actually, I think my question should have been ‘does an NDIS_BUFFER only
ever have one PFN’, which is what I think I’m seeing. Even a 2 byte NDIS
buffer could cross a page so large send wouldn’t need to be active for
this to occur.

The answer doesn’t really matter, I am moving to using sg lists where
the data is broken up into separate pages, so I’m rewriting that code
anyway, but I noticed that my old code made the (flawed?) assumption
that an NDIS_BUFFER couldn’t cross a page boundary.

Thanks

James