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

Fri Sep 12 04:01:02 EDT 2014

I haven't read the SDP docs so your knowledge is deeper than mine at this point, but the blind grope is the only way I know of to connect to a device without any help from the user, and the only way I know of to connect to a device that isn't discoverable.

Even if the API were to expose the SDP methods, wouldn't you still need to know the MAC address of the device you wanted to search for UUIDs? So you'd still need to perform discovery or to get the MAC address out of band.

As far as I can tell from logcat output, discovery has two components: search for nearby devices, and query any discovered devices for services. By directly calling the SDP methods (e.g. via reflection) we could achieve the latter but not the former.

I think. Maybe.

Cheers,
Michael

Yaron Goland <yarong at microsoft.com> wrote:

>I really want to update the article correctly but I have to prepare for an exec review and so I can't just run through the code right now. But I was hoping I could just steal the answers I'm missing from your head.
>
>I looked at http://sourceforge.net/p/briar/prototype/ci/master/tree/briar-android/src/org/briarproject/plugins/droidtooth/DroidtoothPlugin.java and it seems that what it's doing, primarily in the poll method, is trying to blindly connect to all UUIDs it knows about in the hope that some are around.
>
>In other words, it doesn't look like you can say "Hey, show me all the SDP records for all devices around me even if I've never seen them before" and then use that to figure out who to connect to. Rather it seems like you have to 'magically' know the UUIDs of the devices you want to connect to and then you can just blindly try to connect to them. No pairing appears needed for the 'blind grope' though.
>
>I read through the SDP protocol a bit and it explicitly says that there is no requirement for pairing in order for a SDP client to perform discovery on a SDP server. So in theory there should be an API somewhere where one can ask Android to just tell you what devices are in the area. Certainly something like this is needed for the createInsecureRfcommSocketToServiceRecord call to work in the first place. But I don't see anything in http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.html or anywhere else where it's possible to just receive notifications about other devices 'showing up' if you aren't explicitly in discovery mode (and the UX that brings in).
>
>So is the 'blind grope' really the only way to connect to other Bluetooth devices without going into discovery mode (and having to show the user UX)?
>
>Thanks,
>
>    Yaron            
>
>________________________________________
>From: Michael Rogers <michael at briarproject.org>
>Sent: Thursday, September 11, 2014 12:00 PM
>To: Yaron Goland
>Cc: thali-talk at thaliproject.org
>Subject: RE: [Thali-talk] Yaron's Weekly Update - 9/8/2014
>
>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-----