IPv6 packet causes exception #133
Comments
|
When an exception like this is encountered, we can use gdb to determine where the exception occurred. I believe you are with Cesanta ... I am extremely interested in getting Mongoose supported on ESP32. If it would be useful, I will be delighted to partner with you ... you with your Cesanta code skills and me with some useful ESP32 skills. You can reach me on ESP32 IRC (kolban) or Skype at "neil.kolban". |
|
yes, this is my first foray into ESP32 programming. i'm already setting up JTAG debug probe, a bit sooner than i expected :) |
|
If you have trouble with JTAG, you can actually use gdb on your PC to examine the details of what failed through the serial port. Again, if you can use me, please do. I find that when approaching any new environment, I like to find folks who may have walked some of the path in the past that can offer tips on how to proceed. |
|
in this case the problem is that we don't have useful PC to work with. |
|
If needed, I can load your code on my PC ... via a screen share. Where are you compiling source? |
|
On the manufacturer's forum for my board, I stumbled upon this. If my laptop or my phone does a DHCP request, the board panics every time, which explains the regularity of the crashes and why it only happens when the board is associated with the access point. |
|
Thanks for the reports. I have tried both with the latest master and the one which was available on the day this was originally reported. So far I wasn't able to reproduce this. Just to be sure, could any of you please upload the elf file which demonstrates the issue? From the linked forum issue I got an impression that this may be related to some specific DHCP packet. I wonder if I may ask for a wireshark trace with DHCP packets logged? /cc @abiliojr, I would like to keep discussion of this issue in one thread. |
|
this must be triggered by some traffic, as for example it only repros on the office network for me and not at home. i'll try to correlate it with network activity today. |
|
i ran tcpdump on my |
|
here are some more findings. i went back in time to see if it is a recent regression - it's not. now, there is a minor change i noticed: before 9423390 PC had a different invalid value: register dump at f394632: and at 9423390: i can offer remote access to a machine with ESP32 module connected so you can try to debug it. |
|
@rojer Thanks for the observation. I suppose I need to try a bunch of different routers. |
|
no, increasing fwiw my router model is TP-Link TD-W9980 |
|
I did some tcpdump (during my previous attempt, before finding the thread talking of DHCP requests triggering the problem, I only tried to capture the 802.11 frames and saw some corrupt ones but replaying them didn't produce anything) and by elimination, I was left with only one packet: an ICMPv6 Router Solicitation. I'm not sure it is useful I post the pcap here, as I can simply reproduce the issue with the rdisc6 command (could not compile it under OS X so I installed it on a laptop with Debian as it is available in the main APT repository via the For the record, here is how to use it: rdisc6 "$router_ip6" "$interface"Where ip -6 routeAnd Unfortunately, Hope this helps. |
|
fwiw, this is something i have in common with @ether42 - i also have ipv6 in my network. |
|
Thanks @ether42, I have passed this way of reproducing the issue to the team, we should have a fix shortly. |
|
i have similar issue on my beloved LoPy with ESP32. Changed IPv6 settings on my wifirouter from 6to4-tunnel to Disable and the crash has not happened again. Router Netgear R7000 i do not run any ÎPv6 software. Not a fix but a workaround. |
|
Kudus to @ether42 for the thorough report. Thanks! I can confirm that running FYI, @ether42, I just had a look at rdisc on OS X, and made two fixes to rdisc. I mailed it's author just a minute ago. |
|
|
On Xtensa windowed ABI backtrace is easy to do, and it's immensely useful for debugging, so - do it by default. We try to be careful and not deref bogus pointers while walking the frames. Example output (from debugging espressif#133): Backtrace: 0x1:0x3ffc51e0 0x400e9dfa:0x3ffc5210 0x400e9ebc:0x3ffc5230 0x400ec487:0x3ffc5260 With just addr2line utility from binutils, this already pinpoints the location of the crash.
On Xtensa windowed ABI backtrace is easy to do, and it's immensely useful for debugging, so - do it by default. We try to be careful and not deref bogus pointers while walking the frames. Example output (from debugging espressif#133): Backtrace: 0x1:0x3ffc51e0 0x400e9dfa:0x3ffc5210 0x400e9ebc:0x3ffc5230 0x400ec487:0x3ffc5260 With just addr2line utility from binutils, this already pinpoints the location of the crash.
On Xtensa windowed ABI backtrace is easy to do, and it's immensely useful for debugging, so - do it by default. We try to be careful and not deref bogus pointers while walking the frames. Example output (from debugging espressif#133): Backtrace: 0x1:0x3ffc51e0 0x400e9dfa:0x3ffc5210 0x400e9ebc:0x3ffc5230 0x400ec487:0x3ffc5260 With just addr2line utility from binutils, this already pinpoints the location of the crash.
I'm getting the following exception shortly (a few seconds) after connecting to WiFi:
this is latest master esp-idf + esp-idf-template. i only changed ssid pass and later added a couple debug statements to log system event type and provide heartbeat to give an idea when the crash happens.
this only happens on successful wifi connection - if i specify nonexistent ssid or invalid pass, there's no crash. our office AP is nothing special, ESP8266 works with it just fine.
tried on 2 different devices, so it's not a hardware fault.
let me know if you need any info to help debug this.
The text was updated successfully, but these errors were encountered: