[Thali-talk] Yaron's Weekly Update - 9/8/2014

[Michael Rogers]

I agree with most of what you've said about Bluetooth - the range and bandwidth are poor and discovering devices uses a lot of power. I'm not certain whether keeping a device discoverable uses a lot of power by smartphone/laptop standards, but it's a moot point on Android because you can only make the device discoverable for two minutes at a time, with user confirmation each time.

The good news is that you don't need discovery for every connection - once you know the MAC address you can connect to a device even if it's not discoverable. If you get the address out of band then you never need to use discovery.

Despite what the docs say, you can connect without ever having paired by calling createInsecureRfcommSocketToServiceRecord and listenUsingInsecureRfcommWithServiceRecord.

http://stackoverflow.com/questions/5885438/bluetooth-pairing-without-user-confirmation

We do this in Briar. Help yourself to the code in DroidtoothPlugin if it's useful, it's under Apache 2 now.

On other platforms there's a free Bluetooth stack called Bluez. Again, you can connect without discovery or pairing if you're prepared to live without Bluetooth's encryption or authentication - see BluetoothPlugin.

http://www.bluez.org/

I don't want to come across as some kind of Bluetooth zealot - it's got all kinds of problems, but on Android it's the least bad way of establishing a short-range p2p connection without excessively bothering the user... in my always humble opinion. ;-)

Cheers,
Michael

Yaron Goland <yarong at microsoft.com> wrote:

>eeek! I didn't realize that all connections require user confirmation. And apparently Google has no announced plans to fix this, see https://code.google.com/p/android/issues/detail?id=30880
>
>I also looked through the Bluetooth docs on Android and it doesn't look like a good choice either.
>
>I updated the section on Wi-Fi Direct and added a new section on Bluetooth to http://www.goland.org/thalimesh/
>
>I'd be curious to see your response to the Bluetooth section in particular.
>
>Thanks,    
>
>     Yaron            
>
>________________________________________
>From: Michael Rogers <michael at briarproject.org>
>Sent: Wednesday, September 10, 2014 1:14 AM
>To: Yaron Goland; thali-talk at thaliproject.org
>Subject: Re: [Thali-talk] Yaron's Weekly Update - 9/8/2014
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Yup, I was thinking of legacy mode - if you don't need to support
>legacy clients then I agree things are simpler. However, I believe you
>still need user confirmation to (re)join a Wi-Fi Direct group, which
>isn't the case with Bluetooth.
>
>Cheers,
>Michael
>
>On 09/09/14 17:23, Yaron Goland wrote:
>> Unless I'm misreading the documents I do not believe a password is
>> needed to let one Wi-Fi direct client connect to another. In other
>> words if I have say a Windows 7 laptop and an Android 4.x phone
>> then they can, completely from software and with no user
>> interaction, create a Wi-Fi direct group and join it.
>>
>> The password you mentioned I believe is only needed when dealing
>> with legacy clients. For example, if an Android 4.x phone creates a
>> Wi-Fi direct group that group will show up on an iOS phone as just
>> another SSID. But the Wi-Fi direct standard requires that the group
>> be secured by a password if it's going to be joined by a legacy
>> client. So that then brings up the password sharing problem you
>> described below.
>>
>> If we are to implement Wi-Fi direct functionality then we would
>> probably only focus on Wi-Fi direct enabled clients and not worry
>> much about legacy clients. The complexities of joining legacy
>> clients just seem beyond the grasp of most people.
>>
>> Yaron
>>
>>
>> ________________________________________ From: Michael Rogers
>> <michael at briarproject.org> Sent: Tuesday, September 09, 2014 3:36
>> AM To: Yaron Goland; thali-talk at thaliproject.org Subject: Re:
>> [Thali-talk] Yaron's Weekly Update - 9/8/2014
>>
>> On 08/09/14 21:29, Yaron Goland wrote:
>>> Last Week:
>>
>>> * *TL;DR - Squashed remaining known bugs, wrote up
>>> **instructions for writing a Thali app*
>>> <http://www.thaliproject.org/mediawiki/index.php?title=Guide_to_writing_apps_for_Thali>*and
>>
>>>
>>
>> published a **blog article* <http://www.goland.org/thalimesh/>*on
>> my
>>> research on mesh solutions for Thali (short answer: there are no
>>> good ones right now, so Wi-Fi direct is probably our best
>>> fallback)*
>>
>> Hi Yaron,
>>
>> Thanks for writing this article. I agree there's no mesh solution
>> that's ready for mass deployment on off-the-shelf devices, so we
>> need to look at single-hop solutions. I also agree that the biggest
>> problem with Wi-Fi Direct is getting the password from the AP to
>> the clients. QR codes would work, but on Android the SSID and
>> password are generated randomly each time a group is created - will
>> users be willing to scan a new QR code every time they want to
>> connect?
>>
>> Although it doesn't have built-in support for groups, Bluetooth has
>> a nicer user experience on Android - once you know the other
>> device's MAC address you can connect at any later time without
>> bothering the user. On Android and Linux you can connect without
>> pairing if you disable Bluetooth's encryption and authentication (I
>> assume you're providing your own anyway). I don't know about the
>> pairing situation on Windows or Mac.
>>
>> iOS devices won't communicate with non-iOS devices over Bluetooth,
>> but there's a new API that provides a wrapper around Bluetooth,
>> Wi-Fi Direct and normal Wi-Fi:
>>
>> https://developer.apple.com/library/ios/documentation/MultipeerConnectivity/Reference/MultipeerConnectivityFramework/
>>
>>  Some hype:
>>
>> http://www.wired.com/2014/03/apple-multipeer-connectivity/
>>
>> Cheers, Michael
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.12 (GNU/Linux)
>
>iQEcBAEBCAAGBQJUEAhNAAoJEBEET9GfxSfMYvsH/iGbtN052yZxiM9+/R+VUQvf
>vVUWIjjmhnHd+V3oF4a6AExf1lTb4ZuES1HRrJDnR5u/5YcO028eK5yT0+XY4Pai
>pffB3A+pk1C07JOXj46wt31w8Poua0nH3POmeEU36gns4pbsZ23KXYgEk/B4ueUG
>JvhOJ9eF9QGzvpjbUouACxJh1NrWTaEsidtX/v1T7lyu0+LFThjogQMisowmIM/C
>oNW09UUe78lI9TjFsqgwDWHQN4U8v9HSshFoDXMdlqsfer8N/0tYWg0XeUXj7L/p
>pM3/4JTTj5GvxNHG8d7KvpPndz7DgCJJ8ANb+qsypRfy3/tBYXxYZnxbfz6kxL4=
>=CGh6
>-----END PGP SIGNATURE-----