Hi, That's exactly what I've figured out pulling an all-nighter. If I set the IPv4-ACL "Deny UDP src=192.168.254.228:5353 dst=any" (.228 is the OVMS) on the switch for the port my AP hits the network everything works stable. My Vehicle-ID on the Vehicle configuration page is "OVMS". So nothing weird at all... Is there a way to disable mDNS via the shell (I dont need it anyhow)? With you suggesting doing a new build though I guess no? Thanks, Soko @Michael: thx for the tip On 05.07.2023 01:39, Mark Webb-Johnson wrote:
Not sure how reliable that short backtrack is, but here is what it shows:
$ ../a2l ovms3.elf 0x4028128f 0x402823bf Using elf file: ovms3.elf 0x4028128f is in mdns_parse_packet (C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c:2839). 0x402823bf is in _mdns_service_task (C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c:3545). 3540in C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c
So that implies a crash parsing a MDNS packet.
If that is repeatable, it would be a bug in the ESP IDF for mdns. You could try disabling CONFIG_OVMS_COMP_MDNS in your build and see if that works around the issue. There is also CONFIG_MDNS_TASK_STACK_SIZE and CONFIG_MDNS_MAX_SERVICES which may be related. But that is based on the single backtrace, which may be wrong.
The only other thing I can think of is the MDNS service packets we transmit. What is your vehicle ID? Anything unusual (non-ascii characters, long length, etc)?
Regards, Mark
On 4 Jul 2023, at 6:10 PM, Soko <ovms@soko.cc> wrote:
Hi Mark,
I have the exact bin & elf I'm using (I've compiled it myself back in the day...). I've also found the script you are mentioning, but it seems to be a linux script, I'm on windows. Looking at the script though - educated guessing - it just looks at the address in the ELF file. Opening the ELF file with an hex-editor in windows reveals it ends at 0x0240D5DB.
<vwPxeAnwFzenPgJR.png>
Do I have to translate the address somehow? Or is the a2l script doing more than just looking.
I've also uploaded the bin & elf (http://soko.yourweb.de/ovms3.zip) if you wonna have a quick look.
The backtrace (0x4028128f 0x402823bf) is more or less the only constant numbers I get with each crash. So if they are too short can I add/activate some trace which leads to more info without connecting to a laptop (my old devenv doesn't seem to work anymore, and it was Windows anyhow...)
thx Soko
On 04.07.2023 03:01, Mark Webb-Johnson wrote:
To understand what is going on, you’ll need to get the ELF file for the *exact* build of firmware you are using, and then use the support/a2l script to decode the backtrace addresses to something human readable. If you can’t do this, you could try by letting us know the firmware version you are running, where you got it from (API or Dexters), and provide the backtrace addresses. If you are using standard firmware builds, you can normally find the .elf file by simply change ovms3.bin to ovms3.elf in the download URL.
Alternatively, connect the module over USB to a laptop/workstation running the development build environment and GDB stub running to capture the panic.
The backtrace you show below (0x4028128f 0x402823bf) does not seem to be valid (too short), and probably won’t help much.
Regards, Mark.
On 4 Jul 2023, at 5:41 AM, Soko <ovms@soko.cc> wrote:
Hi guys,
Running happily my OVMS on my VW e-Up since 2020 it drives my crazy since today :(
It restarts roughly every minute with this status afterwards: ------------ Last boot was 28 second(s) ago Time at boot: 2023-07-03 21:25:07 CEST This is reset #1 since last power cycle Detected boot reason: Crash (12/12) Reset reason: Exception/panic (4) Crash counters: 1 total, 0 early
Last crash: LoadProhibited exception on core 0 Registers: PC : 0x4028128f PS : 0x00060d30 A0 : 0x802823c2 A1 : 0x3ffe71d0 A2 : 0x3ffe9f9c A3 : 0x00000000 A4 : 0x00000000 A5 : 0x00000001 A6 : 0x3ffe9fe8 A7 : 0x3ffe71d0 A8 : 0x0000005b A9 : 0xffffffff A10 : 0x00000e10 A11 : 0x0000000e A12 : 0x00000010 A13 : 0x3ffbd3ac A14 : 0x3f84e83c A15 : 0x3ffbd46b SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000004 LBEG : 0x4008b0e9 LEND : 0x4008b11d LCOUNT : 0x00000000 Backtrace: 0x4028128f 0x402823bf ------------
And now the crazy part: It only happens when I'm connected to a specific WiFi/network?!?!
What I've tried so far:
1. Factory Reset (multiple times) 2. Set a static IP address 3. Reconnect all cables and make sure all are snug and tight 4. Brought OVMS closer to the AP (only one, no mesh) 5. Restarted AP 6. Restarted DNS & DHCP Server 7. It even happens when I have no vehicle selected after a factory reset
It gets more crazy: My WiFi is via Unifi/Ubiquity. So I can have multiple SSIDs with the same AP. So all hardware involved is the same...
When I connect to SSID "E3200", which is network 192.168.254.0/24, the exception happens every minute or so. When I connect to SSID "SurfHere" which is network 192.168.179.0/24, everything works fine!
Do you guys have any idea why this is happening?
I've tried to look at logs via Shell and "log level verbose" but nothing shows up. Is there more I can activate to log this issue?
Maybe my hardware is faulty... Where do I get a new OVMS here in Europe/EU/Austria? Do I have to import in from the UK (https://shop.openenergymonitor.com/ovms/)?
thanks heaps in advance, Soko _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev