• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1045 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Linux: Possible bug in CPSW driver

M. Birk
Prodigy 20 points
Other Parts Discussed in Thread: AM3358

Tool/software: Linux

Dear TI staff,

it seems like a fix for the CPSW Linux driver from the end of last year introduced a regression which causes short Ethernet frames to be padded to 68B in total instead of the standard defined 64B.

We confirmed the behavior on the Beaglebone Black with an AM3358 processor by modifying the sent frame length incrementally and observing the traffic with Wireshark. We also compared with a few different USB-Ethernet-dongles which all showed the expected traffic. While for instance the ARP protocol does not seem to have a problem with additional padding in the payload, some industrial automation protocols seem to be strict in this regard.

Although we saw it on a Beaglebone Black, it seems to be a general driver problem which should affect everyone who uses CPSW in VLAN-unaware mode as the problem can be fixed for us by reverting this commit. My guess would be that the driver would have to track the configuration of the switch hardware to correctly pad the frame.

Are you aware of such a bug or should this maybe be avoided by using a different CPSW configuration?

Best Regards
M. Birk

  • 0
    TI__Mastermind 38720 points
    Hi,

    I will check into the issue you have brought up. Which TI SDK are you using? In your testing did were you able to reproduce this on the Beagle Bone Black using the prebuilt kernel of the TI SDK?

    Could you describe your application that you are doing? For example you mentioned the industrial protocols, are you running a particular one? Is the testing that are doing an application that you developed that is changing the packet sizes?

    Best Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    Prodigy 20 points

    Hi,

    sorry for the delay...

    Originally I discovered it with the latest beagleboard.org image but I was able to confirm it using the pre-built image of the ti-processor-sdk-linux-rt-am335x-evm-04.03.00.05 as well. After the first time boot it is enough to bring eth0 up with an IP and to ping a different IP in the subnet to see ARP requests with 64B+FCS on the ethernet cable. Short ping frames show the same issue.

    We're basically running a bridge for different industrial protocols like ProfiNet. We keep the frames as they are though. We also see the behavior for direct communication with any protocol using short frames. Locally we reset the padding in the CPSW driver to 60B and did not have any problems yet as we're not using VLAN tag removal.

    Best Regards,
    M. Birk

  • 0 in reply to M. Birk
    TI__Mastermind 38720 points
    Hi,

    I discussed the question you are raising with a member of the driver development group. Essentially the answer is that this is expected behavior. The SDK by default configured to work in VLAN aware mode, so we need to support this padding. At the moment we don't see how to detect and change the padding dynamically so the funtionality will have to stay as it is. If you choose you can revert the change locally and choose to disable VLAN aware mode and not to support VLANs at all.

    If possible can you point to the standards used by the industrial protocols that you are using to explain the strictness of packet size? We like to know which protocols these are and perhaps look for a solution.

    Best Regards,
    Schuyler