examples/gnrc_border_router: esp_wifi crashes on disconnect #14679
Comments
benpicco
added
Platform: ESP
|
Since the 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(); |
This also speaks for |
This indicates that MAC layer buffer is running out of memory for any reason. Therefore, the status is reset to
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. |
Indeed, but the error message The cause Line 75 in 763924b @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. |
|
Unfortunately a second panic happened when it attempted to print that.
I tried that, but it would produce new, unrelated crashes. |
|
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. |
@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 it doens't advertise the prefix although the Even if I set also the global unicast address manually for the 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 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. |
|
@miri64 Do you have any idea what the reason could be why Router Solicitation messages from the 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 Router Solicitation sent by the ESP-NOW nodeReaction of the border router on Router Solicitation on on ESP-NOW interfaceReaction of the ESP-NOW node on Neighbor Solicitation |
|
Mh... my first thought was that maybe something is wrong with multicast on For the following analysis I assume, For the router solicitation it looks like the receiving node is just not configured to send router advertisements (is the |
You interpret them correctly. Although
Exactly, since you introduced the distinction between the so-called
This is what I thought too.
How can I figure out whether it is compiled in? It is activated by default and On the |
|
Just to be sure, I set the global unicast address |
Then it should be compiled in. Curious however, that the AR state is also printed ( |
|
For the border router, I just use @benpicco's example with RPL compiled in and on |
I hope I'm not waking any sleeping dogs, but
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. |
They don't use the same addresses as IEEE 802.15.4 though. But if we assume that the 48-bit addresses of |
Declaring The initial discussion whether But yes, the 48-bit address of |
Ok, if we suppose |
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. |
aabadie
added
Area: network
|
ping? |
Description
When operating as a border router with an
esp_nowclient, 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 RIOT-OS/Release-Specs#185:
flash the border router
flash the
esp_nowclientIt 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.
0x40228c38points tocore/mutex.c:75which is not very enlightening.Versions
RIOT master
The text was updated successfully, but these errors were encountered: