In general, two communicate between bluetooth devices, first we perform a bluetooth pairing between two devices and then starts further communication between them.
My problem scenario is simply to transfer a hello packet from one bluetooth device to another bluetooth device.
For this i am planning to use sockets programming technique i.e. RFCOMM sockets.
I got some help about this from http://people.csail.mit.edu/albert/bluez-intro/x502.html
So, my query is do we require bluetooth pairing between two devices before initiating communication with RFCOMM socket connection.
Or does 48 bits device address is only necessary to transfer some data packet from one bluetooth device to other and bluetooth pairing could be avoided.
No, it is not.
Bluetooth device can be in one of the four modes:
Broadcaster
Observer
Peripheral
Central
In broadcaster mode device can only send advertisement messages. This includes name and HwID.
In Observer mode device can only receive advertisement messages.
Peripheral = Broadcaster + can take in connect requests
Central = Observer + can send out connect requests.
If you have an application which does not want to connect use first two modes above.
Please let me know if this addresses your question.
Related
Is there a way in iOS or Android to set up a Bluetooth passkey passcode whenever another device wants to connect to my device via Bluetooth?
My application involves a BLE client connecting to a BLE server and the two devices will transmit data between each other. However, the data transmitted will be very sensitive security-wise. So beyond the standard encryption my goal is to not initiate data transmission until both devices have authenticated each other (e.g., with a passkey).
It seems like a Bluetooth passkey is something set up by the device manufacturer and not something able to be configured by the user. If so and there is no passkey pairing, would an acceptable alternative be to require a passkey to be exchanged (after the devices are paired) before the devices can transmit any sensitive data?
On a Android phone, assuming the phone is GATT server (which provides data for a client device to read), you can safeguard that data held in a characteristic by setting its read permission to PERMISSION_READ_ENCRYPTED_MITM .
For example, when you create a characteristic to be registered with the Bluetooth stack in Android, you do
BluetoothGattCharacteristic characteristic = new BluetoothGattCharacteristic(YOUR_UUID, BluetoothGattCharacteristic.PROPERTY_READ, BluetoothGattCharacteristic.PERMISSION_READ_ENCRYPTED_MITM)
In this way, anyone who wants to read the characteristic needs to create a secure bonding with your phone first, either by entering a passcode or compare two numerical values. The exact way for pairing is up to the Bluetooth stacks of both devices to negotiate (based on available IO on the client).
On the other hand, if the data you want to access is stored in a third remote device, and you don't need authentication (bonding/pairing) to read from it, and you cant access the firmware. Then you can not enforce secure transmission unilaterally from your phone.
What is the difference between Jackdaw and KillerBee on ZigBee USB Stick, both seem to be sniffing packet, but Jackdaw can act as a network interface, and KillerBee is only used for pentest? As far as I understand it, you can't use either to connect to like a hub or Wireless router, but only to ZigBee based devices, which would be the IoT devices such as sensors or smart socket etc.
Thank you
I am using BlueZ stack for Bluetooth connection between Smart-phone(AG-Audio Gateway) and Embedded board(HF-Handsfree).
On which layer of Bluez ( HCI, L2CAP, RFCOMM) we will get reason of Bluetooth disconnection. So we can differentiate following type of disconnection:
Smart-Phone SIMPLE DISCONNECT, but phone is still have HF Embedded device in its paired list.
Smart-Phone FORGET HF device during bluetooth connection.
Disconnection because HF device went out of Smart-Phone bluetooth Range
HCI: Disconnection Complete Event, check the Reason byte.
Say my platform or 'Bluetooth Controller' has support for only 1 SCO link over PCM. In this case can I still pair with multiple devices and communicate (Audio) with them alternately? Or my 'Bluetooth Controller' needs to have capability for multiple SCO links per PCM?
Yes you can still pair more than one devices, but only one attempt to connect SCO socket will succeed. Since you say 'communicate with them alternately' I think that can be accomplished by always call close() to current SCO socket, before connect() for the next one(to a different headset addr).
I want to clear of my basics before I Jump into more complicated matter of bluetooth. I have following basic question.
If there is two bluetooth devices(A phone and a bluetooth display). Is it that bluetooth connection is initiated only by the phone.
Suppose there would be lot of bluetooth communication happening from a phone to bluetooth display.Both devices can send messages to any other devices at any time. What is usual design approach of communication. Is it that the phone creates a Socket Connection to the bluetooth display through RFCOMM first time by sending a connect request to the Bluetooth device and this connection is maintained all the time or for every message the Socket connection is made and then socket is closed, after that again reopened and closed for next message.
If the connection is opened till the devices are in nearby range what are the consequences.
What is normal way of communication in case of phone and headset.
Can I get any reference so that i can get some knowledge about that.
1) In general, bluetooth connections can be initiated by either device. For example, with a phone and computer, you could start a connection from either side. With a phone and a display or headset, there may be no input interface on one device, so you would initiate connections from the phone. Devices can also auto-negotiate role switches such that they swap master/slave roles.
2) If you have continuous data to exchange, or require low latency, the connection would typically be left up. If you only have rare messages to exchange, tearing down the connection would save power because the devices are maintaining the connection synchronization by exchanging null packets.
3) You can't maintain a connection with devices out of range. If they can't communicate for some timeout period (on the order of seconds) then they lose sync and kill the connection.
4) Note that phone/headset are not using RFCOMM connections, rather the HSP (headset profile). Connections for isochronous voice data are inherently different than a sporadic data connection like RFCOMM.
5) A good way to see how "real" devices are communicating is to use tools like hcidump, as part of the linux blueZ stack. This lets you fully sniff the protocol messages that happen as you connect devices.