July 2020 - OvmsDev - Open Vehicles

Wifi setup
by Derek Caudwell 11 Jul '20

11 Jul '20

Hi devs, I recently received the ovms hardware and have been trying to setup the unit so I can solely use the wifi AP+client. In NZ 3G is soon to be sunset and for my needs I don't really need a connection when I'm driving (and want to make sure everything is behaving nicely on the can bus before I do). I realise AP+client brings it limitations however hopefully some of these can be worked around as I want to be able to use the dashboard/plugins as well as the mobile app. I am new to C/ESP32 programming and the code base so I thought it best to ask a few questions before I begin tinkering with it. Ideally I want the unit on loss of connection to an AP to try and find another AP that has been set in the wifi config and connect. The parts I am not too sure are as follows: - on boot the code uses the default wifi ssid, if the default is not available how does the code try and switch to one of the other saved APs? - can multiple APs be saved to the wifi config memory and handled by ESP32? or do they need to be retrieved from ovms config, wifi client details set, try connect and enumerated through? - I assume EventTimer10 is the logical place to add extra code if required to enumerate through APs and try to connect? similar to EventScanWifiDone when in SClient mode - What is the reason scanning mode is unavailable for AP+client mode in auto init, from the ESP32 documentation it appeared to be usable still but with limitations? Thanks in advance for any pointers and background. Cheers Derek

5 11

Re: [Ovmsdev] OvmsDev Digest, Vol 102, Issue 8
by Derek Caudwell 10 Jul '20

10 Jul '20

Great Michael, Let me know and I'll test the build out. I have a 2016 AZE0 Nismo JDM Leaf and noticed when I turn it on it throws 2 errors repeatedly on can2 (off or charging it's fine). What's the best way to diagnose the root cause of the errors? I assume ovms just ignores traffic it does not recognise, and LeafSpy shows a U1000 DTC on Meter that won't clear. Date: Fri, 10 Jul 2020 08:55:32 +0800 > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> > Subject: Re: [Ovmsdev] Wifi setup > Message-ID: <CFB768E9-8101-495C-8826-085302DDB0C9(a)webb-johnson.net> > Content-Type: text/plain; charset="utf-8" > > FYI: > > I?ve recently done some work with the esphome system (based on platformio > on top of esp idf), for home automation. They don?t seem to trust the ESP > libraries identifying the strongest signal (in the case of two APs > broadcasting the same SSID). They don?t blindly connect to a SSID, but > instead first do a scan to produce an ordered list and then connect to the > SSID+AP-MAC-Address of the AP with the strongest signal. > > That approach might help with your other issue (recently raised in mantis). > > Regards, Mark. > > > On 10 Jul 2020, at 5:43 AM, Michael Balzer <dexter(a)expeedo.de> wrote: > > > > ? Welcome Derek, > > > > I've got a rework of the wifi component near done that allows to use > scanning mode in apclient configuration. I think I can push the changes > tomorrow & suggest you'll be my beta tester ;-) > > > > Regards, > > Michael > > > > > > Am 09.07.20 um 20:50 schrieb Derek Caudwell: > >> Hi devs, > >> > >> I recently received the ovms hardware and have been trying to setup the > unit so I can solely use the wifi AP+client. In NZ 3G is soon to be sunset > and for my needs I don't really need a connection when I'm driving (and > want to make sure everything is behaving nicely on the can bus before I > do). > >> > >> I realise AP+client brings it limitations however hopefully some of > these can be worked around as I want to be able to use the > dashboard/plugins as well as the mobile app. I am new to C/ESP32 > programming and the code base so I thought it best to ask a few questions > before I begin tinkering with it. > >> > >> Ideally I want the unit on loss of connection to an AP to try and find > another AP that has been set in the wifi config and connect. The parts I am > not too sure are as follows: > >> - on boot the code uses the default wifi ssid, if the default is not > available how does the code try and switch to one of the other saved APs? > >> - can multiple APs be saved to the wifi config memory and handled > by ESP32? or do they need to be retrieved from ovms config, wifi client > details set, try connect and enumerated through? > >> - I assume EventTimer10 is the logical place to add extra code if > required to enumerate through APs and try to connect? similar to > EventScanWifiDone when in SClient mode > >> - What is the reason scanning mode is unavailable for AP+client mode > in auto init, from the ESP32 documentation it appeared to be usable still > but with limitations? > >> > >> Thanks in advance for any pointers and background. > >> > >> Cheers Derek > >> > >> > >> _______________________________________________ > >> OvmsDev mailing list > >> OvmsDev(a)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(a)lists.openvehicles.com > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev >

