Hello Experts,
We have a strange problem. When we get the raw packet data from an NDIS packet with NDISGetFirstBufferFromPacket, NDISQueryBufferSafe and NDISGetNextBuffer we get a packet size (NDISQueryPacket - TotalPacketLength) that sometimes differs from the length defined in the IP header. Is it normal or not? And could it cause any problem?
Thank you in advance!
NDIS packets have no notion of IP or any other protocol. They understand only network packets, and all higher-level protocol details are treated just as a payload by them. Taking into consideration the fact that IP packets may get fragmented by the data link layer on their way across the network, this behavior is absolutely normal - it is protocol’s responsibility to take care of these issues…
Anton Bassov
Thank you for the quick and detailed answer!
The size of the packet reported by NDIS is the total size of the memory buffers described by the buffer chain attached to the packet. The ‘logical’ packet length can be shorter than this length on Ethernet because it requires a minimum packet length for proper collision detection.
Ethernet (DIX) packets do not have a length field but the IP header does. If the IP header indicates that 20 octets are present in the packet beyond the Ethernet header and NDIS says the packet buffer chain is 40 octets long, you should assume that anything beyond the (14 octets of Ethernet Header) + (20 Octets of IP packet) is just ‘junk’ (padding).
If the IP header indicates that 820 octets is the size of the IP packet yet NDIS indicates that the total buffer size (packet size) is only 200 octets, then, the packet is malformed since the apparent size of the IP packet exceeds the available buffer size.
IEEE 802.3 (and 802.5, etc.) defines a length field indicating the number of octets in the MAC frame. It is unlikely on a Windows system that you would see an 802.3 framed IP packet in a SNAP header but for completeness you should realize that if the 802.3 MAC header says the packet is ‘n’ octets in length but some value < ‘n’ is reported by NDIS as the buffer (packet) length, then the packet should be discarded as invalid.
As for IP ‘fragments’ keep in mind that yeah, sure, IP can fragment a packet but an IP datagram ‘length’ is the sum of the lengths of its fragments. The IP header carries the length of the ‘fragment’ not the length of the reassembled datagram. The previous comment about fragments is FUD.
IP datagrams do not get fragmented by the datalink (MAC) layer. IP datagrams are only fragmented by IP at either the sender or an intervening router. Any IP packet ‘on a datalink’ by definition must fit in the constraints of the datalink itself. It is impossible to receive a valid IP packet ‘larger’ than the MTU of the datalink. The IP header carries an ‘offset’ field to describe where in the larger (reassembled) IP datagram that a fragment portion shall be positioned during reassembly. It is the ‘offset’ and ‘length’ fields together that describe the fragment.
Unless your driver is interested in reassembling the entire IP datagram, you can safely ignore (by design) whether or not a particular IP packet represents a complete IP datagram or a fragment of such.
The IP header length field *directly* describes in all cases the size of the IP payload in *that* packet.
So, in reference to your original question - sure, it is ‘normal’ in that it is something your driver must consider. If the IP packet fits in the buffer then all is well. If it does not, then, ignore the packet as malformed.
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@freemail.hu
Sent: Friday, February 08, 2008 3:52 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS reassembled packet size problem
Hello Experts,
We have a strange problem. When we get the raw packet data from an NDIS packet with NDISGetFirstBufferFromPacket, NDISQueryBufferSafe and NDISGetNextBuffer we get a packet size (NDISQueryPacket - TotalPacketLength) that sometimes differs from the length defined in the IP header. Is it normal or not? And could it cause any problem?
Thank you in advance!
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
> The previous comment about fragments is FUD. IP datagrams do not get
fragmented by the datalink (MAC) layer. IP datagrams are only fragmented by IP
at either the sender or an intervening router.
What if the packet is unable to fit into *actual* MTU??? Please note that, once miniport may be virtual, the IP, as well as any other bound protocol, has no clue about either the *actual* MTU size or about *actual* underlying physical media - the only info it gets is the one that underlying miniport driver provides. In such case it is virtual miniport’s driver responsibility to fragment the packet - it will break it into separate parts and pre-pend an IP header to each fragment, possibly padding the last physical packet with junk. Therefore, packet size in the IP header of the last packet may be smaller than MTU size because of fragmentation that is done by MAC layer…
Anton Bassov
And this is relevant to the receiver of such a packet how? Does the packet received somehow violate what I said - that a receiver cannot receive a *valid* IP packet larger than the datalink MTU?
More FUD.
The datalink(s) on either side of this virtual miniport element you propose to inject into this discussion are therefore *different* datalinks and thus have *different* MTUs and thus this virtual miniport you have injected is thus acting as router (because it is fragmenting packets) and if it is written correctly will be completely indistinguishable and undetectable by the receiver of the packet.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, February 08, 2008 10:23 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS reassembled packet size problem
The previous comment about fragments is FUD. IP datagrams do not get
fragmented by the datalink (MAC) layer. IP datagrams are only fragmented by IP
at either the sender or an intervening router.
What if the packet is unable to fit into *actual* MTU??? Please note that, once miniport may be virtual, the IP, as well as any other bound protocol, has no clue about either the *actual* MTU size or about *actual* underlying physical media - the only info it gets is the one that underlying miniport driver provides. In such case it is virtual miniport’s driver responsibility to fragment the packet - it will break it into separate parts and pre-pend an IP header to each fragment, possibly padding the last physical packet with junk. Therefore, packet size in the IP header of the last packet may be smaller than MTU size because of fragmentation that is done by MAC layer…
Anton Bassov
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
Anton, you disappointed me. I was expecting you to inject TCP offload into the discussion in combination with local loopback and that a poor hapless protocol or IM driver might see a really big IP packet that *seems* to violate the interface MRU constraint. But really, the OP seems possibly to be new to NDIS and maybe even IP and so do we really need to throw every bit of NDIS esoteria out just to sound like we somehow know what we are doing (which I reasonably assume on any given Friday I, at least, do not).
FUD.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, February 08, 2008 10:23 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS reassembled packet size problem
The previous comment about fragments is FUD. IP datagrams do not get
fragmented by the datalink (MAC) layer. IP datagrams are only fragmented by IP
at either the sender or an intervening router.
What if the packet is unable to fit into *actual* MTU??? Please note that, once miniport may be virtual, the IP, as well as any other bound protocol, has no clue about either the *actual* MTU size or about *actual* underlying physical media - the only info it gets is the one that underlying miniport driver provides. In such case it is virtual miniport’s driver responsibility to fragment the packet - it will break it into separate parts and pre-pend an IP header to each fragment, possibly padding the last physical packet with junk. Therefore, packet size in the IP header of the last packet may be smaller than MTU size because of fragmentation that is done by MAC layer…
Anton Bassov
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
> And this is relevant to the receiver of such a packet how?
Not at the protocol layer. However, if by “receiver” you mean the OP’s driver (which, apparently, is NDIS IM filter), then it does - a receiver may see that IP packet is smaller than physical network one, because of the padding applied. The reverse is not true - as you have already pointed out, if the OP sees the reverse scenario, then the target packet is just malformed…
Does the packet received somehow violate what I said - that a receiver
cannot receive a *valid* IP packet larger than the datalink MTU?
Not at all. The only thing I am saying is that IP packet length may be different from the one of
physical network packet, and this difference is due to fragmentation/manipulation that is done at the level that, from the protocol’s perspective, is datalink layer. The only thing I argue about is your statement that packets cannot get fragmented at datalink layer…
the OP seems possibly to be new to NDIS and maybe even IP and so do we really
need to throw every bit of NDIS esoteria out just to sound like we somehow know
what we are doing
Well, on this particular occasion the OP seems to be a curious character who just wants to understand what actually happens (which is not so common these days - normally posters tend
to say “my driver don’t work… it has to be ready by next Monday… please help…”). Therefore, I think that, on this particular occasion, we can throw some “gory details” into our discussion…
Anton Bassov
I think that IP relies on NDIS or similar layer in packet lengths, and the
only length in the header is related to reassembly. Am I wrong?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hello Experts,
> We have a strange problem. When we get the raw packet data from an NDIS
packet with NDISGetFirstBufferFromPacket, NDISQueryBufferSafe and
NDISGetNextBuffer we get a packet size (NDISQueryPacket - TotalPacketLength)
that sometimes differs from the length defined in the IP header. Is it normal
or not? And could it cause any problem?
> Thank you in advance!
>
>
> I think that IP relies on NDIS or similar layer in packet lengths,
and the only length in the header is related to reassembly. Am I wrong?
Well, I think all you have to do in order to decide whether your statement is right or wrong is to read Dave’s first post on this thread - as he pointed out already, the field ‘Length’ is not related to fragmentation (there is ‘Offset’ one that indicates the fragment’s position in a packet). If packet is fragmented, this field indicates the size of a particular fragment, rather than that of the whole packet. Taking into consideration that IP is meant to be independent from underlying media by its very definition, making IP rely upon lower levels in determining packet size would be quite unwise idea…
Anton Bassov