Lots of code changes later, I'm finally happy with the state of things - at least on iPhone - I have yet to test with an Android phone.  The device is able to reliably reconnect when a phone comes back in range and other functionality seems stable.  And it seems to handle all the possible situations with audio routing and various bluetooth low-level notification traffic.

Fast Support from Espressif

I found a bug in the Espressif low-level (binary blob) Bluetooth library that would crash the app (StoreProhibited) if the phone was at the edge of Bluetooth range.  At night I sleep with the phone on a nightstand across the house from my lab.  I leave weeBell running and logging output and in the morning I noticed it would crash and reboot many times overnight.  Sometimes with a cryptic error from the low level code.  I dove into the Bluedroid library port but was soon stymied by the lack of source for this library so I posted a bug report on Espressif's IDF repo late one night.  Much to my surprise there was a response the next morning from an engineer saying to try a version of the library they had published two months prior (I thought I was up-to-date but I wasn't).  Boom!  That fixed it.  The engineer then checked back with me a couple of days later to see how I was doing.  I was really impressed. 

A compromise in security

I hope to be able to use the modern Bluetooth Secure Simple Pairing (SSP) mechanism to pair weeBell with a phone.  Although in reality this gadget probably doesn't need to be incredibly concerned with security I wanted experience  with this part of the specification and the Espressif implementation supports it. 

The old PIN method of pairing devices is insecure.  It can be snooped and has the potential for a man-in-the-middle attack.  SSP uses cryptographic means to protect both sides and has several mechanisms for user confirmation as well.  My implementation displays a 6-digit code on the GUI in a pop-up dialog box and the same 6-digit code should be displayed on the cellphone during pairing.  The user confirms both match and the pairing is completed.

Only the iPhone displays a dialog box asking if you want to share your address book instead of the 6-digit code.  So the pairing can't be confirmed back to weeBell (although the iPhone thinks it has successfully paired!).

What is interesting is that the pairing process creates a bonding record in the ESP32 NV storage (where it stores remote devices MAC addresses, keys and the like) even though my code never got the callback indicating authentication had been successful.  Before I updated to the new low-level library I would get a callback indicating the iPhone wished to pair around a minute later and both my code and the iPhone would display the dialog boxes with the code and they could complete the pairing.  However after I updated the low-level library this no longer occurred so there was no way to pair with my iPhone.

Long story short, I ended up - at least for now - falling back to the older PIN style of pairing and that works.  At least I don't use the pins 0000 or 1234 - and my device only advertises itself for discovery during the 30 second max pairing window when the user presses Pair.  

Hopefully over time this can be figured out.

The current ESP32 Bluedroid implementation does not support the PBA or PBAP (phone book) profiles.  These are what your car uses, for example, to display the name of who is calling and to let you access your phone's address book from the car's touchscreen.  I submitted a feature request so hopefully Espressif will support this someday and then I'll add support for it in the GUI.  But it's still strange the iPhone displayed this message when the device it's connecting too doesn't support it.  I wonder if either Apple simply assumes any HFP device will support PBAP or if the ESP32 is advertising something it doesn't do (I looked very hard through their code and saw no indication it does).  Apple should still be displaying the 6-digit code first though.

And speaking of iOS strangeness

As you might imagine I have placed a lot of calls to myself (between my weeBell/cellphone and my VOIP landline).  I also place a lot of bogus calls to test various edge conditions.  Dialing gets tedious so I started to place single digit bad calls.  The iPhone does not like this!  And displays the most un-Apple-like error message after a spinner runs for a minute or so:

If I was a security guy I'd definitely experiment with initiating invalid HFP calls from a Bluetooth device to see if that could open any interesting doors...  But I'm not, and time is short, so I'll just leave this here for your amusement.

New Boards Back

Next post will describe the adventures in bringing up the Rev 2 board.  I officially hate I2C...