- OvmsDev - Open Vehicles

Problems with AP + Client mode
by Greg D. 18 Mar '18

18 Mar '18

Hi folks, Are any of you having trouble with AP+Client mode? A couple of observations.... AP mode, by itself, works great. AP+Client, however, seems to depend on whether the client side gets connected or not. If it does, I can also connect to the AP, and when connected, navigate the webserver. If the client side doesn't get connected (the specified SSID isn't available), my phone can connect to the AP, but accessing the webserver never works (times out). This is with the simcom modem unconnected (antenna removed). I also have the DNS server address fixed to '9.9.9.9 8.8.8.8', to remove that from being an issue. If I go into the webserver (when it's working) and configure the client SSID to connect to any available, neither the client nor the AP come up after a module reset. This is apparently due to an error during the Auto execution, where the 'wifi mode apclient' command is failing due to not having the client ssid specified (it's coded as required, should be optional). As I noted earlier, if the module comes up and the client SSID isn't immediately available, the ability for it to connect later is limited. Mark suggested this is because the wifi client isn't scanning channels other than the one the AP mode is on, so it's a matter of luck if the client AP happens to come up on the right one. (Here, that never seems to occur :( ). If the AP+Client does come up (client SSID is available), and later the modem gets connected, connection to the v2 server hangs. Seems like the internal routing of traffic is getting confused, or rather, the module is getting a new IP address, but the server's connection is not bounced. (Enhancement request: Have the network status command to note which interface is considered active.) IMHO, we really shouldn't even try to run the modem if the server is connected via the wifi client, because, besides messing up the network configuration, it's also causing a slow drain on the modem's data plan (I'm seeing the Rx/Tx counters increment) for no benefit. Sometimes I get a spew of 'job queue overflow' errors (see below). Not sure of all the conditions, but tapping the Status tab seems the most often cause, though it can be tapped without causing the error too. Under conditions where the AP+Client had the client connected and the AP able to associate, but not able to access the webserver, I was able to get to the webserver if I joined the same network as the client and surfed to the module's address there. Lots of test cases here. I really need a test matrix to be sure I can reproduce the issues and successes later... Part of the puzzle is that the retries built into the software often recover things, so it's hard to know what's a fatal failure, and what is recoverable in time, and so may be less serious for the end user. Finally, I have seen circumstances where the simcom model gets into a state where it comes up and starts connecting, but after a few frames (less than 10) gets stuck with an increasing number of framing errors, but no progress on receive. Eventually it will reset and try again, and after some number of these, sometimes finally connect (and mess up the wifi that was running happily all along). Greg I (473446) simcom: Power Cycle I (479406) simcom: State: Enter PoweredOn state I (498456) simcom: State: Enter MuxStart state I (498456) gsm-mux: Start MUX I (498466) gsm-mux: Channel #0 is open I (498466) gsm-mux: Channel #1 is open I (498476) gsm-mux: Channel #2 is open I (498476) gsm-mux: Channel #3 is open I (498486) gsm-mux: Channel #4 is open I (499446) simcom: State: Enter NetWait state I (503836) webserver: HTTP POST /api/execute I (503836) webcommand: HttpCommandStream[0x3fff96c0]: 20240 bytes free, executing: simcom status I (509506) simcom: CREG Network Registration: RegisteredRoaming I (510446) simcom: State: Enter NetStart state I (511596) simcom: PPP Connection is ready to start I (512446) simcom: State: Enter NetMode state I (512446) gsm-ppp: Initialising... I (512456) webserver: HTTP GET /home I (515616) gsm-ppp: StatusCallBack: None I (515616) gsm-ppp: status_cb: Connected I (515616) gsm-ppp: our_ipaddr = 10.170.146.142 I (515616) gsm-ppp: his_ipaddr = 10.64.64.64 I (515616) gsm-ppp: netmask = 255.255.255.255 I (515616) gsm-ppp: our6_ipaddr = :: I (515616) netmanager: Set DNS#0 9.9.9.9 I (515616) netmanager: Set DNS#1 8.8.8.8 I (515616) time: Starting SNTP client I (517746) webserver: HTTP GET /home I (520476) webserver: HTTP GET /status W (526166) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow W (526416) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow W (526446) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow W (526666) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow W (526916) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow W (527166) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow W (527416) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow W (527446) websocket: WebSocketHandler[0x3fff5f2c]: job queue overflow

