Packet handed to ProtocolReceive is wrong size

I have been testing with a Trendnet USB to 10/100Mbps Adapter. This adapter passes data to the ProtocolReceive function of my NDIS driver. It always passes the entire packet but it cannot be obtained by NdisGetReceivedPacket. What I have noticed is that I frequently get wrong values for the header, lookahead and packetsize. What I mean is I will received a 54 byte TCP packet as verified by Wireshark but this adapter will tell me it is 60 bytes. As such, I have had to add code to check the IP packet sizes against the sizes passed in and act accordingly.

My question - Is this type of behavior seen a lot from various adapters?

Thanks – Michael

There are a couple of issues here:

1.) NEVER assume that NdisGetReceivedPacket will actually fetch a packet.
ALWAYS have code that can accommodate the case where NdisGetReceivedPacket
returns NULL.

2.) Check to see if the offending packet is a LOOPBACK packet. Loopback
packets are looped back by software in the NDIS wrapper. For runt packets
the loopback packet will have the original non-padded length. On the wire
the adapter hardware will add padding to the minimum required packet size.
So, the loopback packet (seen by Wireshark on the local host) may very well
have length different from what is actually sent on the wire.

Good luck,

Thomas F Divine
http://www.pcausa.com


From:
Sent: Friday, February 05, 2010 4:47 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Packet handed to ProtocolReceive is wrong size

> I have been testing with a Trendnet USB to 10/100Mbps Adapter. This
> adapter passes data to the ProtocolReceive function of my NDIS driver. It
> always passes the entire packet but it cannot be obtained by
> NdisGetReceivedPacket. What I have noticed is that I frequently get wrong
> values for the header, lookahead and packetsize. What I mean is I will
> received a 54 byte TCP packet as verified by Wireshark but this adapter
> will tell me it is 60 bytes. As such, I have had to add code to check the
> IP packet sizes against the sizes passed in and act accordingly.
>
> My question - Is this type of behavior seen a lot from various adapters?
>
> Thanks – Michael
>
>
> —
> 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

Thomas,
I have all the ways ProtocolReceive can be called covered. I have verified that the packet is not a loopback packet. It is a TCP/IP packet from another device. I was wanting to know if this sort of thing is seen often.

I don’t’ think this is seen “often”. In fact, I don’t recall ever seeing a
packet at ProtocolReceive that was too short (unless the source MAC was that
of the receiving adapter - i.e., loopback). In the distant past (ISA days on
a SMC adapter…) I saw some that reported sizes that were larger than the
actual data which is another can of worms.

Was LookaheadBufferSize < PacketSize? If so, then you must call
NdisTransferData to get the “residual” bytes.

(I suspect that you already check for this, so don’t be offended by the
question. Plus, it doesn’t make any sense that there are only 6 bytes
missing.).

Are you using the latest driver for the adapter?

Weird. Sorry I can’t help.

Thomas F Divine
http://www.rawether.net


From:
Sent: Friday, February 05, 2010 5:00 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Packet handed to ProtocolReceive is wrong size

> Thomas,
> I have all the ways ProtocolReceive can be called covered. I have
> verified that the packet is not a loopback packet. It is a TCP/IP packet
> from another device. I was wanting to know if this sort of thing is seen
> often.
>
> —
> 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 LookaheadBufferSize always equals PacketSize. So far, it has always told me there is more data than there actually is. So I have been able to adjust to the correct size using the IP length. (I am only looking for TCP packets, the rest are passed on).

Thanks for the feedback,
Michael

> The LookaheadBufferSize always equals PacketSize. So far, it has always told me there is more

data than there actually is. So I have been able to adjust to the correct size using the IP length.

I think that the base feature of IP is that the MAC layer can add any padding to the tail of the packet.

IpHeader->Length must be <= NDIS packet length, and you just ignore the padding.


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