BlueZ on i.MX25 : Can't connect RFCOMM socket: Operation now in progress
It turns out the target device was requesting authentication from my i.MX25 board.
Usually, PIN code handling is done by using bluetooth-agent.
But this agent wasn't actually installed on the board (I thought it was...), so I had to manually provide the requested PIN code.
This is how I did it :
- edit /etc/bluetooth/rfcomm.conf, like I previously did
- "Up" the local bt adapter : hciconfig 0 up
- Enable page & inquiry scanning : hciconfig 0 piscan (I'm not sure about this one)
- Disable simple pairing : hciconfig 0 sspmode 0
- Edit (or create) /usr/var/lib/bluetooth/00:15:83:44:39:E2/pincodes
- In "pincodes" files, add line (no quotes) : "00:07:80:5A:48:93 045678"
- Manually start bluetooth daemon : bluetoothd
00:15:83:44:39:E2 is local device bluetooth address.
00:07:80:5A:48:93 is target device bluetooth address.
045678 is target device PIN code.
l2ping works :
# l2ping 00:07:80:5A:48:93
Ping: 00:07:80:5A:48:93 from 00:15:83:44:39:E2 (data size 44) ...
4 bytes from 00:07:80:5A:48:93 id 0 time 13.14ms
4 bytes from 00:07:80:5A:48:93 id 1 time 26.34ms
rfcomm connect works :
# rfcomm connect 0
Connected /dev/rfcomm0 to 00:07:80:5A:48:93 on channel 1
Press CTRL-C for hangup
Update 06.15.2015
Today I tried l2ping on that target device again, as previously described. For some reason, it would throw me a "Permission denied" error.
This is what I figured out as a workaround :
- Save /usr/var/lib/bluetooth/00:15:83:44:39:E2/pincodes somewhere else
- Remove everything under /usr/var/lib/bluetooth/00:15:83:44:39:E2
- Reboot
- Put your saved pincodes file back under /usr/var/lib/bluetooth/00:15:83:44:39:E2
- Retry pinging as previously described
Admin
Updated on June 17, 2022Comments
-
Admin almost 2 years
I'm trying to connect to a bluetooth device on embedded linux.
- BlueZ version is 4.101.
- Local bluetooth adapter is an USB Bluetooth dongle Trendnet TBW-107UB, for all tests.
- I can't provide details about the target device, as it is a product of the company I work for, sorry.
Using the method described at this page works fine on Desktop Linux Mint 17 x64, and on RiotBoard (i.MX6) Linaro Ubuntu.
However, I can't get an i.MX25 board (embedded custom Linux) to connect to the target device. Only scan works.
rfcomm.conf
rfcomm0 { # Automatically bind the device at startup bind yes; # Bluetooth address of the device device 00:07:80:5A:48:93; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; }
hciconfig -a output
hci0: Type: BR/EDR Bus: USB BD Address: 00:15:83:44:39:E2 ACL MTU: 384:8 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:28633 acl:0 sco:0 events:204 errors:0 TX bytes:899 acl:0 sco:0 commands:60 errors:0 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Name: 'Bluetooth2.1+EDR CLASS1' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 2.1 (0x4) Revision: 0x149c LMP Version: 2.1 (0x4) Subversion: 0x149c Manufacturer: Cambridge Silicon Radio (10)
rfcomm connect output
# rfcomm connect 0 Can't connect RFCOMM socket: Operation now in progress
hcitool cc output
# hcitool cc 00:07:80:5A:48:93 Can't create connection: Connection timed out
l2ping output
# l2ping 00:07:80:5A:48:93 Can't connect: Invalid exchange
While google searching, the only relevant thread I could find suggests that the rfcomm connect output could be due to a kernel 2.6.27 regression, but mine is 3.10.28 (used uname -r).
I tried with two other target bluetooth devices (of different type), the problem remains the same.Any help is appreciated, thank you!
Edit
Rfkill block / unblock didn't seem to change anything.