GL-S20 Border Router: Devices Stay in Child State, Never Promoted to Router

Hello,

I'm using the GL-S20 IoT gateway as a Border Router in my Thread network.
I have several Full Thread Devices connected, but they remain in the child state and almost never get promoted to router.
Interestingly, when I connect the same devices to a GL-S200, they do become routers as expected.

Is there a specific setting that needs to be enabled on the GL-S20, or are there conditions that would prevent it from promoting devices to router?

Also, I noticed that if the GL-S20 is not the Leader of the Thread network, it doesn't obtain an OMR Address and doesn't act as a gateway between the Thread network and my LAN.
Is this expected behavior?

Thanks a lot,
Lilian

Only Full Thread Devices (FTDs) that are "Router Eligible End Devices" (REEDs) can be promoted to routers. Minimal Thread Devices (MTDs) cannot.

Hi,

It seems not be expected behavior.
Please let me know your S20 firmware version, and PM me the issue syslog.

Hi Bruce,

I'm using the latest firmware
Type : gl-s20-otbr
Version: 2.0.0-R1
I will send by MP the syslog after a reboot from the S20.

Many thanks in advance

The bug we are facing seems to be fixed with the 2.0.0-R1, regarding the release notes

Unfortunatly, we still facing it

Hi @lilianmartin,
Are you using the S20 as a border router for Home Assistant? Is your end device a Matter device or a Thread device?

Hi Lancer,

I'm a product architect, and I'm building Thread devices for a professional application. The GL-S20 is only used as a border router witouth customisation in the firmware.
Devices are only Thread, more specific CoAP. I'm not able to support Matter.

Hi,

I have tried with the dev board from Espressif and the latest release V1.2 (ESP Thread Border Router  |  OpenThread)

Everything works well. All my routers switch from child to router very fast and the border router switch from child to leader.
I've failed to run this build on the GL-S20, I've followed this tutorial (Firmware Compilation Guide - GL.iNet IoT Docs) but with the latest ESP-IDF (V5.4.2) and the latest tag from the Espressif github (GitHub - espressif/esp-thread-br: Espressif Thread Border Router SDK)

Hi @lilianmartin,
Can you tell me at which step it fails? Is there a log?

Hi Lancer,
sorry for the late reply, I was working with my team on the first bug we had, and I believed that we solved it !
firstly to answer your question, I haven't save the log, but if I 'm remember well, the code was crashing at the starting on a pointer error. I will try again this week to update the S20 with the latest release of Espressif, I will let you know if a succeed or not.

For the initial issue, I believe we've finally identified what was missing in our Thread setup.

We had overlooked the IPv6 prefix in the dataset. In fact, we configured the Network Name, Network Key, PAN ID, Extended PAN ID, and Channel. That was enough to create a Thread network, but not sufficient to route data over the internet.
When the network was started with the Border Router (BR) first (we always generate a full setup and copy/paste the Network Name, Network Key, PAN ID, Extended PAN ID, and Channel to our devices), everything worked fine because the BR was sending the IPv6 prefix to our devices.
However, when our devices started before the BR, one of them became the leader and never sent the IPv6 prefix to the BR.

That’s why we initially thought the BR needed to be the leader in order to route data over the internet.

At the end, I can say a big thank you to everyone helped us !

Hi @lilianmartin
Someone has already mentioned this on the OpenThread project BR stay as a child, so the Thread Network can't reach internet · openthread · Discussion #11767 · GitHub. The esp-thread-br version is too old, and we are planning to update it. If you are interested in DIY firmware, you can update the open-source firmware yourself. GitHub - gl-inet/gl-esp-thread-br: Fork Espressif Thread Border Router SDK for GL-S20

Hi Lancer,
I'm familiar with this thread :slightly_smiling_face:, it was originally opened by my colleague regarding the same issue.

It's great news that a firmware update is planned. Do you have an estimated release date?
On my side, I’ll try this week using the GitHub repository you shared.
I’ll go ahead and close this thread, and if I encounter any issues while building the open-source firmware, I’ll open a new one.

Many thanks