Wired ethernet not working unless USB2 port connected to a computer (TZ-2301)

[wanthalf]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

I expect the OTBR to run with the wired ethernet connection when it is connected just to a power source.

Actual behavior (suspected bug)

The version 1.3 (using ESP-IDF 5.5.2) only connects to the wired ethernet network if the ESP32-S3 USB2 port is connected to a computer (or other device supporting serial connection such as a router). Otherwise (e.g. if connected to a USB charger or if connected via the ESP32-H2 USB1 port) it remains unreachable (IPv4 address should be assigned by DHCP, but remains unreachable both by PING and HTTP).

Before upgrading to 1.3/5.5.2 today, I tested with version 1.1/5.4 where it worked, but only for a limited time. After an hour or two, the OTBR also stopped responding to PING and HTTP, even when connected to a computer. Even a constantly open serial connection in a console froze. But reopening the serial connection revived (woke up) the ethernet connection without any actual reset as well.

Is it a bug or a result of some configuration option? I only configured the wired ethernet adaptor (SPI) and enabled the Web interface and autostart, as suggested in the documentation. (With the version 1.3, I also changed the preference for IPv6 from Local-Link to Global IPv6, despite I don't have a global IPv6 prefix configured at the moment yet.) All other options should be at their default values.

Error logs or terminal output

Steps to reproduce the behavior

1. Install the "example/basic thread border router" according to https://docs.espressif.com/projects/esp-thread-br/en/latest/dev-guide/build_and_run.html and https://www.matteralpha.com/how-to/how-to-build-a-thread-1-4-border-router as described above.
2. Connect to wired ethernet and to a power source - charger or a computer by one of the USB ports with the consequences as described above.

Project release version

v1.3

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

MacOS

Operating system version

Sequoia (platform used for compilation)

Shell

ZSH

Additional context

No response

[JonahMMay]

I am having the same issue but with Wi-Fi

[tanyanquan]

Hi @wanthalf and @JonahMMay , thanks for reporting this issue! We've investigated and found that this issue arose because of an update to launch_openthread_border_router() in the latest release of esp-thread-br, which uses ot_console_start() (which has blocking behavior) to replace esp_openthread_cli APIs.

Therefore, if you do not intend to connect the device to USB serial, please comment out ot_console_start() in examples/common/thread_border_router/src/border_router_launch.c and that should allow the example to run correctly.

Do feel free to reach out if you face any additional issues!

[wanthalf]

Thank you. I expected something like that. However, is there not solution that would NOT disable the serial (debugging) access and still allow running without it? I know, maybe that is what you tried before and it was unreliable for some other reason, like I noticed with version 1.1?

[tanyanquan]

Hi @wanthalf , thanks for your quick reply. There is actually a non-blocking version of ot_console_start(), which we are currently adapting for use with the OT examples.

For now, the easiest workaround is to add WHOLE_ARCHIVE to esp-idf/components/console/CMakeLists.txt:

idf_component_register(SRCS ${srcs}
                            ${argtable_srcs}
                    INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}
                    PRIV_INCLUDE_DIRS private_include
                    REQUIRES "${requires}"
                    PRIV_REQUIRES esp_driver_uart
                                  esp_driver_usb_serial_jtag
                                  esp_usb_cdc_rom_console
                    WHOLE_ARCHIVE
                    )

If you're interested in slightly more details, the default version of linenoiseSetReadCharacteristics (which is used in esp_console_new_repl_usb_serial_jtag) in esp-idf/components/console/linenoise/linenoise.c is weakly-defined but blocking. The workaround we described above ensures that components/console/esp_console_repl_internal.c (which contains the strongly-defined and non-blocking version of linenoiseSetReadCharacteristics) is compiled without requiring any other changes.

We're working on an official fix for this which will involve calling esp_console_stop_repl elsewhere.

[JonahMMay]

Thanks for confirming it is a known issue! I'll go ahead and wait for the next release. I have two OTBRs but haven't deployed them yet due to network instability issues. I mainly use a HomePod mini and was just wanting them for redundancy in case the HomePod goes offline, so I can wait a bit.

[wanthalf]

Thank you. I will probably wait for the fix as well. I have connected the OTBR to a router, so it is running, and the actual problem to solve now is a connection with a HomeAssistant located on a different LAN, bridged by OpenVPN. I guess I have to deal with some IPv6 routing between the networks.

[kepstin]

@wanthalf I would recommend reading through https://github.com/matter-js/python-matter-server/blob/main/docs/os_requirements.md - when using a VPN setup like you are describing, you would need an mDNS relay between the lan and the VPN devices, and the VPN concentrator needs to be configured to pick up and use IPv6 router announcements (Linux disables this by default on devices that do routing)

[wanthalf]

Thanks for the hint. I was hoping that routing and/or global IPv6 addresses would solve the problem. If matter really only relies on link-local multicast, it is not a good news for my plans. I planned to do wireguard tunnels between the networks and use global IPv6 from my VPS, because the other locations do not have a native IPv6 connectivity. I was somehow hoping that would also solve the problem. I noticed the OTBR configuration allows to set preference for global IPv6 (rather than just link-local or ULA), so I was hoping that would make the deal. The most confusing part for me is the fact, that I enter IPv4(!) address of the OTBR into the HomeAssistant and they communicate through the API, but obviously it does not work in all aspects just by IPv4.

[Danimal4326]

I'm seeing the same issue, but with WiFi networking. I can only get the OTBR to connect to WiFi when plugged into a USB port on a computer. Will try the fix above and report back

[Danimal4326]

Adding "WHOLE_ARCHIVE" to esp-idf/components/console/CMakeLists.txt did the trick and now able to connect to WiFi with just a USB power adapter.