I am creating a core bluetooth application and connecting to a peripheral device, is there a way for the peripheral to reject which centrals may connect to it? What if a random person scanned and found my peripheral devices broadcasted UUID and then broadcasted that UUID and tried to connect to it, how would I prevent this?
No, the iOS peripheral cannot prohibit centrals from connecting to it. However it has some tricks to disable the connection. When a dynamic characteristic is read:
return an error instead of the value of the characteristic,
don't respond to the request. This will cause the connection to stall and then break up after about 30 seconds.
Think of the advertisement as a real advertisement in the media. As many can see it as want. This is the same for iBeacons. You shouldn't rely any security on being hidden. (Wifi SSID broadcasting can be turned off but if your hotspot is not encrypted and authenticated, people with find you.)
Related
In a table view controller list, I have all the peripherals which had been connected before. When the app loads, I want to check whether each of the peripherals is reachable. By reachability, I mean whether the device is turned on or is in range. How to achieve that when I have just the UUID of the different peripherals in the list?
You test reachability by connecting (CBCentralManager.connect). If the device is advertising, you can scan again and rediscover it (CBCentralManager.scanForPeripherals), but generally speaking it's quicker and easier to just connect to known devices without scanning.
If you can connect and get a response, then it's reachable. There is no other way to know that something is reachable. (The same is true of any networking protocol. The way you determine that another node is available is you send a packet and get a packet back.)
Note that many BLE devices can only accept a single connection, and do not advertise when they are connected. So if some other device has connected to your peripheral, it may become invisible to you. Improving this generally requires reworking the firmware.
I have MFi device which uses BLE for control and Classic Bluetooth for audio streaming.
In the App, i use coreBluetooth framework to scan BLE and EAAccessory framework to scan Classic Bluetooth.
I don't want the BLE of target device to be connected if its Classic Bluetooth is not yet connected. So i need to know which EAAccessory is corresponding to target CBPeripheral.
I am familiar with coreBluetooth, there is UUID string to identify the CBPeripheral. But it looks not exist in EAAccessory.
I have an idea but not sure: maybe firmware side can config EAAccessory's serial number and CBPeripheral's manufacture data in advertisement data with the same
serial number, so that App side can check if they are the same.
Dose anyone knows the general way to implement this in App side and firmware side?
I really do not think there is s relationship between the 2. BT and BTLE are managed by different chip at peripheral side and phone side.
Usually in BT you use the MAC address to identify the peripheral on BTLE side the MAC address is not used anymore since iOS at the first connection give its own identifier to the peripheral.
What you can do is probably at firmware side, by exposing a service with a characteristic that somehow relate the 2.
UPDATE AFTER COMMENT
I see, as far as I know there a best practice doesn't exist.The worst part is that you have to handle connections differently, mostly due to how connection are made on iOS side. While on the BLE you can choose a not encrypted connection that would not require paring or bonding, on BT side I guess that bonding is required.
Probably the most simple flow would be, user bond the BT device. Once you are in the app and detect the connected BT device, use a scan method for detect BLE companion device by filtering for a specific service id that your device exposes, once you do that you can also filter discoveries using BLE name without still making a connection.
Adv packet are restricted in size (29 usable byte) but you can also use the scan response (31 byte), that exposes some additional properties such as manufacturer data that will be exposed in a dictionary (kCBAdvDataManufacturerData).
Once you know that is the correct device you can start a connection, that does not require pair or bond but is NOT encrypted (Pair and Bond will require the user to accept the connection inside your app).
I have an app that acts as a Bluetooth LE peripheral. I have a single service with four characteristics. 2 out of the 4 are read and write only, the other two are configured as notify.
If I subscribe to one of the "notify" characteristics then the app will not disconnect until I do so manually, works well.
My issue is, If I read or write to the other characteristics, and the then am inactive for around 30 seconds, the BTLE connection disconnects from the peripheral. This may be a limitation set by apple, not sure.
Anyone know of a solution to keep the peripheral active even when there aren't any subscribers and no read or write command has been received in 30 seconds??
This is a by-product of the BLE 4.0 specs. Bluetooth Low Energy is explicitly designed to not maintain a connection for long periods which is what you are describing.
The only way to bypass this (beyond subscribing to a characteristic as you have found) would be to modify the implementation of the BLE stack on the peripheral you are connecting to and removing or elongating the interval of connection to a point that you find satisfactory.
Although this may not help you either as both sides of the BLE communication negotiate these values and iOS may impose a maximum below your requested threshold.
In my case reason was in a mismatch between characteristic properties. I wrote data to a characteristic with "waiting for response" option, but characteristic was in 'without response' state.
The symptom: write callback in delegate does not work when BLE peripheral did not write a response.
iOS Bluetooth Smart.
We have few central devices and one pheripheral devices. How to send from pheripheral device request to one of centrals?
iOS support something like "direct advertising"?
Bluetooth peripherals are supposed to be used as advertisers that the Centrals can find and connect to. Not the other way around. Basically you need to set up your peripheral with service/s that the Central is scanning for. After the central discovers the peripheral, it can then choose to connect, and then exchange additional data between the devices.
Check out the Bluetooth Developer Site for more information.
I'm trying to use an iOS BLE device as BLE peripheral which also advertises in background.
I already figured out how to advertise in background and got it detected by another device looking for the specific bluetooth UUDID.
Unfortunately the advertiser-info is not transmitted when the app is in background. Is there a way to send a short string or something else device specific when the app is in background? It would be ok if the app would be woken up for a short period (if this is possible).
The advertised services are removed from the advertisement packages when the app is backgrounded. Only foreground scanning iOS devices will be able to obtain the services.
The advertised services are arbitrary UUIDs. You can easily figure out some encoding to store characters in them. However, this has several caveats, like
the general scheme is usually that the scanner finds your peripheral by the service UUIDS. If the data can be anything, then this is tricky.
the peripheral will not be able to change the advertisement data while backgrounded.
I suggest you not try to trick around with the system. Rather plan for connecting to the peripheral for a short time and sending the data to the central during this interval.