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.

PROCESSOR-SDK-J7200: udhcpd server daemon running failed in CPSW5G since BOOTP packet seems be Not reached to CPSW5G

Part Number: PROCESSOR-SDK-J7200
Other Parts Discussed in Thread: DRA821U, DRA829, TDA4VM, DRA821, TDA4VH

Hi TI

This is an issue reported in SDK 8.2, which is still being reproduced in SDK 8.4.

A customer has been reported that they still can not see ip4 related packet and can not get ip from udhcpd.

Please check if the issue is reproducible. and let us know how to fix the problem.

The following is observed during the test.

Regards, 

Jack

  • Hi Jack,

    Can you explain the test setup and share if you have any scripts to run the tests.

    How is the setup different from EVM? This will help us to reproduce the issue as closely as possible.

    Regards,
    Tanmay

  • Hi Tanmay

    We're still under waiting for test script and test setup configuration from the customer engineer.

    It has been delayed due to email server security issue. Attachment has been blocked. Sorry for delay.

    Regards, 

    Jack

  • HI Tanmay

    I test whether ip is assigned to the pc by connecting the pc with ethernet in TI EVB (dhcpd). 

    But, The port of CPSW5G is not assigned an IP address.

    I share the test procedure and configuration .

    Environment configuration

    1. EVB(TI): udhcp running => Attach the configuration and uchcpd configuration files, recipe, and service files. (Based on TI SDK8.04)

    udhcpd.zip

       1)  UUnzip udhcpd,copy(/sources/meta-arago/meta-arago-distro/recipes-tisdk)  

       2)  Add udhcpd to roots image( yocto-build/sources/meta-arago/meta-arago-distro/recipes-core/images/tisdk-default-image.bb )

       3) Build 및 download

       4)  =>. /usr/sbin/udhcpd -f /etc/udhcpd_tgu.conf &

    2. PC

       1) interface   eth1(line9 in udhcpd_tgu.conf)    => CPSW5G (Fix to eth0 when using CPSW2G)

       2) PC configuration(dhcp)

              

       3) Assign IP address

             *. Ipconfig /renew(in PC side)

       4) Check packet 

             *. EVB(TI) – tcpdump -I eth1 -n &

             *. PC – Wireshark 

    3. normal packet using CPSW2G

    eth0_normal.zip

    Regards,

  • First of all, I recommend you to go over the below link to get familiar with our solution.

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_04_00_06/exports/docs/psdk_rtos/docs/user_guide/developer_notes_ethfw.html

    Please review the User guide to make sure you have the correct setup on EVM, especially the ethernet cable is connected to the right port on EVM for your testing.

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_04_00_06/exports/docs/ethfw/docs/user_guide/index.html

  • What does the above answer have to do with not being able to get an IP from eth1 (CPSW5G) through DHCP in EVM?

    In eth0, it is normal to get an IP assigned by DHCP.

    How do I connect the EVM and PC through eth1 (CPSW5G) and get the IP assigned to the PC by DHCP from the EVM?


    Bootp packet is not seen when looking at the packet with tcpdump in evm. Please support.

  • Subject changed to "udhcpd server daemon running failed in CPSW5G since BOOTP packet seems be Not reached to CPSW5G"

    @Hi Stanley

    They have tried to run udhcpd server program in CPSW5G after verified the running on CPSW2G.

    Could you please teach him to debug in CPSW5G to find out the problrmatic area? He's still unable to dig out the root cause in CPSW5G FW side.

    BTW, 

    If you're able to reproduce the DHCP IP assignemnt issue on CPSW5G using udhcpd, Can you help to fix the problem?

    As my understanding, The client PC is unable to get IP address from the DRA821U' udhcpd server side.

    It works from CPSW2G port. But failed at CPSW5G ports. They want to run udhcpd server via CPSW5G from their custom board which does not include CPSW2G port.

    Regards, 

  • Hi All,

    The packets sent by the DHCP Client is broadcast packet is not reaching the A72. By default, the ethfw does not transfer the broadcast and multicast packets to all the cores. This would result in the DHCP server not receiving any request.

    The solution to this would be to enable intercore ethernet support. This would ensure that the multicast and broadcast packets are forwarded to the A72 core. But the implementation of the intercore ethernet is through creation of another interface on linux called tap interface.

    To tie the eth1 and tap interface together, you can create a bridge interface with this two interfaces and run the dhcp server on this interface. This isn't tested on TI side, but this should work.

    To create a tap interface : Please see this. Make sure that the flag "ETHFW_INTERCORE_ETH_SUPPORT" is "yes" and "ETHFW_PROXY_ARP_SUPPORT" flag is "no". These flags can be changed in [RTOS-SDK-INSTALL-DIR]/ethfw/ethfw_build_flags.mak

    After the changes, you will have to do a rebuild for ethfw and update the binary in the linux filesystem.

    To create bridge : Run these commands from linux user space. After this bind the DHCP server to this br0. The bridge interface can also be configured from systemd-network service. The interface br0 will be the interface to use after this.

    Fullscreen
    1
    2
    3
    4
    ip link add name br0 type bridge
    ip link set dev br0 up
    ip link set dev tap0 master br0
    ip link set dev eth1 master br0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Can you try this and let me know the results.

    Regards,
    Tanmay

  • Hi Tanmay.

    Thanks for your kind support.

    As they followed with your suggestion,, the ip address is assigned with the bootp packet returend, But Ping is failed. 

    The below is the test result. Please check the problem.

    1) Download ethfw with two flags set below in Ethfw to linux filesystem.

    ETHFW_INTERCORE_ETH_SUPPORT=yes

    ETHFW_PROXY_ARP_SUPPORT=no

    2) Create tab interface:  Create br0 after porting the source to RootFS with "<RTOS>/ethfw/apps/tap" code

    3) br0 gateway ip assignment and interface check

    4) Run Udhcpd and check ip allocation (confirm pc receives 192.168.5.11)

    A. EVM

    B. PC

    5) Packet check

    A. Check the interface status of the window after IP allocation: Rx does not work

    B.  Wireshark: only arp packets observed

    C, Tcpdump (EVM): Replying to arp packets

    6) Ping progress (PC -> EVM): No ping

    Regards, 

    Jack

  • Hi Jack, 

    Can you do the following experiment and share the result :

    • Start with a new boot.
    • run the command `ethtool -t eth1`
    • Run a ping test from PC to EVM for around 10 seconds
    • run the command `ethtool -t eth1` again 

    After this please share the output of ethfw logs captured at MAIN UART 2.

    Regards,
    Tanmay

  • Hi Tanmay

    Please find the test result what Customer tried. 

    Can you please check the below?

    * Run the command 'ethtool -t eth1' 

    The log before and after pinging from pc to EVM for 10 seconds is the same as below.

    * After this please share the output of ethfw logs captured at MAIN UART 2.

    The followings is the log from Ethfw.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    root@j7200-evm:/etc/systemd/system# cat /sys/kernel/debug/remoteproc/remoteproc*/trace0
    Sciclient_boardCfgRm init Passed
    DM Built On: Jun 16 2022 04:04:08
    Sciserver Version: v2022.01.1.0-REL.CORESDK.08.02.01.03-1-g59713
    RM_PM_HAL Version: REL.CORESDK.08.02.01.03-1-g59713
    Starting Sciserver..... PASSED
    IPC_echo_test (core : mcu1_0) .....
    mcu1_0 <--> mcu2_1, Ping- 10000, pong - 10000 completed
    =======================================================
    CPSW Ethernet Firmware
    =======================================================
    ETHFW: Shared multicasts (software fanout):
    01:00:5e:00:00:01
    01:00:5e:00:00:fb
    01:00:5e:00:00:fc
    33:33:00:00:00:01
    33:33:ff:1d:92:c2
    01:80:c2:00:00:00
    01:80:c2:00:00:03
    ETHFW: Reserved multicasts:
    01:80:c2:00:00:0e
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks.

    Regards, 

    Jack

  • Hi Jack,

    The command "cat /sys/kernel/debug/remoteproc/remoteproc*/trace0" does not print the statistics which i actually wanted to see. Do you have any other way to get CPSW statistics? like running debug gels from CCS.

    If No, then let me know and I will provide you with a script to print relevant statistics.

    Regards,
    Tanmay

  • Hi Tanmay.

    Please provide us with the script to print out. We don't have the relevant stuff.

    Regards, 

  • Hi Jack,

    First can you try by running this command after the bridge is setup : "bridge vlan add dev br0 vid 1 pvid untagged self"

    Also for the script, please let me know the MAC_PORT to which the ethernet cable is connected.

    Regards,
    Tanmay

  • Hi Tanmay

    Please find the answers from Customer side. below.

    “bridge vlan add dev br0 vid 1 pvid untagged self “
    --> We are currently testing SDK 8.05 on the EVM board, so we will share the results after setting the binary related to tap tomorrow.

    Also for the script, please let me know the MAC_PORT to which the ethernet cable is connected.
    --> Testing with 2 ports below.

    Thanks.

    Regards, 

    Jack

  • Hi

    ip link add name br0 type bridge

    ip link set dev br0 up

    ip link set dev tap0 master br0

    ip link set dev eth1 master br0

    bridge vlan add dev br0 vid 1 pvid untagged self

    As shown above, the phenomenon during the test is the same.

  • Hi Jack, 

    As you are using EVM and default SDK, you should be able to get ethfw log on MAIN_UART2. When you connect a micro-usb connection to MAIN UART, you would see 4 interfaces coming up on the host device. For Linux, it would be /dev/ttyUSB0 to /dev/ttyUSB3. For windows, it would be 4 com ports. One gives you the comand-line (/dev/ttyUSB0 or 1st COM port). The 3rd instance, /dev/ttyUSB2 or 3rd COM port, will be ehfw logs.

    So you should have easy access to ethfw logs. 

    The issue with writing the script is that the logging function in ethfw is clearing the stat registers so I am not able to read the registers. 

    Can you please try to get the ethfw logs over uart. Getting stats after this would be easy. You have to follow the following steps :

    • Start with a new boot.
    • run the command `ethtool -t eth1`
    • Run a ping test from PC to EVM for around 10 seconds
    • run the command `ethtool -t eth1` again 

    Sorry for the confusion caused.

    Regards,
    Tanmay

  • Hi Tanmay

    As customer followed up your suggestion, they are unable to get any logs from MAIN_UART2 as below.

    When testing with the Default evb binary, no logs are taken on the other three ports except the linux log port (MAIN_UART).
    Please check if the default pre-built binary able to produce the ethfw logs.

    Thanks.

    Regards, 

    Jack

  • Hi Jack,

    Can you just confirm that you tried COM5. You should get the logs on COM5.

    Regards,
    Tanmay

  • Hi Tanmay

    Yes, COM5 does not show any logs. 
    Is it possible to see any log with default binary too?
    Let me check once again this week by my EVM as I am on the biz trip. 

    Regard

    Jack

  • Hi Tanmay

    I have the default SDK bianry only. It does not show any EthFW logs via 4x MAIN UARTs and 2x MCU UART ports. I can see only Linux Logs from the first MAIN UART port.

    Please let us know if we're able to see EthFW log from UART port with PSDK fedault binary. 

    If I have to enable Log output feature, Also let us know how to enable it.

    Thanks.

    Regards, 

    Jack

  • Hi Jack,

    Extremely sorry for the delay.

    You can see this to enable the logs from ethfw :

    In some cases, it might be possible that you do not have a ethfw UART available on board, in those cases a patch needs to be applied to ethfw to enable periodic dump of stats to the IPC buffer which can be viewed from Linux. The patch is available in the following attachment and is tested on SDK 8.6.

    Attachment : CPSW_Periodic_stat_dump.zip

    To apply the patch and build ethfw :

    1. Extract the patch from the attachment.
    2. Go to "[PSDK-RTOS-INSTALL-DIR]/ethfw" and create a git repository there if not one already. Run 
      1. git init - to create an empty git repository
      2. git add . - to add all the files to the git repo
      3. git commit -m "Initial Commit" - to do the first commit 
    3. Apply the patch "0001-Adds-support-for-periodic-CPSW-stat-collection.patch"
      1. run "git am [Path_to_0001-Adds-support-for-periodic-CPSW-stat-collection.patch]" to apply the patch
    4. Modify the code based on "readme.txt" given in the attachment for your setup and requirements
    5. To build ethfw, go to "[PSDK-RTOS-INSTALL-DIR]/ethfw" and run the following command
      1. make ethfw_all BUILD_SOC_LIST=<SOC_NAME>
        1. <SOC_NAME>=J721E for DRA829 and TDA4VM
        2. <SOC_NAME>=J7200 for DRA821
        3. <SOC_NAME>=J784S4 for TDA4VH

    To read the stats:

    1. The printed stats can be read using the command
      1. cat /sys/kernel/debug/remoteproc/remoteproc*/trace0

    Can you take the stats now and check if any increments are seen on the "txGoodFrames" of the external Port statistics.

    Regards,
    Tanmay

  • Hi Tanmay

    Thanks for your kind support.

    Here's an attachment what the customer obtained after applied your patch.

    TI_patch_for_ethfwlog_by_not_ping.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    root@j7200-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc*/trace0
    Sciclient_boardCfgRm init Passed
    DM Built On: Feb 1 2023 16:37:10
    Sciserver Version: v2022.01.1.0-REL.CORESDK.08.06.00.09-14-ge559a+
    RM_PM_HAL Version: REL.CORESDK.08.06.00.09-7-g4da19
    Starting Sciserver..... PASSED
    IPC_echo_test (core : mcu1_0) .....
    mcu1_0 <--> mcu2_1, Ping- 10000, pong - 10000 completed
    =======================================================
    CPSW Ethernet Firmware
    =======================================================
    Warning: Using 6 MAC address(es) from static pool
    ETHFW: Shared multicasts (software fanout):
    01:00:5e:00:00:01
    01:00:5e:00:00:fb
    01:00:5e:00:00:fc
    33:33:00:00:00:01
    33:33:ff:1d:92:c2
    01:80:c2:00:00:00
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks.

    Regards, 

    Jack

  • Hi Jack,

    Is ping from PC to SoC working?

    Can you share the output of "tcpdump -i eth1" when pinging the SoC from PC.

    Regards,
    Tanmay

  • Hi Tanmay

    I am attaching tcpdump data here. Please review it.

    It is sending a reply to ARP msg and does not ping from PC to EVM.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    root@j7200-evm:~# tcpdump -i br0
    [ 277.009896] device br0 entered promiscuous mode
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
    22:52:45.059085 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:45.059148 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:46.063931 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:46.063988 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:47.162649 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:47.162705 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:48.067979 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:48.068058 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:49.061076 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:49.061146 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:50.061648 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:50.061701 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:51.184549 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:51.184599 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:52.064542 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:52.064614 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:53.063939 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi,

    From logs it was observed that Port-2 Tx Broadcast count is increasing, means some broadcast packets sent out of MAC port-2. 

    Can you try Ping from EVM to PC.

    Please share the logs using "CPSW_Periodic_stat_dump.zip" along with tcpdump with -xx option on EVM and Wireshark capture at PC.

    Best Regards,
    Sudheer

  • Hi Sudheer

    Here's attahced log snapshot for EVM to PC use case

    Sometimes PING is working according to them.

    Thanks.

    Regards, 

    Jack

  • Hi Tanmay

    Please find the tcpdump below.

    The tcpdump log of br0 is delivered because tab and eth1 are in use by tying br0 to bridge.

    It is sending a reply for Arp, and the ping from PC to EVM is not going.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    root@j7200-evm:~# tcpdump -i br0
    [ 277.009896] device br0 entered promiscuous mode
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
    22:52:45.059085 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:45.059148 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:46.063931 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:46.063988 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:47.162649 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:47.162705 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:48.067979 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:48.068058 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:49.061076 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:49.061146 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:50.061648 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:50.061701 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:51.184549 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:51.184599 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:52.064542 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    22:52:52.064614 ARP, Reply j7200-evm is-at b6:70:f8:e0:b8:85 (oui Unknown), length 28
    22:52:53.063939 ARP, Request who-has j7200-evm tell 192.168.5.12, length 46
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks.

    Regards, 

    Jack

  • Hi,

    When ping is working from EVM to PC, during that time check ping from PC to EVM?

    Also, share the Logs using "CPSW_Periodic_stat_dump.zip" while ping is going on.

    Best Regards,
    Sudheer

  • Jack's PC is weird, so I'm attaching a log.evm_to_pc.zip

    When ping is working to EVM to PC, pc to EVM is not working.

  • Hi Sudheer

    We want all of this to be transmitted from ethernet firmware to eth1 interface without filtering. ( BROADCAST packet, Unknown Unicast Packet, Unknown Multicast Packet, CPU Unicast packet)
    Is it possible to share about the current progress?

    Thanks

    Regards. 

    Dongseuk

  • Hi,

    We want all of this to be transmitted from ethernet firmware to eth1 interface without filtering. ( BROADCAST packet, Unknown Unicast Packet, Unknown Multicast Packet, CPU Unicast packet)

    All broadcast packets can be forwarded to eth1 (A72). Please refer to FAQ [How to forward Broadcast to HLOS on A72]
    Default CPU unicast (A72 MAC address as destination MAC) will be forwarded to eth1.
    Unknown Multicast and Unicast can't be possible to direct to eth1.

    Best Regards,
    Sudheer

  • HI. Sudheer 

    fix the two things below, eth1 interface confirmed that ip allocation with dhcp and ping from EVM to EVM to pc works well.

    1.ethfw 

    2. linux 

    ip maddr add FF:FF:FF:FF:FF:FF dev eth1

    However, if eth0 and eth1 are tested with bridge as br0, it does not work.

    To solve this problem, make the mac address of br0 equal to the mac address of eth1 and it works well during the test.
    Is this the right way to approach it? Is there any other way?

     

    Regards,

    dongseuk. 

  • Hi,

    Can you try below and confirm where you are able to get IP and Ping is working?

    Ignore above changes in Ethfw and Linux side.

    Enable Inter-core Virtual Ethernet communication, no need to create bridge interface.

    Try to check whether IP assigned to eth1 and physical switch interface on Ethfw, you can observe from Ethfw debug logs.

    Best Regards,
    Sudheer

  • HI, 

    Cannot get ip from dhcp to eth1 without the above two modifications. 

    Also, the use of br0 is essential for our application development.
    As you can see from the top, the defines below are applied.
    ETHFW_INTERCORE_ETH_SUPPORT=yes
    ETHFW_PROXY_ARP_SUPPORT=no

    The test environment is as shown in the link below, and in the picture in the link, pc1 and pc2 can now be imported as dhcpd
    Ping works with pc1<->linux br0, pc2<->linux br0.
    However, pc1 <->pc2 does not work.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1222969/dra821u-ip-assignment-failed-for-pc-connected-via-cpsw5g/4633431#4633431

    Regards,

    dongseuk

  • Hi,

    ETHFW_INTERCORE_ETH_SUPPORT=yes
    ETHFW_PROXY_ARP_SUPPORT=no

    In above configuration, you mentioned that IP is assigned but ping is not working.
    In above if you configure MAC address of bro same as eth1 then you can able to ping as well.

    If Broadcast packet forwarding to Linux is fine in your environment as per your use case then above fixes working for you fine.

    However, pc1 <->pc2 does not work.

    For this we may need following:
    1. Forwarding of PC1 packets to eth1 interface from bro.
    2. If above is fine, then eth1 should accept the packets with PC1 MAC address as destination address in packet for this we may need to add PC1 MAC address in eth1/A72 List.

    Please refer to Unicast address Addition to A72, In example Port-2 alone configured for policer rules you can add all ports to the policer.
    But, drawback here is, It is static configuration.

    If okay, you can connect CPSW2G to one of CPSW9G port and check your use case.

    Best Regards,
    Sudheer

  • HI,

     How to configuration below?

    1. Forwarding of PC1 packets to eth1 interface from bro.
    2. If above is fine, then eth1 should accept the packets with PC1 MAC address as destination address in packet for this we may need to add PC1 MAC address in eth1/A72 List.

    Regards,

    dongseuk

  • Hi,

    Forwarding of PC1 packets to eth1 interface from bro.

    I am not sure, how to configure it. Ideally it should transmit from br0 to eth1.

    This you can confirm by checking the Internal Host Port Rx packet count while pinging from PC1 to PC2.
    When you run "#ethtool -t eth1" statistics will be printed in ethfw debug UART window.

    May be you check by running tcpdump -i eth1.

    2. If above is fine, then eth1 should accept the packets with PC1 MAC address as destination address in packet for this we may need to add PC1 MAC address in eth1/A72 List.

    Please refer to FAQ [Unicast address Addition to A72], In example Port-2 alone configured for policer rules you can add all ports to the policer.
    But, drawback here is, It is static configuration.

    Best Regards,
    Sudheer

  • Hi Doedla Sudheer Jumar, currently we are using DRA821U EVM not our custom board.

    PLEASE TEST WITH YOUR EVM for our target environments (using br0 with eth0 and eth1)!  And than please provide the solution.

    Already we wait around one year for this issue!

    -- YoungHan Kim

  • Hi Young,

    Can you please try at your end by adding PC#1 MAC address to ALE by referring to FAQ [Unicast address Addition to A72],

    It should work for your Use-case.

    Best Regards,
    Sudheer

  • Hi Doredla Suhheer Kumar,

    Currently we use SDK 8.06.

    Do you mean to apply apply only "Adding a Unicast MAC Address entry for A72 only for Port-2" patch on origianl SDK 8.06?

    Or does it required other patch?

    Thanks!

    Regards

    YoungHan Kim

  • HI! Sudheer,

    FAQ [Unicast address Addition to A72] was applied to the above environment (eth0 and eth1 were used as br0).
    However, #PC1 and #PC2 still do not ping.

    It's a test on EVM, so I think you can try it. Please test it and provide the solution.

    Regards

    dongseuk, 

  • Hi,

    It's a test on EVM, so I think you can try it. Please test it and provide the solution.

    I have tried and confirmed the forwarding of unicast MAC address frames coming from any of external port to A72 using the latest patch attached in FAQ [Adding a unicast MAC Address entry for A72].

    Earlier patch forward to A72 only when packet receiving from External Port-2.

    Can you please try with latest patch from above FAQ in that instead of default MAC address in patch {00:01:02:03:04:05} use your PC1 MAC address (which is connected to CPSW2G).

    Best Regards,
    Sudheer

  • HI Sudheer, 

    After applying the patch you gave me, eth0 (CPSW2G) is allocated ip from udhcpd, but not ip as eth1 (CPSW5G).
    Should I work on the tap interface above after applying your patch?
    Also, can you tell me the method you checked in order?

    Regards,

    dongseuk

  • Hi Dong,

    Above pointed patch is for only to make successful ping between PC1 & PC2. Rest all to be needed as is. (till you confirmed IP allocation on CPSW2G, CPSW5G and ping between bridge and PC1 as well as ping between Bridge and PC2)

    Make sure that you are using PC1 MAC address instead of Unicast MAC address mentioned in reference patch.

    Also, can you tell me the method you checked in order?

    I have connected PC to one of switch port of CPSW5 and configure the MAC address mentioned reference patch to PC and send some frames using Packeth application from PC to CPSW5G and observed those packets were reaching to A72.

    Basically it is for forwarding of Unicast MAC address frames to A72. (Address we are registering with Ethfw by adding static code).

    Best Regards,
    Sudheer

  • HI! Sudheer

    I applied the patch you gave me and tested it on TI EVM (SDK8.06) as below. However, there is still no ping between PC1 and PC2.
    1. Apply patch and ethfw and linux side modifications
    2. ETHFW_INTERCORE_ETH_SUPPORT=yes
        ETHFW_PROXY_ARP_SUPPORT=no
    3. Create br0
       brctl addbr br0
       brctl addif br0 eth0
       brctl addif br0 eth1
       ifconfig br0 192.168.5.254 netmask 255.255.255.0
    4. Change the Mac address of br0 to the Mac address of eth1


    5. Running udhcpd: Checking ip allocation PC1:192.168.5.11 PC2:192.168.5.12


    6. ping PC1 (CPSW2G:192.168.5.11) to PC2 (CPSW5G:192.168.5. I applied the patch you gave me and tested it on TI EVM (SDK8.06) as below.

    Attached is the wireshark log on the PC side and the tcpdump on the EVM
    Please check

    .

    BR0_tcpdump.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    root@j7200-evm:~# tcpdump -i br0 -n
    [ 1724.766081] device br0 entered promiscuous mode
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
    23:16:52.734108 ARP, Request who-has 192.168.5.11 tell 192.168.5.12, length 46
    23:16:52.734429 ARP, Reply 192.168.5.11 is-at 88:36:6c:fa:d9:15, length 46
    23:16:53.002702 IP 192.168.5.11.63520 > 8.8.8.8.53: 50022+ A? dns.msftncsi.com. (34)
    23:16:53.002799 IP 192.168.5.254 > 192.168.5.11: ICMP net 8.8.8.8 unreachable, length 70
    23:16:53.036305 IP 192.168.5.11.63520 > 8.8.8.8.53: 50022+ A? dns.msftncsi.com. (34)
    23:16:53.728042 ARP, Request who-has 192.168.5.11 tell 192.168.5.12, length 46
    23:16:53.728515 ARP, Reply 192.168.5.11 is-at 88:36:6c:fa:d9:15, length 46
    23:16:54.039261 IP 192.168.5.11.63520 > 8.8.8.8.53: 50022+ A? dns.msftncsi.com. (34)
    23:16:54.084889 IP 192.168.5.11.65235 > 8.8.8.8.53: 57906+ A? gms.ahnlab.com. (32)
    23:16:54.734450 ARP, Request who-has 192.168.5.11 tell 192.168.5.12, length 46
    23:16:54.734780 ARP, Reply 192.168.5.11 is-at 88:36:6c:fa:d9:15, length 46
    23:16:55.733115 ARP, Request who-has 192.168.5.11 tell 192.168.5.12, length 46
    23:16:55.733536 ARP, Reply 192.168.5.11 is-at 88:36:6c:fa:d9:15, length 46
    23:16:56.041411 IP 192.168.5.11.63520 > 8.8.8.8.53: 50022+ A? dns.msftncsi.com. (34)
    23:16:56.041532 IP 192.168.5.254 > 192.168.5.11: ICMP net 8.8.8.8 unreachable, length 70
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    PC_wiresharklog.zip

    Regard,

    dongseuk 

  • Hi,

    I hope the Wireshark log attached will be capture at PC1 and PC2 and ping is from PC2 to PC1.
    From log it seems PC1 is sending response for ARP request sent from PC2, but bridge may not be forwarding on eth1 it seems.

    Can you please capture tcpdump on eth1 when pinging from PC2 to PC1.
    Also capture tcpdump on eth0 when pining from PC1 to PC2.

    Best Regards,
    Sudheer

  • HI! Sudheer 

    When I ping between PC1 and PC2, I collect and attach the wireshark log from PC1 and PC2, and the tcpdump log of eth1 (PC2 to PC1) and eth0 (PC1 to PC2).
    Please check.

    PC2_to_PC1.zip
    PC1_to_PC2.zip

    Regards,

    dongseuk

  • Hi,

    Can you please share the ALE Table dump (ethtool -t eth1) as well before and after trying the ping from PC1 to PC2 and PC2 to PC1.
    If ethtool is not supported, can you refer to FAQ and provide the statistics and ALE Table.


    Best Regards,
    Sudheer

  • HI, 

    The above command has no value as shown below.

    The ethfw log is as follows

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    root@j7200-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc*/trae0
    cat: '/sys/kernel/debug/remoteproc/remoteproc*/trae0': No such file or directory
    root@j7200-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc*/trace0
    Sciclient_boardCfgRm init Passed
    DM Built On: Feb 1 2023 16:37:10
    Sciserver Version: v2022.01.1.0-REL.CORESDK.08.06.00.09-14-ge559a+
    RM_PM_HAL Version: REL.CORESDK.08.06.00.09-7-g4da19
    Starting Sciserver..... PASSED
    IPC_echo_test (core : mcu1_0) .....
    mcu1_0 <--> mcu2_1, Ping- 10000, pong - 10000 completed
    =======================================================
    CPSW Ethernet Firmware
    =======================================================
    Warning: Using 6 MAC address(es) from static pool
    ETHFW: Shared multicasts (software fanout):
    01:00:5e:00:00:01
    01:00:5e:00:00:fb
    01:00:5e:00:00:fc
    33:33:00:00:00:01
    33:33:ff:1d:92:c2
    01:80:c2:00:00:00
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    dongseuk

  • Hi,

    From ALE & Policer tables it is identified as no policer rules for PC1 MAC address at CPSW5G side.

    Please find the log at my side below has ALE entry with the unicast address (It has to be "88366cfad915" in your case i.e. PC1 MAC address) and corresponding policer rule to forward packets with destination MAC as above unicast then forward to A72.

    Can you please try with latest patch from above FAQ in that instead of default MAC address in patch {00:01:02:03:04:05} use your PC1 MAC address (which is connected to CPSW2G).

    It looks like you are using patch as is, without modifying the MAC address {00:01:02:03:04:05} with your PC1 MAC address.
    Please replace MAC address mentioned in FAQ with PC1 MAC address and test again i.e. replace {00:01:02:03:04:05} with {0x88,0x36,0x6c,0xfa,0xd9,0x15} PC1 MAC address.

    0: Vlanid: 012c, UTagged: 1ff, Mult: 1ff, UMult: 0, Member: 1ff RAW:[0 212c1ff1 ff0001ff]
    1: Vlanid: 0000, UTagged: 13, Mult: 13, UMult: 13, Member: 13 RAW:[0 20000130 13013013]
    2: Vlanid: 0001, UTagged: 1ed, Mult: 1ed, UMult: 0, Member: 1ed RAW:[0 20011ed1 ed0001ed]
    3: Address: ffffffffffff, Member:1ff Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[7fc 1000ffffffffffff]
    4: Address: 70ff761d92c3, Port: 000 Se=1 Bl=0 TOUCH=0 AGE=0 TRUNK=0 RAW:[1 100070ff 761d92c3]
    5: EtherType: 0806 RAW:[1 20000000 00000806]
    6: Address: 70ff761d92c1, Port: 000 Se=1 Bl=0 TOUCH=0 AGE=0 TRUNK=0 RAW:[1 100070ff 761d92c1]
    7: Address: 70ff761d92c2, Port: 000 Se=0 Bl=0 TOUCH=0 AGE=0 TRUNK=0 RAW:[0 100070ff 761d92c2]
    8: Address: 000102030405, Port: 000 Se=0 Bl=0 TOUCH=0 AGE=0 TRUNK=0 RAW:[0 10000001 02030405]
    9: Address: 333300000001, Member:001 Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[4 10003333 00000001]
    10: Address: 01005e000001, Member:001 Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[4 10000100 5e000001]
    11: Address: 3333ff1d92c2, Member:001 Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[4 10003333 ff1d92c2]
    12: Address: 0180c2000000, Member:001 Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[4 10000180 c2000000]
    13: Address: 0180c2000003, Member:001 Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[4 10000180 c2000003]
    14: Address: 3333000000fb, Member:1ed Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[7b4 10003333000000fb]
    15: Address: 333300010003, Member:1ed Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[7b4 1000333300010003]

    1008 Free Entries

    0: POLICER_DST_MAC,ALE Index: 3
    0: POLICER_ETHERTYPE,ALE Index: 5
    0: POLICER_THREAD,THREAD ID:4
    0: POLICER_STATS: Hit: 0, RedHit: 0, YellowHit: 0
    1: POLICER_PORT, PORT_NUM: 1 ISTRUNK:0
    1: POLICER_THREAD,THREAD ID:0
    1: POLICER_STATS: Hit: 0, RedHit: 0, YellowHit: 0
    2: POLICER_DST_MAC,ALE Index: 7
    2: POLICER_THREAD,THREAD ID:1
    2: POLICER_STATS: Hit: 0, RedHit: 0, YellowHit: 0
    3: POLICER_DST_MAC,ALE Index: 8
    3: POLICER_THREAD,THREAD ID:1
    3: POLICER_STATS: Hit: 0, RedHit: 0, YellowHit: 0
    4: POLICER_DST_MAC,ALE Index: 14
    4: POLICER_THREAD,THREAD ID:1
    4: POLICER_STATS: Hit: 1, RedHit: 0, YellowHit: 0
    5: POLICER_DST_MAC,ALE Index: 15
    5: POLICER_THREAD,THREAD ID:1
    5: POLICER_STATS: Hit: 1, RedHit: 0, YellowHit: 0

    90 Free Entries

    Port 0 Statistics
    -----------------------------------------
    rxGoodFrames = 45
    rxBcastFrames = 8
    rxMcastFrames = 37
    aleDrop = 44
    rxOctets = 7154
    octetsFrames65to127 = 25
    octetsFrames128to255 = 12
    octetsFrames256to511 = 8
    netOctets = 7154
    portMaskDrop = 45
    alePolicyMatch = 8


    External Port 0 Statistics
    -----------------------------------------

1 2