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
        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:
  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 :

DUND_OPTIONS="--listen --persist"
#PAND_OPTIONS="--listen --role NAP"
#PAND_OPTIONS="--role PANU --search --service NAP -sdp --persist"


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"


rfcomm0 {
        bind yes;
        device 00:12:A1:B0:5B:4A;
        channel 2;
        comment "9 axis contoller Bluetooth device";


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

Paul Matz
Director, Software & Architecture
Osterhout Design Group - 153 Townsend St., STE 570, SF, CA 94107
Desk: 415 644 4030  Cell: 415 652 4077