3 8

Simcom restart crash
by Greg D. 18 Mar '18

18 Mar '18

1 0

Command security
by Stephen Casner 18 Mar '18

18 Mar '18

Mark asked me to check whether the 'secure' flag is set appropriately in the various command invocation contexts. I began with the console command list where there are a number of questionable settings. My assumption going in is that all someone should be able to do before enabling is to look at status that does not include sensitive info. However, there are several commands that do more. All of these commands are at least partially enabled in non-secure mode: OVMS > ? boot BOOT framework echo Test getchar enable Enter secure mode event EVENT framework exit End console session help Ask for help metrics METRICS framework module MODULE framework network NETWORK framework notify NOTIFICATION framework obdii OBDII framework server OVMS Server Connection framework simcom SIMCOM framework time TIME framework vehicle Vehicle framework The harmless ones are 'boot', which just shows status, 'echo', 'exit' and 'help'. Of course, 'enable' needs to be here to change state. But I have questions about all the others: 1. obdii, server and simcom appear to allow their full functionality, including starting and stopping operations, in non-secure mode. That seems wrong. 2. event, metrics and notify all allow tracing to be turned on or off. Is that safe? 3. time allows setting the time in non-secure mode. That may not be critical in this system, but could mess up timed activities. 4. Setting the vehicle module should require being enabled, no? 5. Is it OK to list the metrics in non-secure mode? Is any of that information sensitive enough that it should be prevented? (We don't have the option to show some metrics and not others at this point.) 6. The module command only allowed the subcommand 'factory' which did not allow any subcommand, so the right fix there is to just make the whole command require secure mode. This observation exposed a bug in the code to construct the usage string, which I fixed. So, basically, the question is what do we want someone to be able to do in non-secure mode? -- Steve

3 3

ota questions
by Michael Balzer 18 Mar '18

18 Mar '18

Working on the OTA web UI. Some questions: a) Flashing and changing the boot partition outputs some irritating overflow and "??" log messages: OVMS > ota flash vfs /sd/ovms3.done Current running partition is: ota_0 Target partition is: ota_1 Source image is 1480592 bytes in size Preparing flash partition... Flashing image partition... Setting boot partition... OTA flash was successful Flashed 1480592 bytes from /sd/ovms3.done Next boot will be from 'ota_1' I (1316956) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (1317156) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (1317156) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 ( 1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685 I (1317166) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (1317176) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:? I (1317746) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293 I (1317776) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 ( 52) I (1317776) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (1317976) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (1317986) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 ( 1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685 I (1317986) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (1317996) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:? I (1318566) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293 I (1318606) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 ( 52) … OVMS > ota boot ota_1 Boot from ota_1 at 0x00810000 (size 0x00400000) I (301766) esp_image: segment 0: paddr=0x00810020 vaddr=0x3f400020 size=0x5879c (362396) map I (301966) esp_image: segment 1: paddr=0x008687c4 vaddr=0x3ffb0000 size=0x0382c ( 14380) I (301976) esp_image: segment 2: paddr=0x0086bff8 vaddr=0x40080000 size=0x00400 ( 1024) 0x40080000: _WindowOverflow4 at /home/balzer/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685 I (301976) esp_image: segment 3: paddr=0x0086c400 vaddr=0x40080400 size=0x03c10 ( 15376) I (301986) esp_image: segment 4: paddr=0x00870018 vaddr=0x400d0018 size=0xfb154 (1028436) map 0x400d0018: _flash_cache_start at ??:? I (302556) esp_image: segment 5: paddr=0x0096b174 vaddr=0x40084010 size=0x0e5b4 ( 58804) 0x40084010: spi_flash_mmap at /home/balzer/esp/esp-idf/components/spi_flash/./flash_mmap.c:293 I (302596) esp_image: segment 6: paddr=0x00979730 vaddr=0x400c0000 size=0x00034 ( 52) Can these safely be ignored? The flashed partitions seem to work correctly. b) How do you get back to the factory partition if something went so wrong you can't use the "ota" command? I would have expected "make flash" to reset the boot partition to "factory", as all flashes are only done there, but it doesn't. So if you're on another partition with a broken firmware, how do you recover? Is there a way to set the boot partition using esptool.py? c) ota flash http still gives me a DNS lookup error on any other host than api.openvehicles.com and fails to download from api.openvehicles.com, regardless of the type of network (wifi/modem). OVMS > ota flash http www.google.com/ovms3.bin Current running partition is: factory Target partition is: ota_0 Download firmware from www.google.com/ovms3.bin to ota_0 Error: Request failed W (666891) net: DNS lookup on www.google.com failed err=200 OVMS > ota flash http api.openvehicles.com/test.bin Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/test.bin to ota_0 […dead, needs reset] Is this a local problem of mine? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 26

Wifi: Support APCLIENT mode (for Access-Point + Client)
by Mark Webb-Johnson 16 Mar '18

16 Mar '18

I’ve added support for a new wifi mode ‘apclient’. This takes AP and STA mode SSIDs, and sets up as both an access point and a client. Some caveats: There seems to be a problem coming out of the mode (wifi mode off, etc). The network interfaces are not torn down correctly every time. Symptom is the client comes up, wifi shows an IP address on it, but the address is not set correctly on the ’st’ network interface. Reproducibility is random (maybe interface order related?). Not sure if this is my fault, or a bug in the framework. A 'module reset’ works around the problem ;-) I updated Michael’s webserver, and the auto framework, to support this, but I’m not too familiar with that so might have got it wrong. Wifi sclient style mode (scanning for known SSIDs to join without knowing the _exact_ SSID) is not currently supported. I’m not sure if this can ever be supported properly. The apclient mode works by locking the channel for both the AP and STA to be the same - if we are locked like that, how can we scan across channels? I’m guessing that ‘wifi scan’ will be similarly restricted, when in ap or apclient modes. This is not a router. Setting the gateway on the ’st’ interface would be trivial, but I don’t think packets can travel AP -> STA. Doing that would require source-nat, plus packet routing, etc. Routing would be easy, SNAT very nasty. It does look pretty cool, and seems to work well: OVMS > network Interface#2: ap IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 Interface#1: st IPv4: 10.x.x.x/255.255.255.0 gateway 10.x.x.x Interface#0: lo IPv4: 127.0.0.1/255.0.0.0 gateway 127.0.0.1 DNS: 8.8.8.8 8.8.4.4 OVMS > wifi WiFi Power: on Mode: Access-Point + Client mode STA SSID: MY-STA-SSID MAC: re:da:ct:ed:da:ta IP: 10.x.x.x/255.255.255.0 GW: 10.x.x.x AP SSID: MY-AP-SSID MAC: da:ta:re:da:ct:ed IP: 10.x.x.x AP Stations: 1 1: MAC: da:ta:re:da:ct:ed, IP: 192.168.4.2 Enjoy, Mark. > Begin forwarded message: > > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] ee023a: Wifi: Support APCLIENT mode (for Access-Point + Cl... > Date: 14 March 2018 at 11:09:21 AM HKT > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: ee023a5c8383901da2b190e3a42e94ad49724b07 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ee0… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-03-14 (Wed, 14 Mar 2018) > > Changed paths: > M vehicle/OVMS.V3/changes.txt > M vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp > M vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.h > M vehicle/OVMS.V3/components/ovms_webserver/src/web_cfg.cpp > > Log Message: > ----------- > Wifi: Support APCLIENT mode (for Access-Point + Client) > >

3 4

Mongoose update & dev merge
by Michael Balzer 16 Mar '18

16 Mar '18

Mark, Steve, I'm about to update our mongoose submodule to the latest changes _including_ the latest additions to the "dev" branch. That's because I want to use the mg_broadcast() function, which doesn't work on the ESP32 until this fix from the dev branch: https://github.com/cesanta/mongoose/commit/780077d1187ff632bdcbf33d65207a08… Quickly found that in the mongoose issues once I knew what to look for… ;) My local checkout builds & runs. I've checked through the commits, there is no API change (except a minor one on HTTP header parsing). None of the commits looks like it could break something and there are some clear fixes included, so I think we can just merge the dev branch. I'll do some general tests before pushing the change, if you'd like me to wait with the update or do some specific tests, tell me. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 6

OVMS v3 DNS
by Mark Webb-Johnson 13 Mar '18

13 Mar '18

It seems that we have issues with DNS in OVMS v3. One problem I’ve found is that every time a network interface comes up, the DNS servers for that interface are defined. But when the interface goes down, the old DNS servers are not restored. This becomes an issue when we have both wifi and modem networking interfaces. I’ve committed support for: config network dns … I use: config set network dns "8.8.8.8 8.8.4.4" Along with a new event ‘network.interface.up’, network manager now sets those DNS servers, if defined. Regards, Mark.

1 0

Power consumption
by M B 12 Mar '18

12 Mar '18

Guys, What is the power consumption of ovms 3.1? Did we measure it? I know that some of the Leafs have issues with 12V battery, so would be good to know how much is being consumed by ovms. Thanks, Maciek

3 2

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 037bdd: OVMS event scripts are run in secure mode
by Mark Webb-Johnson 12 Mar '18

12 Mar '18

It seems that event scripts are run in insecure console mode. That doesn’t seem right. I thought we were protecting these so that only secure commands could create these scripts (vfs edit, append, cp, etc), but the scripts themselves ran secure? Otherwise, on a module with a password, how do you run scripts on startup? Putting ‘enable …’ in the script itself is inherently insecure. Anyway, I changed it to run these event scripts in secure mode. If that’s not right, let’s discuss it here… The other issue here is that these scripts may crash the system, so perhaps they should follow the ‘auto’ system as well? Only run event scripts if a corresponding ‘auto’ config is set (can default to true), and the auto system is not temporarily disabled due to too many crashes? Regards, Mark. > Begin forwarded message: > > From: GitHub <noreply(a)github.com> > Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 037bdd: OVMS event scripts are run in secure mode > Date: 11 March 2018 at 9:20:54 PM HKT > To: mark(a)webb-johnson.net > Reply-To: GitHub <noreply(a)github.com> > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 037bddc3e6efa60c70c1fca36b0e0400c87bafe1 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/037… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-03-11 (Sun, 11 Mar 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms_script.cpp > > Log Message: > ----------- > OVMS event scripts are run in secure mode > >

2 2

3.1 Production
by Mark Webb-Johnson 11 Mar '18

11 Mar '18

It is with great relief that I can announce I just wrote a very big cheque to produce the first batch of 120 OVMS v3.1 modules. That is on top of the last big cheque I wrote a couple of months ago for the injection moulding. The order is in, and production has started. Specifically, I’ve ordered: 120x OVMS v3.1 modules (cased in black injection moulded enclosures) 60x OVMS 3G modems with EU frequencies 60x OVMS 3G modems with US frequencies These include WROVER modules with dual processor cores, 16MB flash and 4MB SPI RAM. Also all the other OVMS v3 features such as Wifi, Bluetooth, 3x CAN buses, SD CARD, GPIOs, external 12V power control, pluggable modem modules, OTA firmware updates, etc. 100 (50x EU, 50x US) of these will go direct to FastTech for end users. 20 will come to me in Hong Kong for developers and special users. We have enough stock of the other cables, antennas, etc, already at FastTech. I’ll announce pricing in the next few days. There will be special pricing for everybody here (developers) as well as existing users who want to upgrade. This first batch are early production units, with beta firmware, intended for expert users only. To all those that have contributed to the project so far, we owe a huge debt of thanks. We’ve still got a long way to go with the firmware, but It feels good to finally get this out the door. I’m confident that we have a fantastic base on which to build great things in the coming years. Regards, Mark.

7 15