• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 300 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AM6442: Everything flows to another port with cut-through, Multicast cannot be received on the EVM,

AM6442: echo-request (ping) is erroneously forwarded to the other port

Hideaki Matsumoto
Genius 9160 points
Part Number: AM6442

Hi,

First of all, thank you for fixing the cut-through issue of CPSW3g on the following thread.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1325945/am6442-everything-flows-to-another-port-with-cut-through-multicast-cannot-be-received-on-the-evm/5069538#5069538

The customer was able to confirm below by registering all of L2 multicast address into MDB with the "bridge MDB add" command beforehand.

  • Forward between ports without CPU intervention
  • Receive Multicast

However, they found a new related issue with the bridge cut-through using eth0 and eth1 (CPSW3g) on TMDS64GPEVM.

Could you please check if you can reproduce it at your side as well ?

1)  Phenomenon

  • When an echo-request (ping) is sent from PC connected to eth0, it is erroneously forwarded to the other eth1. However, it sends an echo-reply (ping reply) back to the PC.
  • Example)
    • # ping -t 192.168.16.171
  • Unicast packets destined to itself (destined to br0) are received, but it is a problem because it also forwards them.
  • ICMP Capture display of Wireshark :    See "eth0_eth1_ping.png" in the attached file below. 
    The right image is capturing the eth0 port, and the left is  the eth1 port.

2)  Environment

        SDK :    SDK09_01_00_08

        Configuration script :    Please refer to “cut_through_eth0_eth1.sh” in the attached file.

 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/cut_5F00_through_5F00_eth0_5F00_eth1-.sh

Thanks and regards,

Hideaki

  • 0
    TI__Mastermind 27050 points

    What is the network topology and who has what IP address configured? From above it seems like there is a PC (Windows or Linux?, need networking configuration), and there is a AM64x configured as switch (need printout of networking configuration, for example what does ip a print out). What else is in the network and what is the IP address of those entities. 

  • 0 in reply to Pekka Varis
    TI__Mastermind 40130 points

    Hi,

    In addition to what Pekka is asking for please indicate which platform or platforms is collecting the Wireshark data.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    TI__Genius 9160 points

    Hi Schuyler, Pekka,

    Thank you for supporting this thread. I sent you some files via e-mail. Please check them and continue to support this thread.

    Thanks and regards,
    Hideaki 

  • 0 in reply to Hideaki Matsumoto
    TI__Mastermind 27050 points

    I’m guessing the left side of the screenshot is “Repeater1” and right side is “Repeater2” ? On the trace screenshot the frames are not ordered by time but grouped by the type of frame. This makes it hard to see what is going on. Also cannot see the MAC addresses used in the messages. Ping (ICMP echo) will be broadcast in the subnet until someone responds, does the trace continue to show the ICMP echos once the 192.168.16.171 starts to respond?

    This would be simple to look at if the source .pcap files could be shared instead of a truncated screenshot.

  • 0 in reply to Pekka Varis
    TI__Genius 9160 points

    Hi Pekka,

    Pekka Varis said:
    I’m guessing the left side of the screenshot is “Repeater1” and right side is “Repeater2” ?

    As mentioned in the first post like below, the left side is the eth1 port (Repeater2) and right side is eth0 port (Repeater1). See the NetworkConfig.pptx sent you off-line. 

    >  See "eth0_eth1_ping.png" in the attached file below. 
    >  The right image is capturing the eth0 port, and the left is  the eth1 port.

    Pekka Varis said:
    Also cannot see the MAC addresses used in the messages.

    The MAC addresses are described in the NetworkConfig.pptx. Is this OK ?

    Could you reproduce this issue at your side as well ?

    Thanks and regards,
    Hideaki

  • 0 in reply to Hideaki Matsumoto
    TI__Mastermind 27050 points
    Hideaki Matsumoto said:
    Pekka Varis said:
    Also cannot see the MAC addresses used in the messages.

    The MAC addresses are described in the NetworkConfig.pptx. Is this OK ?

    Could you reproduce this issue at your side as well ?

    Need to see the traces that include MAC addresses. The screenshots of wireshark with only IP is not enough. Suspicion for what is going on is ICMP echo is being sent to a MAC address that is not the unicast address MAC address of192.168.16.171 (what is being pinged). How Windows 10 determines what MAC address to use for ping is not something I'm familiar with or we test with. Ping is just required to send an ICMP echo to the IP unicast address it is told, how it uses Ethernet underneath is up to the implementation. 

    Also I would want to see the traces in time order, in order the understand what is the sequence.

    As another test I would suggest to use two more embedded Linux boards instead of the Windows and PROFINET boxes to see what traffic is seen with ping