BlueZ on i.MX25 : Can't connect RFCOMM socket: Operation now in progress

16,498

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
Share:
16,498
Admin
Author by

Admin

Updated on June 17, 2022

Comments

  • Admin
    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.