search

RIOT-OS / RIOT

RIOT - The friendly OS for IoT
https://riot-os.org
GNU Lesser General Public License v2.1
4.87k stars 1.98k forks source link

examples/gnrc_border_router: esp_wifi crashes on disconnect #14679

Open benpicco opened 4 years ago

benpicco commented 4 years ago

Description

When operating as a border router with an esp_now client, the border router will crash after a while with what seems like a disconnect event that is not handled correctly.

Steps to reproduce the issue

Follow the steps described in https://github.com/RIOT-OS/Release-Specs/pull/185:

It seems like the client node is crucial for this bug to occur. With the second node disconnected, the border router did not crash.

Expected results

The border router keeps operating continuously.

Actual results

After a while (~10 Minutes) the border router crashes and reboots.

2020-08-02 20:40:50,865 # scandone
2020-08-02 20:41:00,866 # scandone
2020-08-02 20:41:10,868 # scandone
2020-08-02 20:41:14,377 # LmacRxBlk:0
2020-08-02 20:41:15,378 # LmacRxBlk:0
2020-08-02 20:41:16,379 # LmacRxBlk:0
2020-08-02 20:41:17,380 # LmacRxBlk:0
2020-08-02 20:41:18,381 # LmacRxBlk:0
2020-08-02 20:41:19,162 # bcn_timout,ap_probe_send_start
2020-08-02 20:41:19,382 # LmacRxBlk:0
2020-08-02 20:41:20,383 # LmacRxBlk:0
2020-08-02 20:41:21,384 # LmacRxBlk:0
2020-08-02 20:41:21,666 # ap_probe_send_over, rest wifi status to disassoc
2020-08-02 20:41:21,669 # state: 5 -> 0 (100)
2020-08-02 20:41:21,669 # rm 0
2020-08-02 20:41:21,675 # WiFi disconnected from ssid beersperminute, reason 200 (BEACON_TIMEOUT)
2020-08-02 20:41:21,770 # EXCEPTION!! exccause=9 (LoadStoreAlignmentCause) @40228c38 excvaddr=40249fbb
2020-08-02 20:41:21,771 # processes:
2020-08-02 20:41:21,779 #   pid | name                 | state    Q | pri | stack  ( used) ( free) | base addr  | current     
2020-08-02 20:41:21,787 #     - | isr_stack            | -        - |   - |   2048 ( 1092) (  956) | 0x3ffe8410 | 0x3ffe8c10
2020-08-02 20:41:21,798 #     1 | ppT                  | bl rx    _ |   2 |   3640 ( 1320) ( 2320) | 0x3fff7480 | 0x3fff8150 
2020-08-02 20:41:21,806 #     2 | pmT                  | bl rx    _ |   4 |   1080 (  328) (  752) | 0x3fff8300 | 0x3fff8600 
2020-08-02 20:41:21,814 #     3 | rtT                  | bl mutex _ |   3 |   2104 ( 1356) (  748) | 0x3fff8740 | 0x3fff8e80 
2020-08-02 20:41:21,823 #     4 | esp_events           | bl rx    _ |   5 |   2104 (  892) ( 1212) | 0x3fff95b0 | 0x3fff9c80 
2020-08-02 20:41:21,831 #     5 | idle                 | pending  Q |  31 |   1024 (  236) (  788) | 0x3ffef18c | 0x3ffef4b0 
2020-08-02 20:41:21,839 #     6 | main                 | bl mutex _ |  15 |   3072 ( 1484) ( 1588) | 0x3ffef58c | 0x3ffeff40 
2020-08-02 20:41:21,848 #     7 | 6lo                  | pending  Q |  11 |   1024 (  568) (  456) | 0x3fff2d38 | 0x3fff2f30 
2020-08-02 20:41:21,856 #     8 | ipv6                 | pending  Q |  12 |   1536 (  800) (  736) | 0x3fff05d0 | 0x3fff0980 
2020-08-02 20:41:21,865 #     9 | udp                  | bl rx    _ |  13 |   1024 (  492) (  532) | 0x3fff351c | 0x3fff3790 
2020-08-02 20:41:21,873 #    10 | netif-esp-now        | running  Q |  10 |   2560 (  948) ( 1612) | 0x3fff4124 | 0x3fff4930 
2020-08-02 20:41:21,881 #    11 | netif-esp-wifi       | bl rx    _ |   9 |   1024 (  932) (   92) | 0x3fff4cf4 | 0x3fff4f40 
2020-08-02 20:41:21,892 #    12 | dhcpv6-client        | bl anyfl _ |  13 |   1024 (  800) (  224) | 0x3fff01cc | 0x3fff04a0 
2020-08-02 20:41:21,898 #       | SUM                  |            |     |  23264 (11248) (12016)
2020-08-02 20:41:21,898 # 
2020-08-02 20:41:21,900 # *** RIOT kernel panic:
2020-08-02 20:41:21,901 # FAILED ASSERTION.
2020-08-02 20:41:21,901 # 
2020-08-02 20:41:21,909 #   pid | name                 | state    Q | pri | stack  ( used) ( free) | base addr  | current     
2020-08-02 20:41:21,917 #     - | isr_stack            | -        - |   - |   2048 ( 1236) (  812) | 0x3ffe8410 | 0x3ffe8c10
2020-08-02 20:41:21,926 #     1 | ppT                  | bl rx    _ |   2 |   3640 ( 1320) ( 2320) | 0x3fff7480 | 0x3fff8150 
2020-08-02 20:41:21,937 #     2 | pmT                  | bl rx    _ |   4 |   1080 (  328) (  752) | 0x3fff8300 | 0x3fff8600 
2020-08-02 20:41:21,945 #     3 | rtT                  | bl mutex _ |   3 |   2104 ( 1356) (  748) | 0x3fff8740 | 0x3fff8e80 
2020-08-02 20:41:21,953 #     4 | esp_events           | bl rx    _ |   5 |   2104 (  892) ( 1212) | 0x3fff95b0 | 0x3fff9c80 
2020-08-02 20:41:21,962 #     5 | idle                 | pending  Q |  31 |   1024 (  236) (  788) | 0x3ffef18c | 0x3ffef4b0 
2020-08-02 20:41:21,970 #     6 | main                 | bl mutex _ |  15 |   3072 ( 1484) ( 1588) | 0x3ffef58c | 0x3ffeff40 
2020-08-02 20:41:21,978 #     7 | 6lo                  | pending  Q |  11 |   1024 (  568) (  456) | 0x3fff2d38 | 0x3fff2f30 
2020-08-02 20:41:21,987 #     8 | ipv6                 | pending  Q |  12 |   1536 (  800) (  736) | 0x3fff05d0 | 0x3fff0980 
2020-08-02 20:41:21,995 #     9 | udp                  | bl rx    _ |  13 |   1024 (  492) (  532) | 0x3fff351c | 0x3fff3790 
2020-08-02 20:41:22,004 #    10 | netif-esp-now        | running  Q |  10 |   2560 (  948) ( 1612) | 0x3fff4124 | 0x3fff4930 
2020-08-02 20:41:22,012 #    11 | netif-esp-wifi       | bl rx    _ |   9 |   1024 (  932) (   92) | 0x3fff4cf4 | 0x3fff4f40 
2020-08-02 20:41:22,020 #    12 | dhcpv6-client        | bl anyfl _ |  13 |   1024 (  800) (  224) | 0x3fff01cc | 0x3fff04a0 
2020-08-02 20:41:22,029 #       | SUM                  |            |     |  23264 (11392) (11872)
2020-08-02 20:41:22,029 # 
2020-08-02 20:41:22,030 # *** halted.

