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.

NDK on DM643x Compliance Testing gives FCS error

Hi,

Our customer is using Network Developers Kit (NDK 2.0) with DM643x.
The protocol compliance test fails with FCS error (ARP packet 4 byte).

But we are able to solve this error by changing the packet size of EmacSend() in nimu_eth.c file.

As shown below by default it is set as 64 and the error gets solved if we change it to 60.

Code from nimu_eth.c file.
/* 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 );

We would like to know if it is ok if we change the size from 64 to 60.
What could the reason to set the size as 64.

Please let me know if there is any advice on this topic.

Regards.
Prad.

  • any comments on this issue?

  • Could anyone please let me know about the Ethernet packet length settings
    in the NDK driver above.

    The EmacSend() function in "nimu_eth.c" file sets the valid length
    of the packet as shown below.

    /* 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 );

    As you know the ethernet standard the minimum packet lenght is "64"
    why is this if condition checking for packets <60 why not 64?
    And does this include the FCS 4 bytes also?

    We are getting FCS error only with the DM643x with NDK driver but no problems
    with other general Ethernet device.

  • Please let me know if there are any comments on this topic?

  • Hi Prad1,

    I'm not the author of that driver but I'll try to help.

    Prad1 said:
    why is this if condition checking for packets <60 why not 64?

    I would guess that the driver is checking for a valid length of 60 because it's only counting the frame as:

        [Destination Addr (6 bytes)] [Source Addr (6 bytes)] [Type (2 bytes)] [Data (46 - 1500 bytes)]

    (NOT counting the 4 byte frame check)

    This will yield a minimum size of 6 + 6 + 2 + 46 = 60 bytes.

    The value of 64 is most likely including the frame check:

    [Destination Addr (6 bytes)] [Source Addr (6 bytes)] [Type (2 bytes)] [Data (46 - 1500 bytes)] [Frame Check (4bytes)]

    Which of course yields a minimum value of 64 bytes.

    I think the EMAC h/w can be configured to include the 4 byte frame check.  Can you see what the setting is for the DM643x you are using?

    Prad1 said:
    We would like to know if it is ok if we change the size from 64 to 60.

    You are certainly free to try this and rebuild the driver code.  I would be interested to see what happens.  Also, is that if statement ever true for you?

    Steve

  • Hi Steve

    Thank you so much for answering this question.

    I have checked about the "PASSCRC" flag, as we haven't changed anything from the default driver,
    there is no code setting the "PASSCRC" flag, which means the flag is "clear" i.e the EMAC generates CRC.

    Regarding the below "if loop" from nimu_eth.c file in NDK 2.0 driver.

    If we change the "setValidLen" to 60, there won't be any FCS error,
    but FCS error occurs only if we leave it as 64.

    if( PBM_getValidLen(hPkt) < 60 )
    PBM_setValidLen (hPkt, 64 );

    So, according to my understanding "PBM_setValidLen" should be set to "60" if the CRC
    is generated by the EMAC hardware. We don't know if this guessing is valid or not..

    Note: Even if we get the FCS error, there is no problem with the communication so
             we believe this may be a false alarm by the Wireshark.

    Regards
    Prad

  • Prad1 said:
    Note: Even if we get the FCS error, there is no problem with the communication so
             we believe this may be a false alarm by the Wireshark.

    I think this was the same conclusion from the other thread.  Based on the FAQ on the Wireshark wiki, if the frames truly had a CRC error, you shouldn't even see them since the NIC would drop them.

    Are you seeing the CRC value is always zero?

    Another guess I have is that it could be that making the length 4 bytes longer is just causing the frame to be 4 bytes longer (the extra 4 bytes just being bogus) and Wireshark is reading it to be the CRC (and it's really just some bogus data)

    Steve

  • Hi Steve

    Thank you..

    We are not getting CRC value as zero.
    We are getting the error like..
    "Frame check sequence: 0x4a495453 [incorrect, should be 0xd7636502]"

    But as mentioned, we are able to solve this error by changing the below
    code for 60.

    if( PBM_getValidLen(hPkt) < 60 )
    PBM_setValidLen (hPkt, 60 );

    So with this change there is no error, but just wanted to confirm
    if this is OK with respect to NDK Driver...
    As for as the application is concerned it is working properly with the above settings.

    Regards
    Prad

  • Hi Steve,

    Just one final confirmation about this issue.
    We need to finalize this issue by tomorrow.

    We believe there are two options for this issue.

    1. Change the frame size to 60 in the function "PBM_setValidLen (hPkt, 60 )"
    which is working for us.

    2. Keep the frame size to default(64 bytes) and ignore the Wireshark error
    because it may be a false error.

    Just in case I asked the same question to the Wireshark community here but the conclusion
    seems to be no problem in the Wireshark but from the Ethernet driver adding
    the extra 4 bytes of padding.

    Please let me know what could be your guessing,
    should we use the setting default frame size(setValidLen=64 bytes) as per the NDK driver?

    Best Regards,
    Prad

  • Hi Prad,

    I also posted to that Wireshark forum/thread, let's see what the people on there have to say.

    Prad1 said:
    1. Change the frame size to 60 in the function "PBM_setValidLen (hPkt, 60 )"
    which is working for us.

    This may be the correct choice.  But, I'm curious what Wireshark shows for padding and FCS in this case?  Since you have PASSCRC" flag "clear" and the EMAC should be generating the FCS, do you see the FCS in Wireshark in that case?

    Coming back to that Wireshark forum, it seems that some drivers add padding + the 4 byte FCS, whereas some drivers do not (at least in the example capture that another user posted in that thread).  It looks like your capture shows the same behavior (padding plus FCS added by one host but not the other).

    It seems that the padding + FCS are added only when the actual data is less than 64 bytes.  In the capture on that thread, the 2nd ping frame has only 43 bytes of valid data, but it shows 17 bytes of padding (which bring the size up to 60 bytes) followed by a 4 byte FCS were added, making it a total size of 64 bytes.

    It may be helpful for me to see your capture of both scenarios (for 1 and 2 above).  In particular, if there are any frames with"valid data" that's < 60 bytes, I would like to see if such frames have the padding/FCS present or not for each scenario.

    Steve

  • Hi Steve,

    Thank you.

    I have uploaded the capture files for both scenarios.

    1.No FCS Error when "setValidLen" is set to 60:
    http://www.cloudshark.org/captures/354f6c39af1f

    2. FCS Error when "setValidLen" is set to 64:
    http://www.cloudshark.org/captures/34912e36b8a6

    In case of 1.(Frame size set to 60), it seems there is no extra 4 bytes of FCS
    and hence no FCS error.

    Just in case I would like to mention one more contradiction
    about the below code from NDK.

    if( PBM_getValidLen(hPkt) < 60 )
    PBM_setValidLen (hPkt, 64 );

    According to our assumption 60 bytes in this expression doesn't include FCS and
    64 bytes include FCS.

    But what if the packet size is in between 60 and 64(say 61)
    in that case this code goes uneffective and the FCS is not added for packets
    with size between 60 to 64.

    Best Regards.
    Prad

  • Prad,

    I think cmaynard's response on that Wireshark forum is very informative.

    I now believe that setting the valid length to 60 is the correct option if the EMAC is configured to generate the FCS.  I think the "if( PBM_getValidLen(hPkt) < 60 )" is checking that the data is meeiting its minimum requirement.

    He also confirmed a suspicion that I have already had that if the FCS was truly bad, then the frame would be dropped by the EMAC h/w and hence it would not even show up in Wireshark.

    So, to recap what I take from all of this - in your case for a packet with data < 60 bytes, the size must be set to 60 in order to provide padding so that the frame meets the 60 byte minimum (data) size.  Since the h/w will append the FCS to the end when the packet goes out, you shouldn't need to worry about it.  And the frame will indeed meet the minimum *frame* size of 64 bytes, once it appends the 4 byte FCS.

    On the other hand, if the h/w were configured NOT to generate the FCS for you, then the driver would need to still pad the data up to 60 bytes, but then calculate and append the 4byte FCS itself and then append that to the frame (since the h/w would not be doing it).  In this case, I think the valid size would then need to be set to 64 (to account for the 4 byte FCS).  After doing this, the frame would then also meet the minimum (frame) size requirement of 64 bytes.

    Does this make sense?

    Steve

  • Hi Steve,

    Thank you so much for your time to find the solution on this topic.

    With all your findings and information we believe "setValidLen=60" is the solution.
    We shall continue with our Compliance Test with this settings.

    Best Regards
    Prad.

  • I also stumbled over this problem, and luckily over this post.

    1. There is an error in wireshark or more detailled in the capturing part for windows. This is not forwarding the FCS. Wireshark itself can only guess if its getting the FCS or not. (Manually disable FCS check in wireshark).

    2. There is a bug with the length check as recognized by Prad1.
    Any good programmer shall feel uncomfortable with lines like:
    if (x < 60) x = 64;
    Where the hell are those 4 bytes coming from?
    So actually it should be x = 60.

    Conclusions:
    The FCS is appended implicitly!
    1. When payload is less than 60 bytes, the ethernet package has a final length of 68 bytes. x = 64 + 4 bytes FCS.
    So 4 bytes too much!!!
    2. Between 60 and 64 the FCS is appended and the package has the minimum length. -> OK.

    @TI Please fix this problem. Because for small payloads 68 bytes instead of 64 bytes are sent.