In addition to minicom failing to be able to open /dev/rfcomm0 (see details below), we also noticed that rfcomm connect fails with this: Can't connect RFCOMM socket: Connection refused However, think I found something; Âhttps://bugs.archlinux.org/task/4930 Details bluez changed the pin_helper concept in the last release. If pairing with a device requires a PIN, then it will send a dbus-message. Unfortunately, there are currently no dbus helpers compatible with the new bluez dbus API. There is a small program called passkey-agent in the bluez-utils source, which solves this problem. If you call "passkey-agent --default <pin>" just before the pairing attempt, it will use the right pin. This program is built with bluez-utils, but make install ignores it. Fix: Add install -D -m755 $startdir/src/bluez-utils-3.1/hcid/passkey-agent $startdir/pkg/usr/bin/passkey-agent to the PKGBUILD. In bluez-4.71 (bluez4), there appears to be no more utils release; (last one was bluez-utils-3.36). Looking thru the source right now to see if there's some sort of equivalent utility. Anybody know what's up in the most recent release of bluez? Thanks in advance, -PEM ---------- Forwarded message ---------- From: Paul Matz <paul@xxxxxxxxxxxxxxxxxx> Date: Mon, Sep 20, 2010 at 1:11 PM Subject: Overo running OE 2.6.34 Bluetooth Serial Device; Problem: cannot open /dev/rfcomm0: Connection refused or No such file or directory To: gumstix-users@xxxxxxxxxxxxxxxxxxxxx We are trying to read input from a Bluetooth embedded serial device. We are using the bluez4-4.66-r7.0 stack in Open Embedded 2.6.34. We have been assuming that once the serial BT device pairs and connects, that we can use rfcomm to map it to a /dev/rfcomm0 serial device that we can open and read. The BT serial device is sending data out continuously. ÂWe find that we can pair it with other systems - Windows for example - and see serial data blasting out of it. A lot works, but not enough. ÂUnsure if pairing is happening successfully. ÂCan't seem to get debug info to turn on, Â(Tried launching bluetoothd with -d, but doesn't seem to help). Here's what we see. root@overo:~# hcitool scan Scanning ...    Â34:15:9E:90:D9:E6    ODG10050    Â00:12:A1:B0:5B:4A    SPP-B root@overo:~# hcitool inq Inquiring ...    Â34:15:9E:90:D9:E6    clock offset: 0x4129  Âclass: 0x38010c    Â00:12:A1:B0:5B:4A    clock offset: 0x3305  Âclass: 0x001f00 (The serial device, SPP-B, does have a weird class; not sure if this is OK or not). root@overo:~#Âhciconfig -a hci0:  Type: BR/EDR ÂBus: UART    ÂBD Address: 00:19:88:39:F3:90 ÂACL MTU: 310:10 ÂSCO MTU: 64:8    ÂUP RUNNING PSCAN    ÂRX bytes:1419 acl:0 sco:0 events:51 errors:0    ÂTX bytes:389 acl:0 sco:0 commands:26 errors:0    ÂFeatures: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80    ÂPacket type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3    ÂLink policy: RSWITCH HOLD SNIFF PARK    ÂLink mode: SLAVE ACCEPT    ÂName: 'overo-0'    ÂClass: 0x4a0100    ÂService Classes: Networking, Capturing, Telephony    ÂDevice Class: Computer, Uncategorized    ÂHCI Version: 2.0 (0x3) ÂRevision: 0xc5c    ÂLMP Version: 2.0 (0x3) ÂSubversion: 0xc5c    ÂManufacturer: Cambridge Silicon Radio (10) root@overo:~# hcitool info 00:12:A1:B0:5B:4A Requesting information ...    ÂBD Address: Â00:12:A1:B0:5B:4A    ÂDevice Name: SPP-B    ÂLMP Version: 2.0 (0x3) LMP Subversion: 0x10b7    ÂManufacturer: Cambridge Silicon Radio (10)    ÂFeatures: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80        Â<3-slot packets> <5-slot packets> <encryption> <slot offset>        Â<timing accuracy> <role switch> <hold mode> <sniff mode>        Â<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>        Â<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>        Â<power control> <transparent SCO> <broadcast encrypt>        Â<EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>        Â<interlaced iscan> <interlaced pscan> <inquiry with RSSI>        Â<extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>        Â<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>        Â<AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>        Â<EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features> root@overo:~# rfcomm bind 0 root@overo:~# rfcomm rfcomm0: 00:12:A1:B0:5B:4A channel 2 clean Processes running of interest: ÂÂPID TTY   ÂSTAT  TIME COMMAND ÂÂ874 ?    ÂS   Â0:00 /usr/sbin/hciattach -s 115200 ttyS1 csr 115200 noflow ÂÂ878 ?    ÂS<s  Â0:00 /usr/sbin/bluetoothd --udev ÂÂ884 ?    ÂS   Â0:00 /usr/bin/rfcomm -r watch 0 1 /sbin/getty -w -L rfcomm Devices of interest: root@overo:~# ls -alFgt /dev | head crw------- Â1 tty    4, Â66 Sep Â2 20:33 ttyS2 crw------- Â1 root   Â4, Â12 Sep Â2 20:33 tty12 crw-rw---- Â1 users  216,  0 Sep Â2 20:23 rfcomm0 crw--w--w- Â1 root   Â4,  1 Sep Â2 20:03 tty1 crw------- Â1 root   Â5,  1 Sep Â2 20:03 console crw-rw---- Â1 dialout  4, Â65 Sep Â2 20:03 ttyS1 Trying to attach to it using minicom fails: root@overo:~# minicom minicom: cannot open /dev/rfcomm0: Connection refused (sometimes the error isÂminicom: cannot open /dev/rfcomm0: No such file or directory) The suspicion is that we don't have the default pin configured correctly, even though we've put it into the right file. When security mode is set to user, there is suppose to be prompting for the pin, but this doesn't work. Attached below are some of the configuration files we have set up: /etc/default/bluetooth : HCIATTACH_ENABLE=true HCIATTACH_TTY=ttyS1 HCIATTACH_TYPE=csr HCIATTACH_START_SPEED=115200 HCIATTACH_SPEED=115200 HCIATTACH_HANDSHAKE=noflow HCID_ENABLE=true HCID_CONFIG="/etc/bluetooth/hcid.conf" SDPD_ENABLE=true HIDD_ENABLE=false #HIDD_OPTIONS="" HID2HCI_ENABLE=true RFCOMM_ENABLE=true RFCOMM_CONFIG="/etc/bluetooth/rfcomm.conf" DUND_ENABLE=false DUND_OPTIONS="--listen --persist" PAND_ENABLE=false #PAND_OPTIONS="--listen --role NAP" #PAND_OPTIONS="--role PANU --search --service NAP -sdp --persist" /etc/bluetooth/hcid.conf: options { autoinit yes; security none;      # tried auto & user here too... pairing multi; passkey "0000"; } device { name "%h-%d"; class 0x3e0100; #pkt_type DH1,DM1,HV1; iscan enable; pscan enable; lm accept,master; lp rswitch,hold,sniff,park; } device 00:12:A1:B0:5B:4A { name "SPP-B" } /etc/bluetooth/rfcomm.conf: rfcomm0 {    Âbind yes;    Âdevice 00:12:A1:B0:5B:4A;    Âchannel 2;    Âcomment "9 axis contoller Bluetooth device"; } /etc/bluetooth/main.conf: [General] Name = %h-%d Class = 0x000100 DiscoverableTimeout = 0 PairableTimeout = 0 PageTimeout = 8192 DiscoverSchedulerInterval = 0 InitiallyPowered = true RememberPowered = true #DeviceID = 1234:5678:abcd ReverseServiceDiscovery = true NameResolving = true DebugKeys = false -- Regards, Paul Matz Director, Software & Architecture Osterhout Design Group -Â153 Townsend St., STE 570, SF, CA 94107 Desk: 415 644 4030 ÂCell: 415 652 4077 -- Regards, Paul Matz Director, Software & Architecture Osterhout Design Group -Â153 Townsend St., STE 570, SF, CA 94107 Desk: 415 644 4030 ÂCell: 415 652 4077 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
