OpenThread: 802.15.4 ESP32-C6 - Nodes unable route TCP packets across mesh.

[mamacker]

Hi there,
I'm trying to create a collection of mesh nodes that will respond to tcp socket requests across the mesh fabric.

This is my simple mesh:

Screenshot from 2024-04-20 17-14-56.png (13.97 KiB) Viewed 668 times

Here I have a border router that is indicated by 03b0 or the "black" bordered node. When I have nodes directly connected (within range) of that node, I'm able to connect to the TCP server of the mesh nodes and get back results just fine.

Which means: fa9a and 18e1 work great. The trouble is that I can't get the node labeled 1841 to received and respond to TCP traffic.

So - the server is working, and it will work when I get in range of 03b0 - but the mesh established by the other two esp32-c6's don't appear to be helping forward traffic from 03b0 to 1841.

Here are my build logs if its helpful (for esp version: v5.2.1):

Code: Select all

 *  Executing task: ninja  

[1/4] cd /home/mamacker/turbineone/Mesh802.15.4/ot_t1_ser...turbineone/Mesh802.15.4/ot_t1_server/build/esp_ot_cli.bin
esp_ot_cli.bin binary size 0xb3a80 bytes. Smallest app partition is 0x120000 bytes. 0x6c580 bytes (38%) free.
[2/4] Performing build step for 'bootloader'
[1/1] cd /home/mamacker/turbineone/Mesh802.15.4/ot_t1_server/build/bootloader/esp-idf/esptool_py && /home/mamacker/.espressif/python_env/idf5.2_py3.8_env/bin/python /home/mamacker/esp/v5.2.1/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x0 /home/mamacker/turbineone/Mesh802.15.4/ot_t1_server/build/bootloader/bootloader.bin
Bootloader binary size 0x64c0 bytes. 0x1b40 bytes (21%) free.

 *  Executing task: /home/mamacker/.espressif/python_env/idf5.2_py3.8_env/bin/python /home/mamacker/esp/v5.2.1/esp-idf/components/esptool_py/esptool/esptool.py -p /dev/ttyACM1 -b 460800 --before default_reset --after hard_reset --chip esp32c6 write_flash --flash_mode dio --flash_freq 80m --flash_size 2MB 0x0 bootloader/bootloader.bin 0x10000 esp_ot_cli.bin 0x8000 partition_table/partition-table.bin 

esptool.py v4.7.0
Loaded custom configuration from /home/mamacker/.config/esptool/esptool.cfg
Serial port /dev/ttyACM1
Connecting...
Chip is ESP32-C6FH4 (QFN32) (revision v0.0)
Features: WiFi 6, BT 5, IEEE802.15.4
Crystal is 40MHz
MAC: 54:32:04:ff:fe:0a:91:b4
BASE MAC: 54:32:04:0a:91:b4
MAC_EXT: ff:fe
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00006fff...
Flash will be erased from 0x00010000 to 0x000c3fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 25792 bytes to 14356...
Wrote 25792 bytes (14356 compressed) at 0x00000000 in 0.3 seconds (effective 619.6 kbit/s)...
Hash of data verified.
Compressed 735872 bytes to 447764...
Wrote 735872 bytes (447764 compressed) at 0x00010000 in 5.4 seconds (effective 1098.0 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 105...
Wrote 3072 bytes (105 compressed) at 0x00008000 in 0.0 seconds (effective 541.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Here is my route table (note the seeming lack of a link):

Code: Select all

ot-ctl router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     | Link |
+----+--------+----------+-----------+-------+--------+-----+------------------+------+
| 12 | 0x3000 |       57 |         1 |     3 |      2 |   3 | 0a80ee8e1562fa9a |    1 |
| 46 | 0xb800 |       63 |         0 |     0 |      0 |   0 | 0000000000000000 |    0 |
| 48 | 0xc000 |       57 |         1 |     0 |      0 |   5 | 02431ea512031841 |    0 |
| 57 | 0xe400 |       12 |         1 |     3 |      3 |  12 | 1233e35052d418e1 |    1 |

The nodes are setup such that 03b0 - can only reach fa9a and 18e1 - and such that 1841 can only reach fa9a.

Here is the output of this command:

Code: Select all

 ot-ctl netdata show
Prefixes:
fdec:df03:fade:1::/64 paos low b800
Routes:
fc00::/7 sa med b800
Services:
44970 01 0a000500000e10 s b800
44970 5d fd000db800a0000096c8c6f93523b384d11f s b800
Contexts:
fdec:df03:fade:1::/64 1 c
Commissioning:
12277 - - -
Done

Neighbors:

Code: Select all

 ot-ctl neighbor table
| Role | RLOC16 | Age | Avg RSSI | Last RSSI |R|D|N| Extended MAC     | Version |
+------+--------+-----+----------+-----------+-+-+-+------------------+---------+
|   R  | 0x3000 |   4 |      -79 |       -79 |1|1|1| 0a80ee8e1562fa9a |       4 |
|   R  | 0xe400 |  17 |      -36 |       -36 |1|1|1| 1233e35052d418e1 |       4 |

Any guidance would be greatly appreciated. Seems like its something seemingly fundamental.

[mamacker]

Also of note - I created a ot_cli node that I placed in the middle of the network - what is interesting. Is that my border node - can ping the cli but cannot ping the node on the opposite side of the cli node.

But the cli node can ping in both directions - as its directly connected to both sides.

What I can't do is ping from one side of the mesh to the other.

So its as if no mesh-forwarding is occuring - when I would have expected that to work out of the box.

Any help would be greatly appreciated.

[mamacker]

I believe my situation may be caused by trusting the Nordic dongle I was using to explore the fabric. It would appear the Nordic is not compatible.

By A) realizing I can't use the link address and B) exploring the fabric using the CLI of an esp32 I was able to prove I could explore multi hop comms.

Soooo the moral of the story. Don't use the Nordic dongle.