• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 34 subscribers
  • Views 804 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.

AM2434: Not responding to pings - lwIP bridge

Manuel Philippin
Intellectual 1210 points
Part Number: AM2434

Hello Sitara MCU team,

my customer is having issues with the lwIP Bridge for AM2434.

They have implemented a 3 port switch between CPSW, EMAC and the R5F.

The issue is that the port to the CPU is not responding to pings.

This is apparently document in the ICSS-CPSW+Bridge+documentation.pdf:

Note:

  1. Ping (ICMP functionality)  on the bridge  NetIF would  be un-responsive.  This is because

the same packet being  used for ping  with swapped source and destination  address would

not be sent out by the bridge  output  function  (bridgeif_send_to_port).

  1. The unicast packets with destination  address as the MAC address of the bridge  will  be

consumed  by the CPU itself  and will  not be forwarded.

However this presents an issue, as their product would need to be able to respond to pings so they will need a way to make this work.
Is there already a workaround for this?

Regards
Manuel 

  • 0
    TI__Genius 11736 points

    Hi Manuel Philippin,

    Yes, there is a known workaround for this. The reason for PING not working is the source code from LwIP itself which prevents sending the packet out to Rx Port. So if port-1 of your device gets the ping request packet, LwIP Stack will prevent the response packet going out on port-1. 

    File: source/networking/lwip/lwip-stack/src/netif/bridgeif.c

    This is the out-of-box lwip-stack code for the LwIP Bridge. The check at line no. 257 is what is causing the Ping functionality to break.

    Here, You will have to remove the check (if condition) at line no. 257.

    Please recompile all the LwIP Libraries after you make the modification and then re-build your application.

    This workaround has already been tested and should work as expected

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    TI__Intellectual 1210 points

    Hello Shaunak,

    please see below the response and suggestion from the customer:

    Using the suggested solution, to comment out line 257 in bridgeif.c, several other packets are repeated on the RX port, resulting in main Ethernet switch to detect a network loop and temporarily switch off network.

    The problem is, that ICMP ping source code recycles the received packet, but it does not reset the RX source port, though it is a TX packet now. To reset the source port for the new TX packet, I suggest to add line 208 in src/core/ipv4/icmp.c:

    --- old/src/core/ipv4/icmp.c

    +++ new/src/core/ipv4/icmp.c

    @@ -205,6 +205,7 @@ icmp_input(struct pbuf *p, struct netif *inp)

           /* We generate an answer by switching the dest and src ip addresses,

            * setting the icmp type to ECHO_RESPONSE and updating the checksum. */

           iecho = (struct icmp_echo_hdr *)p->payload;

    +      p->if_idx = 0;        /* reset if_idx to send back to original port */

           if (pbuf_add_header(p, hlen)) {

             LWIP_DEBUGF(ICMP_DEBUG | LWIP_DBG_LEVEL_SERIOUS, ("Can't move over header in packet"));

           } else {

    Regards
    Manuel

  • 0 in reply to Manuel Philippin
    TI__Genius 11736 points

    Hi Manuel,

    Manuel Philippin said:
    To reset the source port for the new TX packet, I suggest to add line 208 in src/core/ipv4/icmp.c:

    1. Yes, the change is valid. This way you can bypass the check at line no. 257 in bridgeif.c and ping for bridge will work.

    A point to note here is that TI does not own LwIP stack or the logical implementation of protocols inside LwIP. Its open source. The ICMP response to a ping packet is handled by LwIP by just changing the source and destination addresses. It does not change the if_idx of the packet buffer. I believe this was done to save on memory and overhead of creating new packets, so they re-use the packets. This is some optimization on the LwIP Side.

    Manuel Philippin said:
    Using the suggested solution, to comment out line 257 in bridgeif.c, several other packets are repeated on the RX port, resulting in main Ethernet switch to detect a network loop and temporarily switch off network.

    2. Apologies I did not think this through since initially I thought it is just for testing the bridge interface. You can add your changes in the icmp.c file implementation and revert the change I suggested in bridgeif.c. That way you will be able to ping your bridge interface without needing the change in the bridgeif.c file.

    Regards,

    Shaunak

  • 0 in reply to Shaunak Deshpande
    Intellectual 315 points

    Hi, how do I recompile the lwIP lib?

  • 0 in reply to Isaac Lucas de Lima Yuki
    TI__Genius 11736 points

    Hi Isaac,

    I think you are on 08.06 MCU_PLUS_SDK version (please correct me if I'm wrong). You can use the following commands for build.

    Fullscreen
    1
    2
    3
    make -s -f makefile.am243x lwip-freertos_r5f.ti-arm-clang
    make -s -f makefile.am243x lwip-contrib-freertos_r5f.ti-arm-clang
    make -s -f makefile.am243x lwipif-cpsw-freertos_r5f.ti-arm-clang
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    To clean existing libs, you can use:

    Fullscreen
    1
    2
    3
    make -s -f makefile.am243x lwip-freertos_r5f.ti-arm-clang_clean
    make -s -f makefile.am243x lwip-contrib-freertos_r5f.ti-arm-clang_clean
    make -s -f makefile.am243x lwipif-cpsw-freertos_r5f.ti-arm-clang_clean
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Also, you can add a flag to build it for debug builds. (PROFILE=debug). By default, it will be built for release mode.

    Regards,

    Shaunak

  • 0 in reply to Shaunak Deshpande
    Intellectual 315 points

    Hi Shaunak,

    almost, I'm using the version 9.01.00.41 of the SDK right now. When trying to build I get following errors:

    ```

    PS C:\ti\mcu_plus_sdk_am64x_09_01_00_41> gmake -s libs PROFILE=release
    Compiling: board.am64x.a53.gcc-aarch64.release.lib: led/led.c
    process_begin: CreateProcess(NULL, C:/ti/gcc-arm-9.2-2019.12-mingw-w64-i686-aarch64-none-elf/bin/aarch64-none-elf-gcc -c -mcpu=cortex-a53+fp+simd -mabi=lp64 -mcmodel=large -mstrict-align -mfix-cortex-a53-835769 -mfix-cortex-a53-843419 -Wall -Werror -g -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -Wno-unused-but-set-variable -fdata-sections -ffunction-sections -O2 -IC:/ti/mcu_plus_sdk_am64x_09_01_00_41/source -DSOC_AM64X -MMD -MT led.obj -o obj/am64x/gcc-aarch64/release/a53/board//led.obj led/led.c, ...) failed.
    make (e=2): Das System kann die angegebene Datei nicht finden.
    makefile.am64x.a53.gcc-aarch64:89: recipe for target 'led.obj' failed
    gmake[2]: *** [led.obj] Error 2
    makefile.am64x:625: recipe for target 'board_a53.gcc-aarch64' failed
    gmake[1]: *** [board_a53.gcc-aarch64] Error 2
    makefile:68: recipe for target 'libs' failed
    gmake: *** [libs] Error 2

    ```

    Shall I open a related issue?

    Thx for help!

  • 0 in reply to Isaac Lucas de Lima Yuki
    TI__Mastermind 37548 points

    Hello Isaac,

    Thanks for your response.

    Can you please confirm, are you using AM64x MCU+SDK instead of AM243x MCU+SDK?

    Isaac Lucas de Lima Yuki said:
    PS C:\ti\mcu_plus_sdk_am64x_09_01_00_41> gmake -s libs PROFILE=release
    Compiling: board.am64x.a53.gcc-aarch64.release.lib: led/led.c

    Can you please tell which version of GCC AARCH64 cross compiler is installed in your system?

    It seems like you don't have GCC AARCH64 cross compiler toolchain installed at directory C:\ti\gcc-arm-9.2-2019.12-mingw-w64-i686-aarch64-none-elf.

    Please refer GCC AARCH64.

    To know all the required tools for building the SDK, please refer Install Setup SDK tools.

    Regards,

    Tushar