[Ovmsdev] Moving to a production cycle

Sun Feb 25 06:24:47 HKT 2018

Agree, WiFi's MAC is not useful as a passphrase or password, but I don't
think that we need to go to blowing fuses to solve this.

Michael, you are absolutely right that we shouldn't leave an open wifi
hotspot sitting there; it's an invitation for abuse.  But if we have a
static passphrase pre-set, and there is nothing one can do with the
module in that state - plugged in but not configured - I think that the
window for that abuse is going to be vanishingly small.  A new customer
will get the module and plug it in to either their car or (perhaps
better) a standalone USB power source, and then configure it.  It won't
be left powered but unconfigured for very long.  A new wifi AP
passphrase can be set during that configuration process (encouraged or
enforced), and the issue closed.

Especially these days, the most universally accepted means to configure
something is with a web server.  What you have done with the OVMS web
server is very well designed and executed, and I don't see any
significant issues with using that approach as the primary means for
configuring and managing the module. 

I spent a few minutes playing with it just now, and I think there are a
couple of extensions that would complete the package.  The biggest
disconnect I see between the webserver and CLI management approaches is
the role of files.  They are central to the CLI, with little files
sprinkled everywhere about the module.  For the config items, that's
well handled by both methods, but for events, that's a problem.  Perhaps
this is coming, but I currently don't see where the file tree is
visible, nor a facility for creating and editing them.  Are these
planned, or is there a different means for managing on-board files?

Finally, a use-case question.  Do we expect folks to be using the wifi
client along with the modem, for example, using the wifi connection
while at home or work to reduce cellular data fees, with the module
flipping over to cellular when on the road?  I guess there are two
reasons for asking...  First to understand what the connectivity and
management scenarios are, and second, the known difficulty in flipping
between the two connection stacks.

Since wifi can be either a client or an AP, not both, anyone using wifi
for management can't use it as a client, since there is no easy way to
move it back to being an AP.  Ok, I suppose an SMS command could turn on
AP mode...  Is that the intent?

As for flipping between cellular and wifi for connectivity to the
Internet-based server, the two currently are stepping on each other.  If
I have both enabled in my startup event script, wifi connects first and
I can see the status of the car within a second or two of booting.  Then
the modem connects, gets an IP address, and things get messy.  The v2
server thinks it connected, but it's not (or at least, no data gets
through).  Disconnecting from wifi (wifi mode off) doesn't fix it, nor
does turning off the modem.  I have to drop both connections and then
bring just one of them up.

I guess if this is inherently irreparable, the answer to my question
about the role of wifi is easy - it's there for local management only,
or in the rare case of client connectivity if in an area devoid of cell
service but with access to a home or work network.  If we do intend to
fix it (my hope), then one has options for connectivity and management. 
Perhaps this needs to be one of the introductory chapters in the user
guide...

Greg

Mark Webb-Johnson wrote:
> I’m not sure that Wifi MAC helps. That is broadcast as part of the WiFi station announcement, so using it as the password is really not any more secure than a fixed OVMS password.
>
> Printing the wifi MAC also would be troublesome, because it would have to be entered into some printing program, and labels individually printed. Messy. Hand-written would not be good.
>
> A better approach would be to come at it from the other way. Have the serial numbers / password stickers pre-printed in a large batch. Then, have the factory enter them into the number into the module during initial flashing / QC tests.
>
> There is BLK3 of eFuses, but I find those scary. Supposedly it is not used (other than for a custom MAC address), and there are 192/256 bits available. That would be a one-time flash. We could store the serial number as a locally administered MAC address there.
>
> It could also go into the flash as a configured parameter. That would be read/write (allowing someone to change the serial number).
>
> BLK3 is probably the correct way of doing things, but very scary. That is a one time write (it literally sends too much current down a little wire in the chip - burning it out), and not so easy to debug the code ;-)
>
> Regards, Mark.
>
>> On 24 Feb 2018, at 5:21 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>
>> Greg, Mark,
>>
>> I'm a bit concerned about an initially open Wifi access.
>>
>> I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car.
>>
>> We need to be -and stay- aware this may introduce a way to hack & hijack the system. You would for example scan for new OVMS wifi networks, do an automatic
>> passkey change to get access, then get the module to install a trojan firmware that mimicks the original behaviour (root kit style) and voila, you've got
>> another bitcoin miner. A normal user will never recognize something's fishy.
>>
>> With our current OTA function that's an unlikely attack vector, you would need to either control the GSM cell / DNS to redirect the download to your trojan site
>> or have hacked the openvehicles.com server to deliver your trojan firmware. But things will evolve.
>>
>> Some users may also not care about the Wifi access (i.e. using just Bluetooth / USB / GSM) and then not be aware it's actually active & open.
>>
>> Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user?
>>
>> If so we should at least make this very clear in the user documentation.
>>
>> Btw, the same password could be used as the default module password, or we could use the module password for both purposes.
>>
>> Regards,
>> Michael
>>
>>
>> Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:
>>>> There probably isn't a
>>>> need for a custom SSID based on MAC or other serialization; that would
>>>> only be necessary if configuring multiple modules at the same time in
>>>> the same place.  Use case?
>>> Yep. My thoughts exactly.
>>>
>>>> it might be
>>>> a good idea to have a required step of the configuration procedure be to
>>>> force a passkey change and re-connect on the part of the user.
>>> Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
>>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev