I also doubt it's related to the hardware version, and as the crash was consistent during the run and over two reboots I also don't think it's an interrupt timing issue. The crash occured on starting server v2 from the events task: I (5287) webserver: CfgInitTicker: step 4: start server v2 for host 'ovms.***ERROR*** A stack overflow in task OVMS Events has been detected. abort() was called at PC 0x4009045c on core 1 0x4009045c: vApplicationStackOverflowHook at /home/balzer/esp/esp-idf/components/esp32/panic.c:669 Backtrace: 0x4009026c:0x3ffbe030 0x40090443:0x3ffbe050 0x4009045c:0x3ffbe070 0x4008cd54:0x3ffbe090 0x4008e734:0x3ffbe0b0 0x4008e6ea:0x01010101 0x4009026c: invoke_abort at /home/balzer/esp/esp-idf/components/esp32/panic.c:669 0x40090443: abort at /home/balzer/esp/esp-idf/components/esp32/panic.c:669 0x4009045c: vApplicationStackOverflowHook at /home/balzer/esp/esp-idf/components/esp32/panic.c:669 0x4008cd54: vTaskSwitchContext at /home/balzer/esp/esp-idf/components/freertos/tasks.c:4840 0x4008e734: _frxt_dispatch at /home/balzer/esp/esp-idf/components/freertos/portasm.S:406 0x4008e6ea: _frxt_int_exit at /home/balzer/esp/esp-idf/components/freertos/portasm.S:206 Rebooting... With 8K stack, the crash disappeared. Maybe we can reduce the stack usage of the server v2 start or move the start to another context, but I think we can afford the extra 1K for the events task. Regards, Michael Am 13.05.2018 um 19:21 schrieb Stephen Casner:
It's hard to see how running on a 3.0 module would affect the stack usage unless some configuration difference caused an activity into the events task that would otherwise have been in a different task. If you're right on the hairy edge, perhaps the timing of an interrupt could be the difference between crash or not, but I think the interrupts switch to a separate stack. If there is some conditional activity that can be invoked either from a higher level function or from a lower level function, then timing of that condition might affect stack usage.
-- Steve
On Sun, 13 May 2018, Michael Balzer wrote:
I just did another setup run to also catch a firmware update screenshot.
I got a stack overflow in the events task when starting the step 4 test (loading vehicle module and server v2). The crash persisted over reboot, so the setup wizard reverted to factory defaults (good to know that works).
This may be because I'm testing on a 3.0 module, but I've just pushed a stack change to 8K just to be sure.
Regards, Michael
Am 13.05.2018 um 17:54 schrieb Michael Balzer:
Pushed.
Strangely enough, during my tests I once had the same effect as you, but with the Cloudflare DNS.
I couldn't reproduce it though.
Please try again.
I also captured screenshots of the process for the user guide -- is that necessary? I took care to add a lot of info to the process itself.
Regards, Michael
Am 13.05.2018 um 16:44 schrieb Michael Balzer:
With the Google/Cloudflare DNS you can finish the setup?
I was hoping we could omit the DNS question now from the setup, as users likely don't know what that is.
I'll add it to step 2 for now, but with a fixed & labeled selection.
Am 13.05.2018 um 16:36 schrieb Michael Balzer:
My boot without a fixed DNS looks like yours with a fixed one:
I (5066) event: sta ip: 192.168.2.109, mask: 255.255.255.0, gw: 192.168.2.1 I (5066) netmanager: Interface priority is st1 (192.168.2.109/255.255.255.0 gateway 192.168.2.1) I (5076) netmanager: Set DNS#0 192.168.2.1 I (5076) netmanager: Set DNS#1 192.168.2.1 I (5076) netmanager: Set DNS#2 0.0.0.0 I (5076) netmanager: WIFI client up (with MODEM down): starting network with WIFI client I (5076) esp32wifi: STA got IP with SSID: WLAN-214677, MAC: 30:ae:a4:37:25:88, IP: 192.168.2.109, mask: 255.255.255.0, gw: 192.168.2.1 I (5076) time: Starting SNTP client I (5076) ovms-server-v2: Status: Network is up, so attempt network connection I (6286) ovms-server-v2: Connection is ovms.dexters-web.de:6867 Test1 I (6286) ovms-server-v2: Status: Connecting... I (6516) ovms-server-v2: Connection successful I (6516) ovms-server-v2: Status: Logging in...
Is your DNS in the router or behind? The IP and masking looks like it's on another net. If it's on another net, is it possible the first query after the wifi connect is blocked or fails due to some firewall delay?
Regards, Michael
Am 13.05.2018 um 16:07 schrieb Mark Webb-Johnson:
Definitely something timing related. Even with auto wifi.mode=client, the wifi client comes up on boot, but v2 server can't connect on first try (but second try works).
This is what I get:
I (7316) event: sta ip: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64 I (7326) netmanager: Interface priority is st1 (10.10.41.203/255.255.248.0 gateway 10.10.40.64) I (7326) netmanager: Set DNS#0 10.10.40.64 I (7326) netmanager: Set DNS#1 0.0.0.0 I (7326) netmanager: Set DNS#2 0.0.0.0 I (7326) netmanager: WIFI client up (with MODEM down): starting network with WIFI client I (7326) esp32wifi: STA got IP with SSID: HIGHWAYS, MAC: 30:ae:a4:43:92:c4, IP: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64 I (7326) time: Starting SNTP client I (7326) ovms-server-v2: Status: Network is up, so attempt network connection I (7336) webserver: Launching Web Server I (7376) ssh: Launching SSH Server I (7386) ovms-server-v2: Status: Network is up, so attempt network connection I (8396) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867> DEVBENCH I (8396) ovms-server-v2: Status: Connecting... I (10396) housekeeping: System considered stable (RAM: 8b=94792-95652 32b=23608) W (25696) ovms-server-v2: Connection failed E (25696) ovms-server-v2: Status: Error: Connection failed I (25696) ovms-server-v2: Status: Disconnected
But, if I config set network dns '8.8.8.8 1.1.1.1', I get:
I (7087) event: sta ip: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64 I (7097) netmanager: Interface priority is st1 (10.10.41.203/255.255.248.0 gateway 10.10.40.64) I (7097) netmanager: Set DNS#0 8.8.8.8 I (7097) netmanager: Set DNS#1 1.1.1.1 I (7107) netmanager: WIFI client up (with MODEM down): starting network with WIFI client I (7107) esp32wifi: STA got IP with SSID: HIGHWAYS, MAC: 30:ae:a4:43:92:c4, IP: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64 I (7107) time: Starting SNTP client I (7107) ovms-server-v2: Status: Network is up, so attempt network connection I (7117) webserver: Launching Web Server I (7137) ssh: Launching SSH Server I (7157) ovms-server-v2: Status: Network is up, so attempt network connection I (8387) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867> DEVBENCH I (8387) ovms-server-v2: Status: Connecting... I (8617) ovms-server-v2: Connection successful I (8617) ovms-server-v2: Status: Logging in...
I'm guessing this new 'stored dns' is the root of the problem, but really not sure what is going on. The delay is long enough to allow your test to timeout.
Regards, Mark.
> On 13 May 2018, at 2:18 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > > Am 12.05.2018 um 18:21 schrieb Mark Webb-Johnson: >>> Did you apply the sdkconfig changes regarding SO_REUSE? I had none such problems after fixing that in my sdkconfig -- I also fixed the defaults in some >>> commit a few days before. >>> >>> CONFIG_LWIP_SO_REUSE=y >>> CONFIG_LWIP_SO_REUSE_RXTOALL=y >> Just double-checked, and yes they are there. >> >> It seems that after connecting to SSID, the attempt to run 'Ota status' is immediate, but the wifi client hasn't settled down yet. I've looked in >> web_cfg_init, but having trouble working out how it works. In the 'if (step == "2.test.connect")', it just seems to try to MyOTA.GetStatus as soon as the >> ssid matches? But it doesn't check that the wifi client is actually up (the reception of IP address may be a second or two after the SSID is connected, >> and anyway GetSSID() just returns the configured SSID, not the connected one). Or, maybe I'm missing something? > The state ticker does not check yet if it can abort a scheduled timeout. So it doesn't do the test as soon as GetSSID() returns the network. > > The test is done fixed 20 seconds after StartAccessPointClientMode(). That is normally plenty of time for everything to settle. In my runs, the client > network was normally fully functional in ~10 seconds. > > How long does your APClient switch take? You can try raising the 20 second timeout in line 226. > > Regards, > Michael > > >> Regards, Mark >> >>> On 12 May 2018, at 11:14 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>> >>> >>> Am 12.05.2018 um 15:42 schrieb Mark Webb-Johnson: >>>> Works better, but still causing me issues. I had a couple of times where it took down the whole housekeeping task (with red alerts saying event >>>> delivery queue was full so ticker.1 messages couldn't be delivered). I guess it is doing the wifi connectivity test in the main event task? >>> Yes, the most time consuming task in there is the OTA.GetStatus() fetching the server version info. But I didn't get any problems from that in all my tests... >>> >>>> The other problem is that the bringing up/down of the APCLIENT vs AP mode doesn't seem to work properly, so I lose connection to the station. Also, my >>>> iPad keeps switching back to home wifi, every time the OVMS reconfigures the network. APCLIENT mode really sucks. >>> Did you apply the sdkconfig changes regarding SO_REUSE? I had none such problems after fixing that in my sdkconfig -- I also fixed the defaults in some >>> commit a few days before. >>> >>> CONFIG_LWIP_SO_REUSE=y >>> CONFIG_LWIP_SO_REUSE_RXTOALL=y >>> >>> If these are missing, both the webserver and ssh cannot rebind after the switch from AP to APCLIENT. >>> >>> The switching takes some seconds, but my tablets (all Androids) only switched back to my home network during tests with issues. The normal process is >>> fast enough to keep them on the AP. >>> >>> Regards, >>> Michael >>> >>> >>>> I'll have another look at the wifi driver. Maybe I can improve the API a bit (based on what we have). Perhaps configure a STAtion even in AP mode >>>> (which is what I did with my alternative approach before). >>>> >>>> Regards, Mark. >>>> >>>>> On 12 May 2018, at 12:52 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>> >>>>> Added another fix. >>>>> >>>>> Or more sort of a workaround: I just had an empty server status display on step 4 test after successful connect. I'm not sure how this can happen, I >>>>> guess it's due to five events being processed at once after the connect (server v2 blocks the mongoose task there) and some race condition in the >>>>> javascript code in that case. >>>>> >>>>> The three event based status displays now again also do periodic updates every 5 seconds, so if this happens, the status gets updated again after 5 >>>>> seconds. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 11.05.2018 um 18:19 schrieb Michael Balzer: >>>>>> OK. I really should wait for config.mounted before reading from MyConfig. >>>>>> >>>>>> Fix is pushed, please try. >>>>>> >>>>>> >>>>>> Am 11.05.2018 um 17:49 schrieb Mark Webb-Johnson: >>>>>>> I tried a restart. Here is what I get: >>>>>>> >>>>>>> Firmware: 3.1.005-72-g8cd4d07/ota_0/main >>>>>>> Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1 >>>>>>> >>>>>>> I (1465) webserver: Launching Web Server >>>>>>> I (1465) ssh: Launching SSH Server >>>>>>> I (4185) wifi: ap channel adjust o:1,1 n:6,2 >>>>>>> I (4185) wifi: n:6 0, o:1 0, ap:6 2, sta:6 0, prof:1 >>>>>>> I (4945) wifi: state: init -> auth (b0) >>>>>>> I (4945) wifi: state: auth -> assoc (0) >>>>>>> I (4955) wifi: state: assoc -> run (10) >>>>>>> I (5055) wifi: connected with HIGHWAYS, channel 6 >>>>>>> I (5375) sdcard: SD CARD has been inserted >>>>>>> I (5465) sdcard: mount done >>>>>>> I (6025) wpa: PTK has been installed, it may be an attack, ignor it. >>>>>>> I (6025) wpa: GTK has been installed, it may be an attack, ignor it. >>>>>>> I (8515) wifi: n:6 0, o:6 0, ap:6 2, sta:6 0, prof:6 >>>>>>> I (8515) wifi: station: cc:44:63:89:b2:f4 join, AID=1, g, 20 >>>>>>> I (8525) esp32wifi: AP station connected: id: 1, MAC: cc:44:63:89:b2:f4 >>>>>>> I (9455) event: sta ip: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64 >>>>>>> I (9455) netmanager: Interface priority is st1 (10.10.41.203/255.255.248.0 gateway 10.10.40.64) >>>>>>> I (9455) netmanager: Set DNS#0 10.10.40.64 >>>>>>> I (9455) netmanager: Set DNS#1 0.0.0.0 >>>>>>> I (9455) netmanager: Set DNS#2 0.0.0.0 >>>>>>> I (9455) netmanager: WIFI client up (with MODEM down): starting network with WIFI client >>>>>>> I (9455) esp32wifi: STA got IP with SSID: HIGHWAYS, MAC: 30:ae:a4:43:92:c4, IP: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64 >>>>>>> I (9455) time: Starting SNTP client >>>>>>> I (10375) housekeeping: System considered stable (RAM: 8b=106112-106940 32b=23608) >>>>>>> I (13565) webserver: HTTP GET / >>>>>>> I (13575) webserver: HTTP GET /cfg/init >>>>>>> I (14825) webserver: HTTP GET / >>>>>>> I (15135) webserver: HTTP GET /cfg/init >>>>>>> I (15375) simcom: State timeout, transition to 13 >>>>>>> I (15375) simcom: State: Enter PoweredOff state >>>>>>> I (15375) gsm-mux: Stop MUX >>>>>>> I (16695) webserver: HTTP GET / >>>>>>> I (16705) webserver: HTTP GET /cfg/init >>>>>>> I (16735) webserver: HTTP GET /apple-touch-icon.png >>>>>>> I (16905) webserver: HTTP GET /assets/style.css >>>>>>> I (16905) webserver: HTTP GET /assets/script.js >>>>>>> I (17345) webserver: HTTP GET /cfg/init >>>>>>> I (28045) webserver: HTTP POST /cfg/init >>>>>>> I (28045) webserver: HandleLogin: 'admin' logged in, sid 98faaa06ed8f1574 >>>>>>> I (28085) webserver: HTTP GET /cfg/init >>>>>>> I (28085) webserver: CfgInit enter 2.test.connect >>>>>>> I (28085) webserver: HTTP GET /menu >>>>>>> I (40025) webserver: HTTP GET / >>>>>>> I (40035) webserver: HTTP GET /cfg/init >>>>>>> I (40035) webserver: CfgInit enter 2.test.connect >>>>>>> I (40045) webserver: HTTP GET / >>>>>>> I (40075) webserver: HTTP GET /apple-touch-icon.png >>>>>>> I (40085) webserver: HTTP GET /assets/style.css >>>>>>> I (40185) webserver: HTTP GET /assets/script.js >>>>>>> I (40355) webserver: HTTP GET /cfg/init >>>>>>> I (40355) webserver: CfgInit enter 2.test.connect >>>>>>> OVMS> enable >>>>>>> Password: >>>>>>> Secure mode >>>>>>> >>>>>>> I (50425) webserver: HTTP GET / >>>>>>> I (50425) webserver: HTTP GET /cfg/init >>>>>>> I (50425) webserver: CfgInit enter 2.test.connect >>>>>>> I (50465) webserver: HTTP GET /apple-touch-icon.png >>>>>>> I (50475) webserver: HTTP GET /assets/style.css >>>>>>> I (50555) webserver: HTTP GET /assets/script.js >>>>>>> I (50675) webserver: HTTP GET /cfg/init >>>>>>> I (50675) webserver: CfgInit enter 2.test.connect >>>>>>> OVMS# ota status >>>>>>> Running partition: ota_0 >>>>>>> Boot partition: ota_0 >>>>>>> Firmware: 3.1.005-72-g8cd4d07/ota_0/main (build idf v3.1-dev-454-gdaef4b5c May 11 2018 20:00:05) >>>>>>> Server Available: 3.1.005 >>>>>>> >>>>>>> OTA release providing minor improvements and fixes. >>>>>>> >>>>>>> - Vehicle: 12V battery monitoring >>>>>>> vehicle [12v.alert] = 1.6 Voltage drop alert threshold in V vs. reference >>>>>>> - OTA: automatic daily firmware updates (wifi only) >>>>>>> auto [ota] = yes Enable/disable >>>>>>> ota [auto.hour] = 2 Hour for daily check >>>>>>> - Logging: persistent configuration, file cycling, web config UI: >>>>>>> log [file.enable] = no Enable/disable file logging >>>>>>> log [file.maxsize] = 1024 Max log file size in kB, 0 = no cycling >>>>>>> log [file.path] = "" Log path, if on /sd watches sd.mounted >>>>>>> log [level] Default level >>>>>>> log [level.<tag>] Component levels >>>>>>> - Reverse Engineering Tools enhancements >>>>>>> - Tesla Roadster CAC support >>>>>>> - Miscellaneous bug fixes and enhancements >>>>>>> >>>>>>> I (61705) webserver: HTTP GET / >>>>>>> I (61715) webserver: HTTP GET /cfg/init >>>>>>> I (61715) webserver: CfgInit enter 2.test.connect >>>>>>> I (61745) webserver: HTTP GET /apple-touch-icon.png >>>>>>> I (61755) webserver: HTTP GET /assets/style.css >>>>>>> I (61845) webserver: HTTP GET /assets/script.js >>>>>>> I (61965) webserver: HTTP GET /cfg/init >>>>>>> I (61965) webserver: CfgInit enter 2.test.connect >>>>>>> I (72035) webserver: HTTP GET / >>>>>>> I (72045) webserver: HTTP GET /cfg/init >>>>>>> I (72045) webserver: CfgInit enter 2.test.connect >>>>>>> I (72085) webserver: HTTP GET /apple-touch-icon.png >>>>>>> I (72095) webserver: HTTP GET /assets/style.css >>>>>>> I (72175) webserver: HTTP GET /assets/script.js >>>>>>> I (73485) webserver: HTTP GET /cfg/init >>>>>>> I (73495) webserver: CfgInit enter 2.test.connect >>>>>>> >>>>>>> OVMS# config list auto >>>>>>> auto (readable writeable) >>>>>>> wifi.mode: apclient >>>>>>> wifi.ssid.ap: DEVBENCH >>>>>>> wifi.ssid.client: HIGHWAYS >>>>>>> >>>>>>> OVMS# config list module >>>>>>> module (readable writeable) >>>>>>> init: 2.test.connect >>>>>>> >>>>>>> >>>>>>> Regards, Mark >>>>>>> >>>>>>>> On 11 May 2018, at 10:42 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>> >>>>>>>> Do you have the earlier log, especially of the CfgInit ticker messages? >>>>>>>> >>>>>>>> Is the auto config correct and matching the "HIGHWAY" network? >>>>>>>> >>>>>>>> Please try a reboot. The ticker should take on step "2.test.connect" and proceed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Am 11.05.2018 um 16:28 schrieb Mark Webb-Johnson: >>>>>>>>> Trying the new web setup, but not getting very far... >>>>>>>>> >>>>>>>>> I (503580) webserver: HTTP GET / >>>>>>>>> I (503590) webserver: HTTP GET /cfg/init >>>>>>>>> I (503590) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (503610) webserver: HTTP GET /apple-touch-icon.png >>>>>>>>> I (503610) webserver: HTTP GET /assets/style.css >>>>>>>>> I (503730) webserver: HTTP GET /assets/script.js >>>>>>>>> I (503880) webserver: HTTP GET /cfg/init >>>>>>>>> I (503880) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (513960) webserver: HTTP GET /cfg/init >>>>>>>>> I (513960) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (513960) webserver: HTTP GET / >>>>>>>>> I (514000) webserver: HTTP GET /apple-touch-icon.png >>>>>>>>> I (514000) webserver: HTTP GET /assets/style.css >>>>>>>>> I (514090) webserver: HTTP GET /assets/script.js >>>>>>>>> I (514220) webserver: HTTP GET /cfg/init >>>>>>>>> I (514220) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (524280) webserver: HTTP GET / >>>>>>>>> I (524290) webserver: HTTP GET /cfg/init >>>>>>>>> I (524290) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (524320) webserver: HTTP GET /apple-touch-icon.png >>>>>>>>> I (524340) webserver: HTTP GET /assets/style.css >>>>>>>>> I (524420) webserver: HTTP GET /assets/script.js >>>>>>>>> I (524590) webserver: HTTP GET /cfg/init >>>>>>>>> I (524590) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (534620) webserver: HTTP GET / >>>>>>>>> I (534630) webserver: HTTP GET /cfg/init >>>>>>>>> I (534630) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (534660) webserver: HTTP GET /apple-touch-icon.png >>>>>>>>> I (534660) webserver: HTTP GET /assets/style.css >>>>>>>>> I (534760) webserver: HTTP GET /assets/script.js >>>>>>>>> I (534890) webserver: HTTP GET /cfg/init >>>>>>>>> I (534890) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (544940) webserver: HTTP GET / >>>>>>>>> I (544950) webserver: HTTP GET /cfg/init >>>>>>>>> I (544950) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (544980) webserver: HTTP GET /assets/style.css >>>>>>>>> I (544990) webserver: HTTP GET /apple-touch-icon.png >>>>>>>>> I (545080) webserver: HTTP GET /assets/script.js >>>>>>>>> I (545250) webserver: HTTP GET /cfg/init >>>>>>>>> I (545250) webserver: CfgInit enter 2.test.connect >>>>>>>>> >>>>>>>>> OVMS# wifi status >>>>>>>>> WiFi >>>>>>>>> Power: on >>>>>>>>> Mode: Access-Point + Client mode >>>>>>>>> >>>>>>>>> STA SSID: HIGHWAYS >>>>>>>>> MAC: 30:ae:a4:43:92:c4 >>>>>>>>> IP: 10.10.41.203/255.255.248.0 >>>>>>>>> GW: 10.10.40.64 >>>>>>>>> >>>>>>>>> AP SSID: DEVBENCH >>>>>>>>> MAC: 30:ae:a4:43:92:c5 >>>>>>>>> IP: 192.168.4.1 >>>>>>>>> AP Stations: 1 >>>>>>>>> 1: MAC: cc:44:63:89:b2:f4, IP: 192.168.4.2 >>>>>>>>> >>>>>>>>> OVMS# ota status >>>>>>>>> Running partition: ota_0 >>>>>>>>> Boot partition: ota_0 >>>>>>>>> Firmware: 3.1.005-72-g8cd4d07/ota_0/main (build idf v3.1-dev-454-gdaef4b5c May 11 2018 20:00:05) >>>>>>>>> Server Available: 3.1.005 >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> I (1141850) webserver: HTTP GET / >>>>>>>>> I (1141860) webserver: HTTP GET /cfg/init >>>>>>>>> I (1141860) webserver: CfgInit enter 2.test.connect >>>>>>>>> I (1141890) webserver: HTTP GET /apple-touch-icon.png >>>>>>>>> I (1141890) webserver: HTTP GET /assets/style.css >>>>>>>>> I (1141990) webserver: HTTP GET /assets/script.js >>>>>>>>> I (1142120) webserver: HTTP GET /cfg/init >>>>>>>>> I (1142120) webserver: CfgInit enter 2.test.connect >>>>>>>>> >>>>>>>>> >>>>>>>>> Can't get out of that 2.test.connect. >>>>>>>>> >>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>>> Regards, Mark. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OvmsDev mailing list >>>>>>>>> OvmsDev@lists.openvehicles.com >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>>>>> -- >>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>> _______________________________________________ >>>>>>>> OvmsDev mailing list >>>>>>>> OvmsDev@lists.openvehicles.com <mailto: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 >>>>>> -- >>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev@lists.openvehicles.com >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>>>> -- >>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.openvehicles.com <mailto: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 >>> -- >>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.openvehicles.com <mailto: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 > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto: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 -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26