This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Possible NDK 2.0 bug related to short packet processing (including ARP)

Hello,

Sorry if this is a repeat...

I discovered what appears to be a minor bug in the way NDK 2.0 handles short packets.  

This bug manifests itself on Wireshark with packets less than 60 bytes in size, like ARP packets, in the form of incorrect Ethernet Frame Check Sequence error appended to the packet display on Wireshark:

I've traced the issue to a bit of code in EmacSend() function, which is located in nimu_eth.c and is part of the device drivers.  I've seen the same issue in both 64x+ and 6657 drivers, though.

The bit of code in question is the check for packets that are less than 60 bytes:

/* Make sure the driver does not transmit packet less than min. as per the
* Ethernet standards. */
if( PBM_getValidLen(hPkt) < 60 )
PBM_setValidLen (hPkt, 64 );

Notice that if the packet is less than 60 bytes, it's length is set to 64.  This causes extra four bytes to be appended to the packet. These extra bytes then get interpreted as the FCS (which they are not).

The "fix" is to dial back 64 down to 60:

/* Make sure the driver does not transmit packet less than min. as per the
* Ethernet standards. */
if( PBM_getValidLen(hPkt) < 60 )
PBM_setValidLen (hPkt, 60 ); 

I tested this, and it appears to work. 

I noticed that there were a few other posts related to this on this forum.  I'd like to have the nice TI folk look at it to see if nothing else is broken by this "fix".

I initially ran into this problem with NDK 2.0.1, and now noticed that it traveled into the latest NDK.