Development with ESP32 - Thoughts

[Tazzi]

I am currently working with the ESP32 as the new wireless interface for the obdxpro series of cables, and have come across a bit of a dilemma.

The ESP32 supports whats called SSP (Secure Simple Pairing) and also legacy pairing.
The SSP allows pairing without any code, it just pairs instantly and without any mucking about, whereas legacy pairing is what we are all use to where you enter a pin such as 1234 which we commonly find on any old ELM327 with a HC05 glued to it.

From my 10+hours working on this today, I could not for the life of me get the legacy pairing to work at all. The ESP's design is it will default to SSP if the device being connected to supports it, whether or not you request it to be legacy pairing.

So here is the dilemma..
Is it a bad thing to simply roll with the SSP profile and allow any device to connect to the tool without a pincode? Or is legacy an absolute must?
Since even with legacy, if a default code such as 1234 is implemented (Like done with the HC05's), this is just as easy to connect to anyways.

The question has arisen due to the OBDX being able to have alot more capabilities the that of an ELM. Someone with the know how could do all sorts of damage to someones car in seconds by connecting and using a custom app, or even prebuilt ones now with the dawn of mobile tuning occurring.

I mean, I cant really think of any other better way of securing the connection But also who would leave a dongle connected permanently either.

The same can be said with WIFI, if a default password is set on it, it also becomes vulnerable to just anyone connecting to it.

If a custom password is set for both, it then becomes the issue of how to manage custom passwords for every single device

Any thoughts or input are greatly appreciated, Im a bit lost on how to resolve the situation.

[In-Tech]

Hi Tazzi,
I have seen many use a stored value and use that for a xor to complicate a dump and can easily be used for a simple calc before it gets to ram for processing.

[antus]

Personally I wouldnt worry about it, ive never seen the pin be used properly for security, and the small range of the device is usually enough to isolate it. Your right about what serious attackers could do, but its unlikely someone malicious with those skills are going to be within 20 meters of the car at a workshop ready to unleash some custom malware they wrote for a vehicle. Typically people with that level of skills have something better to do than implement such an attack and do it for real.

[Tazzi]

After the stupid time put into it and thinkg about it logically like that, yeah... if someone wanted to be malicious it would happen regardless

[Tazzi]

Well with that sorted. Took less then a day to have BLE,BT and WIFI all setup and running at the same time.
BLE and BT require broadcasting the same name, WIFI can have its own SSID.

What I found is all three can broad cast at once. Lightening quick communication when connected to one protocol, but as soon as you join two phones to two different protocols (BLE and BT), then communication becomes absolutely trash.

I believe I was connected to WIFI and BT at the same time and that seemed to not be so bad, but at least BLE and BT cant. Just means the firmware needs to be setup to only allow one connected device at a time.

[antus]

that makes sense, I think its only a single bluetooth module and low energy (polling) vs standard (broadcast) is two very different modes. It probably has to swap between them internally. i know other devices can do both at once, but ESP is very low cost. it works fine, but you just need to know its limits. like also its ADC is completely un-calibrated, so not good for much more than "that analog voltage is more or less than the last sample". Though thats more the 8266, im not sure if the 32 is better.

[Tazzi]

From my reading it does need to swap between them.
From practical testing, WIFI and bluetooth seem to get along much nicer then that of both bluetooths. Anything else it can do is outside of its purpose, since i needed a FCC approved device that does BLE, classic bluetooth and WIFI. Being FCC approved means in its current state, its legal to use for commercial products so long as its not used outside of its current permitted frequencies and limits. Technically speaking its recommended to have it retested/approved once putting it on a product, but if you keep within specs, even if its flagged/investigated then it meets regulations.

Its only being used as basically a passthrough for wireless connectivity. The only part Im a little unsure of until I try use it practically is the WIFI side as basically it is going to be used as a GET request almost where everything is appended to the URL (As done with ELMs).

Personally i think I would rather be using POST to put everything in the body of the request.. but maybe I can do something about that. And also I have never tried sending actual raw bytes, its always been strings, so yet to work out if thatll be an issue when switching to the DVI setup.

[Tazzi]

Figured as this is something I spent a fair bit of time on(more then Id like to admit), it might be for some other stranger out there.

The ESP is very fast processor, it will happily overrun its wireless buffers without any second thought, so much that it doesnt even get a chance to fire its interrupts to indicate queues or buffers are full or pending transmission resulting in loss of data.

Now looking specifically at the classic bluetooth, it does not have any methods to identify or even check when it has fully completed its transmissions wirelessly. It has "queues" and even a "transmission completed event", but even when checking these are empty, and event fired... its actually still technically sending the message in bluetooth stack.

It has inbuilt congestion routines which are essentially just wait loops to allow the bluetooth time to process a buffer before adding more into the queue. As soon as the congestion mode is hit, the wait loops are way longer then required, thus significantly dropping the transmission rate.

Solution has to put intentional delays between frames/bytes sent so the congestion mode does not occur. Doing so has reduced the read time on a P01 with the VT from 8min to 2:48min (using lsdroid). And changed the write time from 5min to 40seconds.
So its not a very technical fix, but it has made a world of difference.