[ESP-WIFI-MESH] esp_mesh_recv received wrong device when series of MAC ID's into Mesh network. (IDFGH-12904)

[andy-danieal]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

When I added two series of custom MAC devices to Mesh network. For example, D1 -> 60:55:f9:e7:5e:56 and D2 -> 60:55:f9:e7:5e:57 was connected to Gateway with ESP-WIFI-MESH. And D1 is the parent of D2, the issue occurs. During that time, Gateway sent data to D2, but D1 received it.

ESP IDF Version:- ESP-IDF v5.2.1-533-g9f4f8e24f

Gateway Logs

W (00:25:32.371) [APP]: [SYSTEM INFO]: HEAP: 23 MESH-DEVICES - 3
W (00:25:15.054) [APP]: ================================
||     0 | a0:76:4e:8c:ff:1c |  7423 ||
||     1 | 60:55:f9:e7:5e:57 | 22366 ||
||     2 | 60:55:f9:e7:5e:56 | 22110 ||
W (00:25:15.065) [APP]: ================================

D1 Device Logs

I (01:51:55.976) [PACKET]: Send command to gateway :- a0:76:4e:8c:ff:1d
W (01:51:56.404) [MESH-EVENT]: GOT MESSAGE FROM NODE a0:76:4e:8c:ff:1c Device: 60:55:f9:e7:5e:56
I (01:51:56.424) [PACKET]: Send command to gateway :- a0:76:4e:8c:ff:1d
W (01:51:58.554) [MESH-EVENT]: GOT MESSAGE FROM NODE a0:76:4e:8c:ff:1c Data:60:55:f9:e7:5e:57
I (01:52:31.852) [APP]: [SYSTEM INFO]: HEAP: 42 MESH-DEVICES - 3 | Parent ID: a0:76:4e:8c:ff:1d
              0 | 60:55:f9:e7:5e:56 | 22110 ||

D2 Device Logs

I (01:54:01.838) [APP]: [SYSTEM INFO]: HEAP: 42 MESH-DEVICES - 3 | Parent ID: a0:76:4e:8c:ff:1d
              0 | 60:55:f9:e7:5e:57 | 22366 ||
              1 | 60:55:f9:e7:5e:56 | 22110 ||

[zhangyanjiaoesp]

@andy-danieal
Please check the mac address of the station interface and softAP interface according to the mac address doc

[andy-danieal]

I'm aware of that, but I'm interested in a better solution without changing serial mac IDs.

@zhangyanjiaoesp, Also curious as to why this impacts the SoftAP MAC ID, since ESP-MESH works with Station MAC ID.

[zhangyanjiaoesp]

@andy-danieal Each mesh node (except the leaf node) opens the station and softAP interface. If the station mac is 60:55:f9:e7:5e:56, the the softap mac is 60:55:f9:e7:5e:57 for D1, when gateway send data to 60:55:f9:e7:5e:57 , D1 will receive it.

[andy-danieal]

I have update only STA MAC ID as custom MAC. but at time esp_mesh not working with D2 device.

esp_iface_mac_addr_set(customMacAddr, ESP_MAC_WIFI_STA);

Mesh logs

I (730257) mesh: 1307[recv]cidx[0]60:55:f9:e7:5e:57 xseqno loss, current/new:99/20, in:99, out:99, pending:0
W (730257) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[20], len:168, seqno:20[rx-wnd:10]<>
E (730274) mesh: [mesh_schedule.c,1715] pandora

I (730278) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:20, ttl:28, opt:-1>, pending:0, err:0x4014
W (730846) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[21], len:168, seqno:21[rx-wnd:9]<>
E (730853) mesh: [mesh_schedule.c,1715] pandora

I (730858) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:21, ttl:28, opt:-1>, pending:0, err:0x4014
W (00:12:10.389) [APP]: [SYSTEM INFO]: HEAP: 27 MESH-DEVICES - 5
W (738299) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[22], len:168, seqno:22[rx-wnd:8]<>
E (738307) mesh: [mesh_schedule.c,1715] pandora

I (738311) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:22, ttl:28, opt:-1>, pending:0, err:0x4014
W (738789) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[23], len:168, seqno:23[rx-wnd:7]<>
E (738797) mesh: [mesh_schedule.c,1715] pandora

I (738801) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:23, ttl:28, opt:-1>, pending:0, err:0x4014
W (739169) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[24], len:168, seqno:24[rx-wnd:6]<>
E (739177) mesh: [mesh_schedule.c,1715] pandora

I (739181) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:24, ttl:28, opt:-1>, pending:0, err:0x4014
W (739609) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[25], len:168, seqno:25[rx-wnd:5]<>
E (739617) mesh: [mesh_schedule.c,1715] pandora

I (739621) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:25, ttl:28, opt:-1>, pending:0, err:0x4014
W (740039) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[26], len:168, seqno:26[rx-wnd:4]<>
E (740046) mesh: [mesh_schedule.c,1715] pandora

I (740051) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:26, ttl:28, opt:-1>, pending:0, err:0x4014
W (740449) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[27], len:168, seqno:27[rx-wnd:3]<>
E (740456) mesh: [mesh_schedule.c,1715] pandora

I (740461) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:27, ttl:28, opt:-1>, pending:0, err:0x4014
W (740879) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[28], len:168, seqno:28[rx-wnd:2]<>
E (740887) mesh: [mesh_schedule.c,1715] pandora

I (740891) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:28, ttl:28, opt:-1>, pending:0, err:0x4014
W (741299) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:99, xonseq.in[99] >= the asked xseqno[29], len:168, seqno:29[rx-wnd:1]<>
E (741307) mesh: [mesh_schedule.c,1715] pandora

I (741311) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:29, ttl:28, opt:-1>, pending:0, err:0x4014
I (741679) mesh: 1093[xrsp]wnd:15, the asked:30 <= xseqno_in:99, child 60:55:f9:e7:5e:57, xrsp_seqno:5
I (741680) mesh: 1145[xrsp:1]the asked:30, max window:15, force to increase/decrease(up) xseqno:1 for child 60:55:f9:e7:5e:57, xrsp_seqno:5, heap:19636
-------
W (00:12:48.489) [MESH-EVENT]: Send Device: 6055f9e75e57 Data: 9 Bytes Status:- 0x0
I (769124) mesh: 1307[recv]cidx[0]60:55:f9:e7:5e:57 xseqno loss, current/new:104/38, in:104, out:104, pending:0
W (769125) mesh: [mesh_schedule.c,1702] esp_mesh_push_to_myself_queue,1943 up increase[cidx:0, 60:55:f9:e7:5e:57]pending:0, xonseq.out:104, xonseq.in[104] >= the asked xseqno[38], len:168, seqno:38[rx-wnd:6]<>
E (769141) mesh: [mesh_schedule.c,1715] pandora

I (769146) mesh: 1184[self]push to self q fail, ifx: AP, child:60:55:f9:e7:5e:57, len:168<hlen:28, xseqno:38, ttl:28, opt:-1>, pending:0, err:0x4014

[zhangyanjiaoesp]

@andy-danieal

1. Please provide your sdkconfig file
2. Please call esp_read_mac() to show the mac address of the station and softap interfaces
3. Does your mesh network like this: getway <-> D1 <-> D2 ?

[andy-danieal]

sdkconfig.txt

Update only STA mac. esp_iface_mac_addr_set(customMacAddr, ESP_MAC_WIFI_STA);

D1 device
STA mac is 60:55:f9:e7:5e:56
AP mac is a0:76:4e:8c:eb:24

D2 device
STA mac is 60:55:f9:e7:5e:57
AP mac is a0:76:4e:8c:eb:48

• Yes, getway <-> D1 <-> D2

[zhangyanjiaoesp]

@andy-danieal
I just set the STA mac to 60:55:f9:e7:5e:56 for D1, and set the STA mac to 60:55:f9:e7:5e:57 for D2. Using the internal_communication example, I can reproduce your problem. If I change the STA mac to 60:55:f9:e7:5e:58 for D2, then D2 can receive data successfully.

The root cause of the aforementioned issue is: In the mesh network, When a node joins the network, such as D2 (STA) connecting to D1 (softAP), D1 can only obtain the STA MAC address of D2. If D1 needs to know the softAP MAC address of D2, it defaults to the four-address rule, where the softAP MAC = STA MAC + 1. Consequently, when a packet is sent to D2, the destination address is set to 60:55:f9:e7:5e:57. The mesh network checks the routing table, and if the address is 60:55:f9:e7:5e:56 or 60:55:f9:e7:5e:57, it assumes the packet is intended for D1. As a result, D2 does not receive the packet.

Therefore, we recommend you don't change the mac address for mesh devices. And for other cases, avoid assigning consecutive MAC addresses to different devices. It is best to follow the four-address rule and ensure there is a gap of at least 4 between the MAC addresses of two devices.