[Thali-talk] Testing BLE discovery and Bluetooth connectivity in Android land
Michael Rogers
michael at briarproject.org
Wed Mar 2 06:30:24 EST 2016
Hi Yaron,
You've probably already noticed this in your testing, but just in case,
I wanted to give you a quick heads-up about some issues I've run into
while testing Bluetooth connectivity.
Some devices will remember that you declined to pair with another device
and subsequently refuse connections from that device - this may include
insecure RFCOMM connections, which don't require pairing (I haven't been
able to confirm this because there's no explicit indication that the
connection was refused, it just fails, so the cause could be something
else).
Some devices will cache recently discovered devices, so discovery
happens much faster on subsequent tries.
Devices that support automatic pairing (I can't remember what Bluetooth
version introduced it - it's the same key exchange as manual pairing but
without the PIN confirmation) may pair with each other when you make an
insecure RFCOMM connection.
These issues make it difficult to isolate the results of different tests
- the only workaround I've found is to factory reset the devices between
tests, which is obviously very time-consuming. The last issue might also
be considered a privacy issue, as it creates a record of which devices
you've communicated with.
Cheers,
Michael
On 02/03/16 01:10, Yaron Goland wrote:
> Note: This is going to the public mailing list
>
>
>
> Devices –
>
> HTC One M9 –Android 6 with android security path level 2015-12-01
>
> LG G4 – Android 5.1 w/Android Security Patch Level 2016-01-01
>
> Nexus 6 – Android 6.0.1 w/Android Security Patch Level 2016-02-01
>
>
>
> Setup – I turned off wifi direct support
>
>
>
> Test #1 - For the first tests I took the native client and I tried to
> connect one client to one server. I made sure that the other devices
> were not running the test app and before each test I turned off the apps
> and restarted them. In all cases but one discovery was reasonably snappy
> and the first connect and disconnect was instantaneous and clearly
> viewable on both devices. In all cases the second connect failed. My
> details notes are recorded in [1].
>
>
>
> Test #2 – I tried to connect two devices to one server. I would first
> establish a connection from one client and then from the other. In all
> cases the second connection timed out. I looked at the latest BTLibrary
> code and it seems to support multiple simultaneous Bluetooth connections
> so I don’t understand why these tests failed. They should not have.
> Results are recorded in [2].
>
>
>
> Test #3 – I tried to connect all three devices in a circle. That is,
> device 1 to 2, 2 to 3 and 3 back to 1. This worked in all cases. [3]
>
>
>
> Test #4 – In this test I connected a single client to the other two
> phones as a server. I even sent actual data. Everything passed. [4]
>
>
>
> Test #5 – For Test #5 I picked a random application off the store, in
> this case Bluetooth Chat by Emparador. This does require pairing the
> devices. Which I did. But I was then able to send Bluetooth messages (I
> made sure WiFi was turned off) from each phone to the other two phones
> and I tested this with all the phones. The only real difference in the
> Bluetooth stack between a paired connection and an insecure RFCOMM
> connection is the later lacks encryption. Also, for entertainment value,
> I killed the Bluetooth Chat app on one of the phones and restarted it. I
> was instantly able to connect back to the other two phones and they to
> the phone I had turned off. So at least with pairing the Bluetooth stack
> can clearly behave itself.
>
> Questions:
>
>
>
> Why is the default buffer size 256 bytes? Why not say 10k? Or 100k?
>
>
>
> There was a consistent issue with the HTC seeing the Nexus multiple
> times in its listing. Why?
>
>
>
> Thanks,
>
>
>
> Yaron
>
>
>
>
>
> [1] ONE SERVER – ONE CLIENT
>
>
>
> Test - Connect client to server, disconnect, try to reconnect
>
>
>
> Server - HTC m9
>
> Client - Nexus 6
>
> Comment - It took the HTC a good 10 or 20 seconds to notice the Nexus
> but the Nexus saw the HTC instantly
>
> Test Result - Failed
>
>
>
> Server - HTC m9
>
> Client - LG
>
> Comment - The LG found the HTC quite quickly, the HTC though was only a
> tiny bit slower than the LG, much better than with the Nexus
>
> Test Result - Failed
>
>
>
> Server - Nexus
>
> Client - HTC
>
> Comment - The HTC found the nexus instantly but the Nexus took a tiny
> bit of time to find the HTC
>
> Test Result - Failed
>
>
>
> Server - Nexus
>
> Client - LG
>
> Comment - LG found the nexus instantly, the nexus took a few seconds
> more to find the LG
>
> Test Result - Failed
>
>
>
> Server - LG
>
> Client - HTC
>
> Comment - HTC found G4 instantly. G4 took a few more seconds to find HTC
>
> Test Result - Failed
>
>
>
> Server - LG
>
> Client - Nexus
>
> Comment - Nexus found LG instantly. The LG took a good 10 seconds to
> find the Nexus.
>
> Test Result – Failed
>
>
>
> [2] ONE SERVER – TWO CLIENTS
>
>
>
> In this test I first connect to the server with client 1 and then with
> client 2. The goal is to see if they can both connect.
>
>
>
> Server - HTC
>
> Client 1 - LG
>
> Client 2 - Nexus
>
> Result - Fail, The LG connected without issue but the Nexus could not
> connect, it got a time out.
>
>
>
> Server - HTC
>
> Client 1 - Nexus
>
> Client 2 - LG
>
> Result - Fail, Same as above but in reverse order
>
>
>
> Server - Nexus
>
> Client 1 - HTC
>
> Client 2 - LG
>
> Comment - The Nexus and LG found the other 2 phones instantly, the HTC
> found the Nexus instantly but took some time to find the LG
>
> Result - Fail on second, as with previous
>
>
>
> Server - Nexus
>
> Client 1 - LG
>
> Client 2 - HTC
>
> Comment - Unlike in the previous test, this time everyone found everyone
> else instantly
>
> Result - Fail on second, as with previous
>
>
>
> Server - LG
>
> Client 1 - HTC
>
> Client 2 - Nexus
>
> Comment - This time Nexus was the winner, followed a few seconds later
> by the LG followed a few seconds later by the HTC
>
> Result - Fail, on second, as with previous
>
>
>
> Server - LG
>
> Client 1 - Nexus
>
> Client 2 HTC
>
> Comment - This time the HTC found everyone first, followed by the Nexus
> with the LG lagging
>
> Result - Fail, on second, as with previous
>
>
>
> [3] THREE SERVERS – THREE CLIENTS
>
>
>
> Three Servers, Three Clients
>
>
>
> In this test I create a round robin between the devices. I connect
> device 1 to device 2, 2 to 3 and 3 to 1. I'm just testing that they will
> all connect to each other.
>
>
>
> Client 1 - LG
>
> Client 2 - HTC
>
> Client 3 - Nexus
>
> Result - Success
>
>
>
> Client 1 - LG
>
> Client 2 - Nexus
>
> Client 3 - HTC
>
> Result - Success
>
>
>
> [4] TWO SERVERS – ONE CLIENT
>
>
>
> In this test I take one client and have it connect to the other two
> phones. Strictly for entertainment value I also sent data.
>
>
>
> Client - LG
>
> Server 1 - HTC
>
> Server 2 - Nexus
>
> Comment - this time the LG was fastest followed several seconds later by
> the Nexus and then followed a good 30 seconds later by the HTC
>
> Result - Success
>
>
>
> Client - LG
>
> Server 1 - Nexus
>
> Sever 2 - HTC
>
> Result - Success
>
>
>
> Client - HTC
>
> Server 1- LG
>
> Server 2 - Nexus
>
> Result - Success
>
>
>
> (Skipping the second HTC test)
>
>
>
> Client - Nexus
>
> Server 1 - HTC
>
> Server 2 - LG
>
> Result - Success
>
>
>
> (Skipping the second Nexus test)
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <https://pairlist10.pair.net/pipermail/thali-talk/attachments/20160302/60f170a2/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://pairlist10.pair.net/pipermail/thali-talk/attachments/20160302/60f170a2/attachment-0001.pgp>
More information about the Thali-talk
mailing list