Does bluez support low energy pairing with ios devices? - ios

I have been beating my head on the wall with this project. I have an app built to an iPhone 5 that needs to communicate with my mac via bluetooth low-energy, and I want to do it through linux using the bluez protocol. I have my mac dual booted with ubuntu 12.04 and my iPhone app is connectible (acting as a peripheral), which I verified with lightblue. So, my question is, basically, is this possible? Will bluez support this type of connection, or will it only work if I use a dongle?
I have tried many different permutations of bluez. My linux kernel is 3.11.0. I think I am currently running bluez 4.98. I can get the hcitool to sense my app, then I use gatttool -b -I -t random which gives me the [ ][MAC.......][LE]>
then I type connect, I get
[CON][MAC.......][LE]> for about 15 seconds and then the CON goes away. That was the best I could do. Actually, at this point I'm not even getting that anymore. I'm getting any one of 3 errors. Either connection refused (111), could not create connection, or device busy (16).
Anyway, any help is appreciated!
Thanks.

To quickly answer your question, yes BlueZ DOES support pairing with iOS devices. That being said, the way Bluetooth Low Energy works is that you only need pairing if you want to perform an action on a characteristic (i.e. reading, writing, or enabling indications/notifications), and that characteristic requires pairing for that action to be performed. In other words, I think that the errors you are seeing are unrelated to pairing (since they occur before you do anything to the characteristics). I recommend that you try resetting the hci device with the command:
hciconfig hciX reset
Where hciX is the local hci device you are using.
If that doesn't work, try using #hcidump or #btmon to read the raw hci data and possibly get a clearer picture of what exactly might be happening.
If you want to make sure that you have a local hci device (and therefore meaning you wouldn't need a dongle), run the following command
hcitool dev
This should display the local hci devices. If the response is empty, that means that your Linux system is not using Apple's Bluetooth hardware, and that you probably need a dongle.
Also, watch out for other common errors, i.e. are you sure that your peripheral device is connectable, does it have proper implementation of services and characteristics, does the peripheral device have a random address (hence the -t random option?), are you sure you can see it from your linux machine (e.g. with the #hcitool lescan command), and if you are using the gatttool command correctly. There are a couple of good bluez questions on this site that might be beneficial to look at:
Using Bluetooth Low Energy from The Command Line
Bluetooth Low Energy Listening for Notifications/Indications
Raspberry Pi iBeacon Connection Timing Out
Attribute Requires Authentication Before Read/Write
Finally, when it comes to pairing, you have to increase the security level by passing "--sec-level=medium" or "--sec-level=high", e.g.
gatttool --sec-level=high -t random -b <MAC Address> --primary
or
gatttool -l high -t random -b <MAC Address> --primary
This should initiate the pairing process, and then result in a pop-window to appear asking you to accept the pairing request
I hope that this helps,

Related

iOS SMP Pairing Request doesn't set SC Bit

I'm using an iPhone XR to connect to my Linux 4.9 / Bluez 5.50 peripheral and want to use Bluetooth 4.2's Secure Connection pairing.
On my device, there are a couple of characteristics that require authentication, the agent for pairing is set up as "DisplayYesNo". After discovering the services and characteristics on the iPhone, I read a characteristic for the first time. As expected, a Bluetooth Pairing dialog pops up, but instead of asking me to compare numbers, I have to enter a passkey (that I show on the peripheral's display).
With btmon on the Linux side, I can see that after the "Insufficient Authentication" response from Linux, the iPhone sends a SMP Pairing Request, but doesn't set the SC bit. Everything works consistently, but I would have expected the iPhone to initiate pairing with SC enabled.
There is a rather brittle way to run the pairing with SC enabled: After the connection is established, Bluez' "battery" plugin runs on the Linux side, discovers the "Battery Service (0x180f)" on the iPhone and tries to read its characteristics. The iPhone responds with an Insufficient Authentication error by itself, Linux (as peripheral) sends an SMP Security Request with the SC bit set and then the iPhone issues a SMP Pairing Request with the SC bit set resulting in numeric comparison on both ends and public key exchange etc.
I can now "force" this second behavior by putting an arbitrary delay (3 seconds...) into the iOS app right after the successful connection before starting service and characteristic discovery and reading characteristics. That way the SC pairing due to the battery plugin likely has already started before I try to read from the authenticated characteristic within the app.
shudder What can I do to improve that?

The fastest way to connect to a known BLE device with firemonkey

the examples I have seen of BLE connection with Delphi / Firemonkey always start with a search for devices, then go to a service discovery to only then do the pairing.
This entire process takes about 5 seconds. I wonder if there is a faster way to connect to an already known device with known services and quickly send a command.

How to Find Latency of Other Connected Device via TCP Socket in IOS

is sending a message to the device which is connected via TCP Socket and calculate the time it takes to reply is the right approach?
The most common implementation for checking networking latency is based on ICMP packages and is called ping.
There is a nice and easy sample available from Apple.
Please note that even though the sample is provided for OSX, it should build and work fine on iOS as well.
Here are some additions I just found: splinter.com.au/how-to-ping-a-server-in-objective-c-iphone
I would go with ping as that way you would not have to build the "echoing" part yourself, that part is done by the remote system/network-stack.

iOS Wifi Network Notifications. (Knowing when I am home)

I am working on some home automation project and I am trying to use my iPhone as "I am home" sensor.
I tried
Reachability API (doesn't work in bg)
CLLocationManager and startMonitoringForRegion (too inconsistent and not accurate at all)
performFetchWithCompletionHandler (not predictable triggering)
Is there a way to notify that I am on a certain network?
I also tried the reverse approach of continuously scanning my lan, but other that seeming stupid it doesn't work and it's not scalable, iPhone goes in low power mode when it's locked and it just sends beacons, aka is not pingable, reachable.
Assuming:
I know the iphone mac address
IP may change over time
I can't access so DHCP logs
I can run a server on a raspberry pi to sniff (I don't like it)

Discover computers with my application installed on network

I am trying to build an app for iOS that can connect to computers running macOS or windows, and control a few stuff on those computers. Another application will be installed on those computers so that the app on iOS can connect to them. But at first I need to discover those computers in the network that has my app installed and running. What is a good way of doing that? I thought about using broadcasting, multicasting or bonjour. Are there any other options? Which one is best for my situation?
I am planning on doing two different applications for macOS and windows, one with objective c and other with c#, so the networking stuff should be available for both of those. Thanks in advance
The simplest option by far would be to use IP/UDP broadcast packets. The application on the computers (running whatever OS) can all sit there listening on a predefined UDP port (e.g. 9999), and when the iOS device wants to 'scan' the network, it will send out an IP/UDP broadcast packet with the destination port of 9999. Upon receiving the broadcast packet(s), the application on the computers can respond since it now knows the IP address of the iOS device, and you can take things from there.
The cleanest way to handle a computer leaving the network is for the application that is running on the computer to communicate this fact to the iOS device since it already knows the IP address of the iOS device. But if keeping a current list of computers is crucial, then some sort of a polling mechanism is unavoidable because the computers may crash for whatever reason without having the chance to send the bye-bye message.
Multicasting can be utilized as follows: computers periodically send IGMP joins for a predefined multicast group (e.g. 224.1.1.1), and iOS device sends the multicast UDP packet destined to 224.1.1.1 when it wants to 'scan' the network. The multicast UDP packet(s) will be received by the computers since they have already joined the multicast group of 224.1.1.1, and then the computers can start communicating with the iOS device now that the IP address is known. However, this seems overly complex, and does not really offer any advantages. The whole point of using multicast is to save bandwidth, but the amount of bandwidth saved will be minuscule. Unless you are going to send the same data in substantial quantities from the iOS device to all the computers, there is simply no reason to go down this path.
As for Bonjour, unfortunately I am unable to comment as I have no experience with it, but I would still vote for simple broadcasting to keep things platform independent... well, at least on the computers side. :)

Resources