1 0

Hi everyone
by Soko 10 Jul '20

10 Jul '20

Hey, I'm Soko and live in Austria/Europe. I'm a programmer since 20 years now, mainly (big) Windows applications (PowerBuilder, C#, .NET) with databases (MSSQL, Oracle, ...). I also dabble in Arduino/ESP32 programming with little projects for my home since 2 years. I've just bought the new version of the Volkswagen e-Up (equals Skoda citigo and Seat Mii) and was directed to your project by some guys over at www.goingelectric.de. I'd like to contribute to OVMS by adding the e-Up using the standard OBD2 cable (not the Komfort-CAN). My first hurdle though is to get the development environment under Windows up and running. Which seems to be a big task by itself. I guess using Visual Studio Code with PlatformIO (as I do for my Arduino projects) is no option, correct? I have to use this special "ESP IDF" to make it work... Is there any better/newer guide for me than page 6 of the developer guide doc? Thanks Andi

4 5

Trade War impact
by Mark Webb-Johnson 08 Jul '20

08 Jul '20

FYI: We are starting to see an impact from the US/China trade war, with OVMS as collateral damage. This is currently affecting OVMS in two ways: Imports of OVMS modules, cables, and antennas, into USA, are starting to be hit with a 25% tax. I don’t have any workaround, and it would cost way more than +25% to get these manufactured elsewhere (even if all the components didn’t come from China in the first place). So, this tax is now being passed on to consumers in USA. We are experiencing difficulties getting the US Hologram SIMs into China. I realise that this is an inconvenience for the users, but we have no alternative at the moment. So, from this week until further notice, OVMS modules purchased from Fasttech won’t include Hologram SIMs. These can be purchased directly from Hologram themselves: https://store.hologram.io/store/global-iot-sim-card/17 <https://store.hologram.io/store/global-iot-sim-card/17> (You can also order on amazon https://www.amazon.com/3-in-1-Global-IoT-SIM-Card/dp/B07GY2S8QK#ace-2093936… <https://www.amazon.com/3-in-1-Global-IoT-SIM-Card/dp/B07GY2S8QK#ace-2093936…>) OVMS modules purchased from the official distributors (either Carl Medlock in USA, or Open Energy Monitor in EU) will still include the Hologram SIMs. I have updated the user guide documentation to clarify this. I’ll let you know if the situation changes. Regards, Mark.

1 0

TPMS subsystem, Roadster, Model S, Baolong, and some UDS hacking/cracking
by Mark Webb-Johnson 05 Jul '20

05 Jul '20

A long post, but contains some interesting information, and discussion of UDS hacking/cracking approaches. A few weeks ago, I published my work on the Baolong TPMS in the Tesla Roadster. This resulted in a new TPMS subsystem in OVMS, as well as support for reading and writing tyre ID sets from/to the TPMS ECU in the car. For the Tesla Roadster, this requires the new K-line option board that should be generally available next week. I then moved on to look at the Model S. My car (a 2014 Model S) uses a Baolong ECU, and can’t display the tyre pressures or temperatures. It is a simpler system than the roadster (same manufacturer), with just one ECU, one CAN bus connection, no k-line, no Lin bus, and no external antennas. Also about US$40 on eBay :-) Decoding the message data was pretty trivial. Same format as the Roadster (same manufacturer, after all), just on a different CAN ID. The status messages are different, but the Tesla Model S ECU in developer mode shows a nice decode of those. A few minutes in the OVMS firmware and we can display tyre pressures and temperatures in the OVMS Apps (which strangely, Tesla still can’t do with that Baolong system in the car). A colleague provided some CAN bus dumps of the engineering TPMS tool reading and writing tyre ID sets, and they looked pretty simple. First the read commands: 34.296622 2T11 64F 03 22 f0 90 55 55 55 55 34.310594 2R11 65F 10 13 62 f0 90 11 12 13 34.396020 2T11 64F 30 03 0a 00 00 00 00 00 34.396663 2R11 65F 21 14 21 22 23 24 31 32 34.415594 2R11 65F 22 33 34 41 42 43 44 55 Looks pretty similar to the stuff we’ve seen before with OBDII active polling. ID 64F for the command and 65F for the response from the ECU. An extended OBDII multi-frame read of PID 0xf090. Easy enough, and implemented in the vehicle_teslamodels in less than an hour. So, on to the write commands: 114.506522 2T11 64F 02 10 03 00 00 00 00 00 114.552387 2R11 65F 06 50 03 00 96 17 70 55 120.956904 2T11 64F 02 27 01 00 00 00 00 00 120.957400 2R11 65F 04 67 01 b5 0a 55 55 55 144.106603 2T11 64F 04 27 02 f7 02 00 00 00 144.107136 2R11 65F 02 67 02 55 55 55 55 55 157.657510 2T11 64F 10 13 2e f0 90 11 12 13 157.657932 2R11 65F 30 03 14 55 55 55 55 55 157.756158 2T11 64F 21 14 21 22 23 24 31 32 157.856138 2T11 64F 22 33 34 41 42 43 44 00 158.148199 2R11 65F 03 6e f0 90 55 55 55 55 At first glance, I skipped over the first three commands (assuming they were checking firmware version, or something like that), and looked at the last group. Seems similar to the OBDII extended read we saw to read the IDs. But when I try it on my bench ECU I don’t get the happy ‘65F 03 6e f0 90’ acknowledging the write, but instead a '65F 03 7f 2e 31’ indicating an error. So, I went back and looked at those first three requests. In OBDII speak, these decode as: 64F 02 10 03 00 00 00 00 00 0x02 = 2 data bytes in the request 0x10 = UDS Diagnostic Session Control 0x03 = UDS session type 0x03 65F 06 50 03 00 96 17 70 55 0x06 = 6 data bytes in the response 0x50 = 0x10 + 0x40 = successful response to our 0x10 command 0x03 = UDS session type 0x03 0x00961770 = Session data 64F 02 27 01 00 00 00 00 00 0x02 = 2 data bytes in the request 0x27 = UDS Security Access 0x01 = Type 1 (seed request) 65F 04 67 01 b5 0a 55 55 55 0x04 = 4 data bytes in the response 0x67 = 0x27 + 0x40 = successful response to our 0x27 command 0x01 = Type 1 (seed) 0xb50a = UDS security access seed data 64F 04 27 02 f7 02 00 00 00 0x04 = 4 data bytes in the request 0x27 = UDS Security Access 0x02 = type 2 (login) 0xf702 = UDS security access login data 65F 02 67 02 55 55 55 55 55 0x02 = 2 data bytes in the response 0x67 = 0x27 + 0x40 = successful response to our 0x27 command 0x02 = type 2 (login success) * See here for an explanation: https://en.wikipedia.org/wiki/Unified_Diagnostic_Services <https://en.wikipedia.org/wiki/Unified_Diagnostic_Services> At the point, I had an ‘oh shit’ moment. Why they hell would they use UDS security to protect writing TPMS tyre IDs? Good grief. The way this works is that the diagnostic tool first establishes a diagnostic session with the ECU. It then requests a seed, and the ECU responds with a random number. The tool and ECU both then independently do a secret calculation (based on a secret algorithm and a secret number), the tool provides the result to the ECU, and the ECU verifies it. The seed provides protection against relay attack, and the password or algorithm are never sent over the wire so if done properly this can be strong against eavesdropping. Despite the initial ‘oh shit’, there were two bits of good news. Firstly, the seed was only 2 bytes; that is 65,536 combinations and very susceptible to brute force. Secondly, we had a number of writes logged from the original tool so knew some good seed and login combinations: 843b -> d632 8338 -> d330 8932 -> db32 4738 -> 5730 ff00 -> ff00 That, and in particular the last one, doesn’t seem to show much entropy. The seed->password is just not random enough. I started with some blind guesses: Here are our known samples: 843b -> d632 8338 -> d330 8932 -> db32 4738 -> 5730 ff00 -> ff00 In binary: 843b 1000 0100 0011 1011 d632 1101 0110 0011 0010 8338 1000 0011 0011 1000 d330 1101 0011 0011 0000 8932 1000 1001 0011 0010 db32 1101 1011 0011 0010 4738 0100 0111 0011 1000 5730 0101 0111 0011 0000 ff00 1111 1111 0000 0000 ff00 1111 1111 0000 0000 It seems that the first byte can have 0’s become a 1, but never a 1 become a 0. So let’s assume that is a boolean OR operator. The second byte doesn’t have such good data, but it seems a 1 can become a 0. So let’s assume that it is a boolean AND operator. ----or--- ---and--- 0101 0010 ??11 0?10 In ascii, 0101 0010 is “R”. The second byte is harder, as we don’t have enough data and only know the result for 5 out of the 8 bits. But, if it is a letter, we can guess it is 0111 0?10. In ascii, 0111 0010 is the lower case “r”. So, OR the first byte with “R”, then AND the second byte with “r”. Can it be that simple? Can my first blind guess be correct? A little perl code: #!/usr/bin/perl while (<>) { chop; my $val = hex($_); my $first = $val >> 8; my $second = $val & 0xff; printf "Response for %04x is %02x %02x\n",$val,($first | 0b01010010),($second & 0b01110010) } # Running it… 843b Response for 843b is d6 32 8338 Response for 8338 is d3 30 8932 Response for 8932 is db 32 4738 Response for 4738 is 57 30 ff00 Response for ff00 is ff 00 OK. But that is easy. Let’s try it for some new data… OVMS# can can2 tx standard 64F 02 10 03 00 00 00 00 00 V (11781198) canlog-monitor: 1593874849.354117 2T11 64F 02 10 03 00 00 00 00 00 V (11781248) canlog-monitor: 1593874849.400007 2R11 65F 06 50 03 00 96 17 70 55 OVMS# can can2 tx standard 64F 02 27 01 00 00 00 00 00 V (11786098) canlog-monitor: 1593874854.254102 2T11 64F 02 27 01 00 00 00 00 00 V (11786098) canlog-monitor: 1593874854.254637 2R11 65F 04 67 01 be 01 55 55 55 (My program gives "Response for be01 is fe 00”) OVMS# can can2 tx standard 64F 04 27 02 fe 00 00 00 00 V (11805208) canlog-monitor: 1593874873.364121 2T11 64F 04 27 02 fe 00 00 00 00 V (11805208) canlog-monitor: 1593874873.364639 2R11 65F 02 67 02 55 55 55 55 55 Of course, that is a guess. But after trying a few dozen times I get success 100% of the time. It does make me wonder what is the point of even attempting to add a security layer so trivially easy to crack. I implemented the write in the OVMS firmware for Tesla Model S, and we have: OVMS# tpms read TPMS read as 11121314,21222324,31323334,41424344 V (34357) canlog-monitor: 34.296622 2T11 64F 03 22 f0 90 55 55 55 55 V (34377) canlog-monitor: 34.310594 2R11 65F 10 13 62 f0 90 11 12 13 V (34457) canlog-monitor: 34.396020 2T11 64F 30 03 0a 00 00 00 00 00 V (34457) canlog-monitor: 34.396663 2R11 65F 21 14 21 22 23 24 31 32 V (34477) canlog-monitor: 34.415594 2R11 65F 22 33 34 41 42 43 44 55 OVMS# tpms write models Tyre set 'models' written to vehicle TPMS successfully V (39687) canlog-monitor: 39.627553 2T11 64F 02 10 03 00 00 00 00 00 V (39737) canlog-monitor: 39.673421 2R11 65F 06 50 03 00 96 17 70 55 V (39787) canlog-monitor: 39.726138 2T11 64F 02 27 01 00 00 00 00 00 V (39787) canlog-monitor: 39.726907 2R11 65F 04 67 01 80 3b 55 55 55 V (39887) canlog-monitor: 39.826021 2T11 64F 04 27 02 d2 32 00 00 00 V (39887) canlog-monitor: 39.826744 2R11 65F 02 67 02 55 55 55 55 55 V (39987) canlog-monitor: 39.926014 2T11 64F 10 13 2e f0 90 08 02 ee V (39987) canlog-monitor: 39.926747 2R11 65F 30 03 14 55 55 55 55 55 V (40087) canlog-monitor: 40.026051 2T11 64F 21 37 08 02 e9 63 08 02 V (40187) canlog-monitor: 40.126015 2T11 64F 22 ed fb 08 02 db 3a 00 V (40187) canlog-monitor: 40.126692 2R11 65F 03 7f 2e 78 55 55 55 55 V (40477) canlog-monitor: 40.418525 2R11 65F 03 6e f0 90 55 55 55 55 OVMS# tpms read TPMS read as 0802ee37,0802e963,0802edfb,0802db3a V (62107) canlog-monitor: 62.046624 2T11 64F 03 22 f0 90 55 55 55 55 V (62127) canlog-monitor: 62.060579 2R11 65F 10 13 62 f0 90 08 02 ee V (62207) canlog-monitor: 62.146023 2T11 64F 30 03 0a 00 00 00 00 00 V (62207) canlog-monitor: 62.146658 2R11 65F 21 37 08 02 e9 63 08 02 V (62227) canlog-monitor: 62.165585 2R11 65F 22 ed fb 08 02 db 3a 55 Code committed, and working in my car. Regards, Mark

