I want to see the Bluetooth adapter details in terminal without using Bluetooth GUI. Initially Bluetooth is turned off both in terminal and GUI.
My commands for different functions in Terminal
View status of Bluetooth (it will show active/inactive and status in some cases, and just active/inactive in some other cases)
sudo /etc/init.d/bluetooth status
Turn on Bluetooth
sudo /etc/init.d/bluetooth start
Turn off Bluetooth
sudo /etc/init.d/bluetooth stop
View the Bluetooth adapter details
hciconfig
I can see the adapter details with the help of Bluetooth GUI in Settings GUI.
I researched the status of Bluetooth in different cases by doing following steps in order:
1. Turn on Bluetooth via terminal
Status = "Running"
Active = "active (running)"
Bluetooth adapter details: Doesn't display anything
2. Turn off Bluetooth via terminal
Status = Not shown
Active = "inactive (dead)"
Bluetooth adapter details: Doesn't display anything
3. Turn on Bluetooth via GUI
Status = "Running"
Active = "active (running)"
Bluetooth adapter details: Shows the adapter details
4. Turn off Bluetooth via terminal, but doesn't change in GUI
Status = "Quitting"
Active = "inactive (dead)"
Bluetooth adapter details: Shows the adapter details
5. Turn on Bluetooth via terminal
Status = "Running"
Active = "active (running)"
Bluetooth adapter details: Shows the adapter details
6. Turn off Bluetooth via terminal, but doesn't change in GUI
Status = "Quitting"
Active = "inactive (dead)"
Bluetooth adapter details: Shows the adapter details
7. Turn off Bluetooth in GUI
Status = Not shown
Active = "inactive (dead)"
Bluetooth adapter details: Doesn't display anything
Can someone please help me what's wrong in my commands? Also, why it works fine along with GUI? What does GUI actually do?
Give this tool a try:
bluetoothctl
Here is the installation guide:
(https://wiki.archlinux.org/index.php/bluetooth#Installation)
it gives you a lot of posibilities:
Menu main:
Available commands:
-------------------
advertise Advertise Options Submenu
scan Scan Options Submenu
gatt Generic Attribute Submenu
list List available controllers
show [ctrl] Controller information
select <ctrl> Select default controller
devices List available devices
paired-devices List paired devices
system-alias <name> Set controller alias
reset-alias Reset controller alias
power <on/off> Set controller power
pairable <on/off> Set controller pairable mode
discoverable <on/off> Set controller discoverable mode
agent <on/off/capability> Enable/disable agent with given capability
default-agent Set agent as the default one
advertise <on/off/type> Enable/disable advertising with given type
set-alias <alias> Set device alias
scan <on/off> Scan for devices
info [dev] Device information
pair [dev] Pair with device
trust [dev] Trust device
untrust [dev] Untrust device
block [dev] Block device
unblock [dev] Unblock device
remove <dev> Remove device
connect <dev> Connect device
disconnect [dev] Disconnect device
menu <name> Select submenu
version Display version
quit Quit program
exit Quit program
help Display help about this program
you can even drill down into the advertise policies and more:
# menu advertise
Menu advertise:
Available commands:
-------------------
uuids [uuid1 uuid2 ...] Set/Get advertise uuids
service [uuid] [data=xx xx ...] Set/Get advertise service data
manufacturer [id] [data=xx xx ...] Set/Get advertise manufacturer data
tx-power [on/off] Show/Enable/Disable TX power to be advertised
name [on/off/name] Configure local name to be advertised
appearance [on/off/value] Configure custom appearance to be advertised
duration [seconds] Set/Get advertise duration
timeout [seconds] Set/Get advertise timeout
clear [uuids/service/manufacturer/config-name...] Clear advertise config
back Return to main menu
version Display version
quit Quit program
exit Quit program
help Display help about this program
That is a lot of information you can pull (and set) directly.
Related
I see its adding a file to /var/lib/bluetooth/hci MAC/cache/ for each discovered device with its name as the address. Documentation says its creating device objects. Where and what are they, virtual dbus objects? ( ex: /dev_F8:41:1B:6B:95:2A). I know the device is removed after 3 minutes if not connected. And what else is it doing to make a device available for connecting with the bluez dbus interface. Thanks.
Bluetoothctl uses the Bluez DBus apis to do everything it does. When you do 'scan on' in bluetoothctl, it will call the StartDiscovery method of the Adapter object. Internally the Dbus will use the HCI interface to start a lescan. Once advertisement come in, Bluez will create objects for them on the Dbus and will send an InterfaceAdded or PropertiesChanged signals on the Dbus. Your application can listen to those signals which contain the address of the objects they are about.
We are developing small internet connected device that connects via wifi and does some work. It is controlled via mobile app.
For configuration purposes we use wi-fi module that can work in both STA + AP modes simultaneously via two interfaces wlan0 and wlan1. One of the interfaces works in Master mode. Phone connects to the device via wlan1 and sends command for the device to connect to another network and waits for result. Device in turn connects to another wi-fi network using wlan0 and notifies the phone if connection was successful or not.
But there is one issue. Both interfaces (wlan0 and wlan1) must work on the same channel as we have single hardware module. This causes channel of wlan1 to change in order to match of channel for wlan0.
Here comes the problem. When channel changes phone looses connection with the device. Is there a way to change wi-fi channel but keep connection between the device and mobile phone?
Our wi-fi module is rtl8723bu.
Linux 3.4.103.
Wifi daemons: hostapd v0.8.x_rtw_r7475.20130812_beta, wpa_supplicant v2.3.
UPDATE
Here is more clearly description what is going on on device.
Let's assume that the phone already connected to Device wlan1 interface with essid DeviceAp which is on channel 1. We have a Router with essid RouterAp which is on channel 6. Device interface wlan0 is not configured and not running.
(Step1 on image below).
Then the phone sends a request to the device to connect to RouterAp.
(Step2 on image below).
When wlan0 starts connecting to RouterAp it changes working channel. Because WiFi module can work only on one channel. The channel of wlan1 also changes (maybe in hard way). Therefore Phone lost DeviceAp and starts roaming.
(Step3 on image below).
SO the update question is:
Is there a way to tell the Phone (or other device) about network change? Or perhaps increase the likelihood that the phone is connected back to DeviceAP.
This behavior is very similar to the process of setting up Google Chromecast.
Chromecast also has two wireless interfaces and change the channel, but the Phone does not lose connection with it.
Image:
http://postimg.org/image/soh78vd17/
Description:
I have a small in-house device with bluetooth capabilities.
At the moment , other devices connect to that box.
Requirement:
Now we have to make it slave so that it get connected with other devices. I am wondering how to do it ? I don't need source code or anything just your views.
Additional Information:
The application uses Bluez libraires to send command to firmware/hardware and we extensively use HCItool.
Operating system :
Fedora.
I am also wondering , do I need to change chipset? From google it doesnt look like we need to change it.
Any help will be beneficial to us.
Thanks
From the command line, the way to achieve what you want is to use the #hcitool. However, you must first be connected. Try this sequence:
hcitool cc AA:BB:CC:DD:EE:FF #Connect to the device
hcitool con #To make sure you are in a connection
hcitool sr AA:BB:CC:DD:EE:FF <role> #switch master/slave role
If the output of "hcitool con" indicates that you are not in a connection, try the following sequence:
hciconfig hci0 sspmode 1
hciconfig hci0 piscan
sdptool add SP
rfcomm connect /dev/rfcomm0 AA:BB:CC:DD:EE:FF 1 &
hcitool con
hcitool sr AA:BB:CC:DD:EE:FF <role>
The above code is specifically for the serial profile, but it has worked for me on several occasions when 'hcitool cc' failed.
If you want to see the source code for this, open the tools/hcitool.c source file in the bluez directory and navigate to the function:
static void cmd_sr(int dev_id, int argc, char **argv)
This is the function that fires up the sequence for switching between master and slave role. Following this function you can see what exactly happens through the bluez stack.
I hope this helps.
I'm trying to set up a connection to a Bluetooth 4.0 LE device on Linux using the BlueZ 4.X DBus interface.
To test this I use the following command:
dbus-send --system --dest=org.bluez --print-reply /org/bluez/<PID of bluetoothd>/hci0 org.bluez.Adapter.CreateDevice string:<MAC of BT device>
This command seems to work most times, giving a result like:
method return sender=:1.238 -> dest=:1.262 reply_serial=2
object path "/org/bluez/9652/hci1/dev_BC_6A_29_26_C2_1C"
and enabling me to interact with the device DBus object.
However, starting from yesterday, this seems to fail very frequently returning the following error:
Error org.bluez.Error.Failed: Operation canceled
When debugging the bluetooth daemon, (using bluetoothd -n -d) I notice the following things when executing the method call:
bluetoothd[340]: src/adapter.c:create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/adapter.c:adapter_create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/device.c:device_create() Creating device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=2
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() Received 14 bytes from management socket
bluetoothd[340]: plugins/mgmtops.c:mgmt_connect_failed() hci0 BC:6A:29:26:C2:1C status 4
bluetoothd[340]: src/event.c:btd_event_conn_failed() status 0x04
bluetoothd[340]: src/device.c:device_remove() Removing device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=0
bluetoothd[340]: src/device.c:device_free() 0xb7ad8
As far as I can see, my Bluetooth dongle sends me an error event (status 4) when I try to connect to the device.
However, when I use hcitool ot gatttool to connect to the device, everything works perfectly.
I found that this happens mostly after I try to connect to the device using a different program (i.e cinnamon-settings), and cancel the connection prematurely. I also noticed this with other programs like bluetooth-properties on Angstrom.
My guess is that Bluez sends the wrong HCI commands to my bluetooth dongle in certain conditions. I think this is because the gui programs try to pair with the device instead of just connecting to it, which may cause BlueZ to think my device is a Bluetooth 2.0 device.
Thus far I seemed to be able to resolve this problem by connecting to my BT device using a gui application, waiting till it fails, and restarting my computer. However, the problem seems to reoccur occasionally, making this very painful.
I have seen this problem on systems running both BlueZ version 4.99 and 4.101.
Does anyone know how I can solve this correctly?
It seems like my predictions where more or less correct. After many hours of debugging the Bluetooth daemon I discovered that connecting to BT LE devices without a preliminary scan causes the daemon to try to connect to the device as a BR/EDR device. This is because the daemon's "internal cache" is filled with the EIR information at the time the device is discovered. If this information is not available when connecting to a LE device the CreateDevice method will fail.
A simple solution is to always make sure to discover devices before connecting to them.
The BlueZ 5 API introduction and porting guide also describes this problem, and how it is solved in BlueZ 5:
Bluetooth Low Energy essentially extended Bluetooth addresses with one extra bit, requiring one to always know whether an address is “random” or “public”. This caused issues with the BlueZ 4 API where the address was given to BlueZ in the CreateDevice and CreatePairedDevice calls. Since the parameter didn’t contain any of this extra random/public information bluetoothd had to maintain an internal cache to look up the necessary info. Another complication to the matter is that the BlueZ D-Bus API doesn’t differentiate between traditional BR/EDR devices and LE devices so there are essentially three possible address types: BR/EDR, LE public and LE random.
We have a custom embedded device that uses Roving Networks' RN240 bluetooth adapter on an RS232 port to communicate with another device via bluetooth. It is working well, but I am attempting to "bulletproof" the management of the bluetooth connection as there is an occasional hiccup and I need to handle these circumstances.
In the flow I'm working on, I put the adapter into Command mode and get back the proper response:
> CMD
< $$$
I am then able to issue commands to it to Get or Set information. One of the things we do is specify which bluetooth device to pair to using these commands. The device may already have a valid pairing, and is set to Auto Master mode. When the device powers up, it may automatically connect to our other bluetooth device (as designed). I need to know if the dongle has paired when I am attempting to perform certain functions.
The command set specification specifically says that when the Get command
> GK
< 1
is sent to the device (to obtain current connection status), it will respond with a "0" for "Not Connected" or "1" for "Connected"
I am occasionally getting a "4" when the device is either connecting or connected, and I've been unable to isolate why. Once I start getting a "4", I keep getting a "4" every time I inquire after that. I have to power down the dongle (ie: reset my test scenario) to get a different behavior.
I've poked through other Advanced User Guides on Roving Networks' website, and googled as many variations as I can think of to find what this status means. It seems when I get back "4", I can no longer control the Bluetooth Adapter as I need to. I would like to know what "4" means, and what I can do to recover the device so I can make it do what I want to!
Thanks! I appreciate any help.
(For reference, here's the page for this adapter, along with links for downloading the command set: Roving Networks RN240 Bluetooth Adapter)
EDIT: I have heard back from Microchip Engineering Support. Their answer was that "4" is an undocumented state, as it shouldn't be visible to the user. "4" means the chip in in a connecting state, and that if the module is getting into this state, it is recommended that the module be rebooted (with the "R,1" command).