0x40228c38 points to core/mutex.c:75 which is not very enlightening.

Versions

RIOT master

miri64 commented 4 years ago

Since the netif-esp-now thread is the running thread it is most likely the culprit. I usually use a patch like this to dig deeper:

diff --git a/core/include/mutex.h b/core/include/mutex.h
index 24129f8929..ff7dcca1f7 100644
--- a/core/include/mutex.h
+++ b/core/include/mutex.h
@@ -123,7 +123,12 @@ static inline void mutex_lock(mutex_t *mutex)
  *
  * @param[in] mutex Mutex object to unlock, must not be NULL.
  */
-void mutex_unlock(mutex_t *mutex);
+void _mutex_unlock(mutex_t *mutex);
+
+#include <stdio.h>
+#define mutex_unlock(mutex) \
+    printf("%s:%d: unlock %p\n", __FILE__, __LINE__, (void *)mutex); \
+    _mutex_unlock(mutex);

 /**
  * @brief Unlocks the mutex and sends the current thread to sleep
diff --git a/core/mutex.c b/core/mutex.c
index 0a52e72a9b..2412155e5f 100644
--- a/core/mutex.c
+++ b/core/mutex.c
@@ -70,7 +70,7 @@ int _mutex_lock(mutex_t *mutex, volatile uint8_t *blocking)
     }
 }

-void mutex_unlock(mutex_t *mutex)
+void _mutex_unlock(mutex_t *mutex)
 {
     unsigned irqstate = irq_disable();
miri64 commented 4 years ago

It seems like the client node is crucial for this bug to occur. With the second node disconnected, the border router did not crash.

This also speaks for esp_now :-/

gschorcht commented 4 years ago

2020-08-02 20:41:10,868 # scandone 2020-08-02 20:41:14,377 # LmacRxBlk:0 2020-08-02 20:41:15,378 # LmacRxBlk:0 2020-08-02 20:41:16,379 # LmacRxBlk:0 2020-08-02 20:41:17,380 # LmacRxBlk:0 2020-08-02 20:41:18,381 # LmacRxBlk:0 2020-08-02 20:41:19,162 # bcn_timout,ap_probe_send_start 2020-08-02 20:41:19,382 # LmacRxBlk:0 2020-08-02 20:41:20,383 # LmacRxBlk:0 2020-08-02 20:41:21,384 # LmacRxBlk:0

This indicates that MAC layer buffer is running out of memory for any reason. Therefore, the status is reset to disassociated and it gets a beacon timeout afterwards.

2020-08-02 20:41:21,666 # ap_probe_send_over, rest wifi status to disassoc 2020-08-02 20:41:21,669 # state: 5 -> 0 (100) 2020-08-02 20:41:21,669 # rm 0 2020-08-02 20:41:21,675 # WiFi disconnected from ssid beersperminute, reason 200 (BEACON_TIMEOUT)

I have seen this already sporadically. Unfortunatly I wasn't able to figure out the reason because it is something that happens deep inside closed and completely undocumented code of ESP8266 libraries and the OCD capabilities are pretty poor for ESP8266.

gschorcht commented 4 years ago

Since the netif-esp-now thread is the running thread it is most likely the culprit.

Indeed, but the error message LmacRxBlk:0 might indicate the initial problem. esp-now and esp-wifi are using the same WiFi interface.

The cause LoadStoreAlignment usually means that an attempt is made to access the memory at an address that is not 32-bit-word-aligned in a memory segment that supports only 32-bit-word-aligned access. But, there is nothing in core/mutex.c:75 https://github.com/RIOT-OS/RIOT/blob/763924bcaa71a5af91b4a2cb9c55369e16b86981/core/mutex.c#L75 that could cause an unaligned access. So, I would guess the exception happens at another place.

@benpicco The output of the register set could be helpful here. Normally, it should be in the output of the exception handling like the process listing.

benpicco commented 4 years ago

Unfortunately a second panic happened when it attempted to print that. Can the esp8266 be debugged with a J-Link device?

Since the netif-esp-now thread is the running thread it is most likely the culprit. I usually use a patch like this to dig deeper:

I tried that, but it would produce new, unrelated crashes.

gschorcht commented 4 years ago

Theoretically yes, see here. But it doesn't work reliable. After having it working 2 or 3 times two years ago, I wasn't able to get it working anymore. I was using the ICprog OpenOCD JTAG Adapter. Maybe, it works more reliable with a J-Link device.

Unfortunately I can't support you for the next three days because I have exams all day and don't have the hardware at hand.

gschorcht commented 4 years ago

Can the esp8266 be debugged with a J-Link device?

@benpicco I have a working OpenOCD with a J-Link adapter, but I can't set up the appropriate test environment because my Speedport router doesn't support prefix delegation.

Even if I set a global unicast address manually for the esp_now interface of the border router with

ifconfig 10 add 2001:db8::1/64

it doens't advertise the prefix although the esp_now client node sends router solicitations and the RTR_ADV attribute is set.

> ifconfig 10
Iface  10  HWaddr: 5E:CF:7F:80:3F:08  Channel: 8 
          L2-PDU:249  MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  Source address length: 6
          Link type: wireless
          inet6 addr: fe80::5ccf:7fff:fe80:3f08  scope: link  VAL
          inet6 addr: 2001:db8::1  scope: global  VAL
          ...

Even if I set also the global unicast address manually for the esp_now client node, it doesn't work.

ifconfig 11 add 2001:db8::2/64

Both nodes then have the corresponding route entry in the NIB, but can't reach each other via this global unicast address. After a short look with airmon-ng it seems that both nodes send a Neighbor Solicitation for the respective global unicast address. The initiating node sends a Neighbor Solicitation, but doesn't get a reply. Instead, the solicited node itself sends a Neighbor Solicitation and doesn't get a reply.

I don't know what I am doing wrong now. Due to lack of time I was not able to look at it in more detail. So I can't reproduce the problem to try to debug it.

gschorcht commented 4 years ago

@miri64 Do you have any idea what the reason could be why Router Solicitation messages from the esp_now node are not answered by the border router? Perhaps it is the same reason why Neighbor Discovery does not work on the esp_now link. A Neighbor Solicitation message is answered by the solicited node with a Neighbor Solicitation message for the initiating node.

Because of the traffic and the resulting large number of debugging messages for the WiFi interface of the border router, I have only the debugging output on the esp_now node for the Neighbor Discovery at hand:

Router Solicitation sent by the ESP-NOW node ``` ipv6: NIB timer event received nib: Handle timer event (ctx = 0x3fff3a84, type = 0x4fc3, now = 80616ms) icmpv6: Building ICMPv6 message with type=133, code=0 ipv6: waiting for incoming message. ipv6: GNRC_NETAPI_MSG_TYPE_SND received ipv6: set payload length to 16 (network byteorder 1000) ipv6: set next header to 58 ipv6: write protect up to payload to calculate checksum ipv6: calculate checksum for upper header. ipv6: send multicast over interface 11 ipv6: Sending (src = fe80::18fe:34ff:fee5:ef04, dst = ff02::2, next header = 58, length = 16) ipv6: send to 6LoWPAN instead _send: 0x3fff4670 0x3fff44b0 _send: send 58 byte 00000000 01 41 60 00 00 00 00 10 3A FF FE 80 00 00 00 00 00000010 00 00 18 FE 34 FF FE E5 EF 04 FF 02 00 00 00 00 00000020 00 00 00 00 00 00 00 00 00 02 85 00 01 5E 00 00 00000030 00 00 01 01 1A FE 34 E5 EF 04 _send: send esp_now broadcast esp_now_send_cb: sent to 5e:cf:7f:80:3f:08 with status 0 ipv6: waiting for incoming message. ```
Reaction of the border router on Router Solicitation on on ESP-NOW interface ``` _recv: 0x3fff4ca8 0x0 0 0x0 _recv: 0x3fff4ca8 0x3fff16ac 64 0x0 _recv: received 58 byte from 1a:fe:34:e5:ef:04 00000000 01 41 60 00 00 00 00 10 3A FF FE 80 00 00 00 00 00000010 00 00 18 FE 34 FF FE E5 EF 04 FF 02 00 00 00 00 00000020 00 00 00 00 00 00 00 00 00 02 85 00 01 5E 00 00 00000030 00 00 01 01 1A FE 34 E5 EF 04 ipv6: GNRC_NETAPI_MSG_TYPE_RCV received ipv6: Received (src = fe80::18fe:34ff:fee5:ef04, dst = ff02::2, next header = 58, length = 16) ipv6: forward nh = 58 to other threads ipv6: handle ICMPv6 packet (nh = 58) icmpv6: NDP message received. Handle with gnrc_ipv6_nib nib: Handle packet (icmpv6->type = 133) nib: Received valid router solicitation: - Source address: fe80::18fe:34ff:fee5:ef04 - Destination address: ff02::2 icmpv6: no one interested in type 133 ipv6: waiting for incoming message. ```
Reaction of the ESP-NOW node on Neighbor Solicitation ``` _recv: 0x3fff4670 0x0 0 0x0 _recv: 0x3fff4670 0x3fff0ccc 80 0x0 _recv: received 74 byte from 5e:cf:7f:80:3f:08 00000000 01 41 60 00 00 00 00 20 3A FF 20 01 0D B8 00 00 00000010 00 00 00 00 00 00 00 00 00 01 FF 02 00 00 00 00 00000020 00 00 00 00 00 01 FF 00 00 02 87 00 00 D0 00 00 00000030 00 00 20 01 0D B8 00 00 00 00 00 00 00 00 00 00 00000040 00 02 01 01 5E CF 7F 80 3F 08 ipv6: GNRC_NETAPI_MSG_TYPE_RCV received ipv6: Received (src = 2001:db8::1, dst = ff02::1:ff00:2, next header = 58, length = 32) ipv6: forward nh = 58 to other threads ipv6: handle ICMPv6 packet (nh = 58) icmpv6: NDP message received. Handle with gnrc_ipv6_nib nib: Handle packet (icmpv6->type = 135) nib: Received valid neighbor solicitation: - Target address: 2001:db8::2 - Source address: 2001:db8::1 - Destination address: ff02::1:ff00:2 nib: Storing SL2AO for later handling icmpv6: Building ICMPv6 message with type=136, code=0 icmpv6: no one interested in type 135 ipv6: waiting for incoming message. ipv6: GNRC_NETAPI_MSG_TYPE_SND received ipv6: send unicast nib: get next hop link-layer address of 2001:db8::1%11 nib: 2001:db8::1 is off-link, resolve route nib: no route to 2001:db8::1 found or is prefix list entry, search neighbor cache nib: prefix list entry => taking dst as next hop nib: resolve address 2001:db8::1 by probing neighbors icmpv6: Building ICMPv6 message with type=135, code=0 ipv6: no link-layer address or interface for next hop to 2001:db8::1 ipv6: waiting for incoming message. ipv6: GNRC_NETAPI_MSG_TYPE_SND received ipv6: set payload length to 32 (network byteorder 2000) ipv6: set next header to 58 ipv6: write protect up to payload to calculate checksum ipv6: calculate checksum for upper header. ipv6: send multicast over interface 11 ipv6: Sending (src = 2001:db8::2, dst = ff02::1:ff00:1, next header = 58, length = 32) ipv6: send to 6LoWPAN instead _send: 0x3fff4670 0x3fff44b0 _send: send 74 byte 00000000 01 41 60 00 00 00 00 20 3A FF 20 01 0D B8 00 00 00000010 00 00 00 00 00 00 00 00 00 02 FF 02 00 00 00 00 00000020 00 00 00 00 00 01 FF 00 00 01 87 00 DF 40 00 00 00000030 00 00 20 01 0D B8 00 00 00 00 00 00 00 00 00 00 00000040 00 01 01 01 1A FE 34 E5 EF 04 _send: send esp_now broadcast esp_now_send_cb: sent to 5e:cf:7f:80:3f:08 with status 0 ipv6: waiting for incoming message. ```
miri64 commented 4 years ago

Mh... my first thought was that maybe something is wrong with multicast on esp_now, but your logs don't agree with that if I interpret them correctly.

For the following analysis I assume, esp_now is not using 6Lo-ND, as I remember that we decided that in the past.

For the router solicitation it looks like the receiving node is just not configured to send router advertisements (is the RTR_ADV bit set?), for the neighbor solicitation the receiving node seems to try to also start a neighbor solicitation process, this shouldn't happen however as the received neighbor solicitation should create a STALE neighbor cache entry. Is the address-resolution state-machine of the NIB compiled in?

gschorcht commented 4 years ago

Mh... my first thought was that maybe something is wrong with multicast on esp_now, but your logs don't agree with that if I interpret them correctly.

You interpret them correctly. Although esp_now does not support MAC multicast but only MAC broadcast, IPv6 multicast works because IPv6 multicast packets are always sent via MAC Broadcast. For example, the Router Solicitation message which is sent by the esp_now node with MAC address 1a:fe:34:e5:ef:04 to the all-router multicast address ff02::2 is received by the border router. ND also works for link local addresses.

For the following analysis I assume, esp_now is not using 6Lo-ND, as I remember that we decided that in the past.

Exactly, since you introduced the distinction between the so-called 6LN nodes, which use 6Lo-ND, and the so-called 6Lo nodes, which use 6Lo only for fragmentation, esp_now no longer uses 6Lo-ND. If I remember correctly, the reason why esp_now can't use 6Lo-ND is the lack of a real EUI, but I don't remember exactly.

For the router solicitation it looks like the receiving node is just not configured to send router advertisements (is the RTR_ADV bit set?),

RTR_ADV seems to be set, at least according to the output for the esp_now interface on the border router:

> ifconfig 10
Iface  10  HWaddr: 5E:CF:7F:80:3F:08  Channel: 8 
          L2-PDU:249  MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  Source address length: 6
          Link type: wireless
          inet6 addr: fe80::5ccf:7fff:fe80:3f08  scope: link  VAL
          inet6 addr: 2001:db8::1  scope: global  VAL

for the neighbor solicitation the receiving node seems to try to also start a neighbor solicitation process, this shouldn't happen however

This is what I thought too.

as the received neighbor solicitation should create a STALE neighbor cache entry. Is the address-resolution state-machine of the NIB compiled in?

How can I figure out whether it is compiled in? It is activated by default and info-debug-variable-CLFAGS doesn't contain a setting for it. On the border router it seems to be compiled in, at least I get an output for the WiFi interface:

> nib neigh
fe80::1 dev #11 lladdr 20:A6:80:56:A4:7B router STALE GC

On the esp_now node the nib neigh command gives no results.

gschorcht commented 4 years ago

Just to be sure, I set the global unicast address 2001:db8::1/64 manually since my Speedport Router doesn't support prefix delegation.

miri64 commented 4 years ago

How can I figure out whether it is compiled in? It is activated by default and info-debug-variable-CLFAGS doesn't contain a setting for it. On the border router it seems to be compiled in, at least I get an output for the WiFi interface:

> nib neigh
fe80::1 dev #11 lladdr 20:A6:80:56:A4:7B router STALE GC

On the esp_now node the nib neigh command gives no results.

Then it should be compiled in. Curious however, that the AR state is also printed (GC == garbarge-collectible, so a "normal" NC entry, not one used for address registration according to 6Lo-ND). Since you are not using 6Lo-ND, it shouldn't be there. Is maybe some conflict between a compiled-in 6LN NIB config but acting as a non-6LN causing the problem :thinking:?

gschorcht commented 4 years ago

For the border router, I just use @benpicco's example with RPL compiled in

USEMODULE='gnrc_rpl' make -C examples/gnrc_border_router BOARD=esp8266-esp-12x UPLINK=wifi WIFI_SSID='...' WIFI_PASS='...' flash

and on esp-now node

CFLAGS='-DESP_NOW_CHANNEL=8' make -C examples/gnrc_networking BOARD=esp8266-esp-12x flash
benpicco commented 4 years ago

For the following analysis I assume, esp_now is not using 6Lo-ND, as I remember that we decided that in the past. […] esp_now no longer uses 6Lo-ND.

I hope I'm not waking any sleeping dogs, but esp_now is marked as GNRC_NETIF_FLAGS_6LN

If I remember correctly, the reason why esp_now can't use 6Lo-ND is the lack of a real EUI,

That would be a very weak argument. Our 802.15.4 radios don't use a "real EUI" either, the use one generated by luid too.

miri64 commented 4 years ago

Our 802.15.4 radios don't use a "real EUI" either, the use one generated by luid too.

They don't use the same addresses as IEEE 802.15.4 though. But if we assume that the 48-bit addresses of esp_now are unique as we do with the the luid-based EUI-64s we could indeed use them to generate an EUI-64 as we do for Ethernet.

gschorcht commented 4 years ago

They don't use the same addresses as IEEE 802.15.4 though. But if we assume that the 48-bit addresses of esp_now are unique as we do with the the luid-based EUI-64s we could indeed use them to generate an EUI-64 as we do for Ethernet.

Declaring esp_now as 6LN node was introduced with PR #13561. At that time, we had a discussion after the PR was already merged whether esp_now could be considered as a 6LN node (https://github.com/RIOT-OS/RIOT/pull/13561#issuecomment-595276512). If I'm right, this discussion ended without result.

The initial discussion whether esp_now could act as a 6LN and use 6Lo-ND, multihop prefix dissemination a.s.o. started in PR #10524 with https://github.com/RIOT-OS/RIOT/pull/10524#issuecomment-451620006 when esp_now was not working in border router any more. As I remember, issue #10723 and PR #10817 were results of this discussion.

But yes, the 48-bit address of esp-now is a MAC address and therefore unique.

gschorcht commented 4 years ago

I hope I'm not waking any sleeping dogs, but esp_now is marked as GNRC_NETIF_FLAGS_6LN

Ok, if we suppose esp_now to act as a 6LN node, would that explain why Router Solicitation is not answered because 6Lo-ND is used for prefixes dissemination? As I remember, DHCPv6 is used in @benpicco's test environment to get the prefix on esp_now nodes.

miri64 commented 4 years ago

As I remember, DHCPv6 is used in @benpicco's test environment to get the prefix on esp_now nodes.

DHCPv6 is only used to configure the 6LoWPAN border router's (6LBR's) prefix, for the WPAN's nodes prefix dissemation is used. A node configured as 6LoWPAN router (6LR) only starts sending router advertisements—i.e. replying to router solicitations—when it itself has its prefix configured (i.e. received a router advertisement from an upstream router or in the 6LBR's case got the prefix configured). A non-6LR 6LN (6LoWPAN node) does reply to router solicitations as it is not a router.

maribu commented 1 year ago

ping?