1 0

File logging task
by Michael Balzer 04 Jul '20

04 Jul '20

Everyone, I've pushed the long due refactoring of the file logging into a dedicated task. This removes most of the delays involved in file logging, as the fsync() and log cycling now is done in the logging task and no longer blocks overall log message processing. I stumbled upon a bad thing (tm) though we need to resolve with logging: the esp-idf logging generally involves a semaphore wait of max 10 ms (!). I wasn't aware of this because I didn't look into the source before, there also is no warning about this in the esp-idf documentation (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/…) so I guess I'm not the only one being taken by surprise here. // Maximum time to wait for the mutex in a logging statement. #define *MAX_MUTEX_WAIT_MS 10* #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS + portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS) … void IRAM_ATTR *esp_log_write*(esp_log_level_t level, const char* tag, const char* format, ...) { if (!s_log_mutex) { s_log_mutex = xSemaphoreCreateMutex(); } if (*xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS*) == pdFALSE) { return; } … That semaphore is needed to secure the log level tag cache against parallel access, so it also affects log messages of currently disabled tags and/or levels. This means we *must not* use the standard logging from timer callbacks, at no verbosity level. But we do, partially caused by my own code serving as a bad example I assume -- sorry. But I've not only found direct log calls in most vehicle timer callbacks, there also are some hidden ones from calling the framework, for example marking a notification as read can produce a log output from Cleanup() if tracing is enabled. We need to change this short to mid term. This may be the cause of those strange timer overflow issues we've seen occasionally. It also means every debug or verbose log output currently in the code involves potentially multiple semaphore waits, that's for example the case for all hex dumps logged by the SIMCOM module. Our primary option is to remove all log calls from all low level framework functions and timer callbacks. A simple & quick workaround could be to extend the ESP_LOGx macros to check if they are executed in the timer task context, if so suppress the message or call the ESP_EARLY log function instead. That will hide these log messages from the logging framework though, if using the _EARLY_ variant they only will be sent to the USB port. For a better solution I thought about adding a dedicated queue & task for the initial log submission as well. That will need quite some rework to the esp-idf (no changes for this in the current master) but would allow to continue logging as we do now. Cons: queue submission involves some overhead & RAM, printf format expansion needs to be done before the tag/level check, messages may need to be dropped if the task starves or RAM gets tight, log output to consoles will depend on a task as well. Opinions / better ideas? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 5

Android App 3.16.2 (fix maps not showing)
by Michael Balzer 01 Jul '20

01 Jul '20

A new release was necessary to fix the maps view not showing map images anymore or not loading new details outside the cached area. The maps API key previously used did not belong to the OVMS developer account. I assume it's been deleted or blocked by Google or the actual owner. I have replaced that key by an OVMS key. Unfortunately the Google Play Console is currently not working, so the release via the Play Store is delayed. If you're in a hurry, you can download the new APK from the repository: https://github.com/openvehicles/Open-Vehicle-Android/tree/master/release Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0