The link I had working quit. Help

The link I had working quit. Help

[Gene Heskett]

Greetings all;

I had minicom working fine till I reset the passkey on both devices, and now 
minicom says there is no /dev/rfcomm0 when there really is.

The init script I use here now reads:
----------------------------------
#!/bin/bash
echo attempting to get bt link to the coco3
hcitool -i hci0 11:11:11:11:11:11 key 4391
rfcomm release hci0
rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8
echo this should show the cocos address
rfcomm -i 11:11:11:11:11:11 show hci0
------------------------------------
and returns:
[root@coyote sysconfig]# connect2coco3

attempting to get bt link to the coco3
this should show the cocos address
rfcomm0: 11:11:11:11:11:11 -> 00:0C:84:00:86:F8 channel 1 clean

But minicom now says /dev/rfcomm0 doesn't exist, or after a couple of minutes:
-------------------------------
[root@coyote system.d]# minicom
minicom: cannot open /dev/rfcomm0: Host is down
-----------------------------

but it does exist:
[root@coyote sysconfig]# ls -l /dev/rfc*
crw------- 1 root root 216, 0 2009-04-04 16:20 /dev/rfcomm0

I am assuming that 'key' here is equal to 'passkey' on the other device.
Is that assumption wrong?

I'm also assuming that a short powerdown for the eb101 device at the other end 
will restore it to link mode after I quit the comm proggy on that machine, 
which probably puts the eb101 into the command mode with a +++ pause ATH.  I 
can train that program not to do that I think.

So, which end do I beat on here?, I'm getting lost in the forest, too many 
trees.

Thank you all.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Please state the nature of the technical emergency

Re: The link I had working quit. Help

[Gene Heskett]

On Saturday 04 April 2009, Gene Heskett wrote:
>Greetings all;
>
>I had minicom working fine till I reset the passkey on both devices, and now
>minicom says there is no /dev/rfcomm0 when there really is.
>
>The init script I use here now reads:
>----------------------------------
>#!/bin/bash
>echo attempting to get bt link to the coco3
>hcitool -i hci0 11:11:11:11:11:11 key 4391
>rfcomm release hci0
>rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8
>echo this should show the cocos address
>rfcomm -i 11:11:11:11:11:11 show hci0
>------------------------------------
>and returns:
>[root@coyote sysconfig]# connect2coco3
>
>attempting to get bt link to the coco3
>this should show the cocos address
>rfcomm0: 11:11:11:11:11:11 -> 00:0C:84:00:86:F8 channel 1 clean
>
>But minicom now says /dev/rfcomm0 doesn't exist, or after a couple of
> minutes: -------------------------------
>[root@coyote system.d]# minicom
>minicom: cannot open /dev/rfcomm0: Host is down
>-----------------------------
>
>but it does exist:
>[root@coyote sysconfig]# ls -l /dev/rfc*
>crw------- 1 root root 216, 0 2009-04-04 16:20 /dev/rfcomm0
>
>I am assuming that 'key' here is equal to 'passkey' on the other device.
>Is that assumption wrong?
>
>I'm also assuming that a short powerdown for the eb101 device at the other
> end will restore it to link mode after I quit the comm proggy on that
> machine, which probably puts the eb101 into the command mode with a +++
> pause ATH.  I can train that program not to do that I think.

I also set it to the other option of dropping the dtr, either way seems to 
leave the device dead.

>So, which end do I beat on here?, I'm getting lost in the forest, too many
>trees.
>
>Thank you all.

Ping! :)  I'm still dead in the water here.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Etiquette is for those with no breeding; fashion for those with no taste.

Re: The link I had working quit. Help

[Gene Heskett]

On Sunday 05 April 2009, Gene Heskett wrote:
[...]
Been playing with a script, step by step.  It gets to the line
hciconfig -a hci0 putkey 0000 (which is the default key at the other end of 
this link I'm trying to reliably establish)

The script:
----------------------------------
#!/bin/bash
echo attempting to get bt link to the coco3
echo "rfcomm release hci0"
rfcomm release hci0
sleep 5
echo "hciconfig hci0 down"
hciconfig -a hci0 down
sleep 5
echo "hciconfig -a hci0 up"
hciconfig -a hci0 up
sleep 5
hciconfig -a
sleep 5
echo "hciconfig -a hci0 noauth noencrypt nosecmgr"
hciconfig -a hci0 noauth noencrypt nosecmgr
sleep 5
echo "hciconfig -a hci0 putkey 0000"
hciconfig -a hci0 putkey 0000
--------which returns:
Can't find link key for 0000 on hci0
^C

And as you can see I killed it there.  What am I doing wrong?
-------------script continues----------------
sleep 5
echo "rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8"
rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8
sleep 5
echo "rfcomm -i 11:11:11:11:11:11 connect hci0 00:0c:84:00:86:F8"
rfcomm -i 11:11:11:11:11:11 connect hci0 00:0c:84:00:86:F8
sleep 5
echo this should show the cocos address
rfcomm -i 11:11:11:11:11:11 show hci0
-------------------------------
And it did yesterday morning before I broke it somehow trying to make a script 
that Just Worked(TM) :(

Where are the bluetooth guru's?  Or, where can I find the RFC documents that 
describe how all this is supposed to work?

What I want to  do, and was doing, is to run a system shell on the bt device 
on the other end, and minicom or picocom  to /dev/rfcomm0 as a remote terminal 
on that system.

Thanks everybody.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Learning French is trivial: the word for horse is cheval, and everything else
follows in the same way.
		-- Alan J. Perlis

Re: The link I had working quit. Help

[Gene Heskett]

On Monday 06 April 2009, jayjwa wrote:
>On Sun, 5 Apr 2009, Gene Heskett wrote:
>> Been playing with a script, step by step.  It gets to the line
>> hciconfig -a hci0 putkey 0000 (which is the default key at the other end
>> of this link I'm trying to reliably establish)
>
>Read your other mail; looks like you got it going. Possibly they need to
>re-pair? Sometimes clearing /var/lib/bluetooth/*  will help, or wherever
>bluetooth link key info is stored on your system. Sometimes it gets stale.
>
>Another idea is try to re-pair the devices. Are you running the
> passkey-agent and auth-agent?

What are those?  I never heard of them before.  I just built and installed 
bluez-4.34

>> The script:
>> ----------------------------------
>> #!/bin/bash
>> echo attempting to get bt link to the coco3
>> echo "rfcomm release hci0"
>> rfcomm release hci0
>
>This is strange that it works; the "release" refers to the rfcomm minor
>number, not the hci device number. It should be "rfcomm release 0", refering
>to rfcomm0.

It didn't.

I have bluez-4.34 installed on top of the rpm of 4.30.  I saw that mistake, 
and it said all according to the manpage, but I've set that to 0 now.

>> sleep 5
>> echo "hciconfig hci0 down"
>> hciconfig -a hci0 down
>> sleep 5
>> echo "hciconfig -a hci0 up"
>> hciconfig -a hci0 up
>> sleep 5
>
>I've never used the up and down commands. That should happen automatically.

Ok, I'll nuke those from the test script.

So that script now:

#!/bin/bash
echo attempting to get bt link to the coco3
echo "rfcomm release 0"
rfcomm release 0
sleep 2
ls -l /dev/rfcomm*
sleep 2
rfcomm -i 11:11:11:11:11:11 show hci0
sleep 2
echo "resetting hci0"
hciconfig reset hsi0
sleep 2
ls -l /dev/rfcomm*
sleep 2
rfcomm -i 11:11:11:11:11:11 show hci0
sleep 2
ls -l /dev/rfcomm*
sleep 2
echo "hciconfig -a"
hciconfig -a
sleep 2
ls -l /dev/rfcomm*
sleep 2
echo "rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8"
rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8
sleep 2
ls -l /dev/rfcomm*
sleep 2
echo "rfcomm connect 0 00:0c:84:00:86:F8 1"
rfcomm connect 0 00:0c:84:00:86:F8 1
echo this should show the cocos address
rfcomm -i 11:11:11:11:11:11 show 0


And the shell output is:
[root@coyote bin]# ./connect2coco3                        
attempting to get bt link to the coco3                    
rfcomm release 0 
ls: cannot access /dev/rfcomm*: No such file or directory 
Get info failed: No such device
resetting hci0
hci0:   Type: USB                                         
        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
        UP RUNNING PSCAN ISCAN                                    
        RX bytes:15003 acl:10 sco:0 events:440 errors:0<-note RX count, events         
        TX bytes:4548 acl:10 sco:0 commands:403 errors:0<-TX will increase

ls: cannot access /dev/rfcomm*: No such file or directory
Get info failed: No such device                          
ls: cannot access /dev/rfcomm*: No such file or directory
hciconfig -a                                             
hci0:   Type: USB                                        
        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
        UP RUNNING PSCAN ISCAN                                    
        RX bytes:15003 acl:10 sco:0 events:440 errors:0  <-note RX byte count
        TX bytes:4548 acl:10 sco:0 commands:403 errors:0          
        Features: 0xff 0x3e 0x85 0x38 0x18 0x18 0x00 0x00         
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3          
        Link policy: RSWITCH HOLD SNIFF PARK                      
        Link mode: SLAVE ACCEPT                                   
        Name: 'coyote.coyote.den-0'                               
        Class: 0x4a2104                                           
        Service Classes: Networking, Capturing, Telephony         
        Device Class: Computer, Desktop workstation               
        HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
        Manufacturer: CONWISE Technology Corporation Ltd (66)                 

ls: cannot access /dev/rfcomm*: No such file or directory
rfcomm -i 11:11:11:11:11:11 bind 0 00:0c:84:00:86:F8     
crw------- 1 root root 216, 0 2009-04-06 14:11 /dev/rfcomm0
rfcomm connect 0 00:0c:84:00:86:F8 1                       
Can't connect RFCOMM socket: Host is down                  
this should show the cocos address                         
rfcomm0: 11:11:11:11:11:11 -> 00:0C:84:00:86:F8 channel 1 clean 

[root@coyote bin]# cat /dev/rfcomm0  (gets nothing)
^C                                 

[root@coyote bin]# hciconfig -a
hci0:   Type: USB              
        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
        UP RUNNING PSCAN ISCAN                                    
        RX bytes:15671 acl:12 sco:0 events:456 errors:0 <-note byte count        
        TX bytes:4643 acl:12 sco:0 commands:411 errors:0          
        Features: 0xff 0x3e 0x85 0x38 0x18 0x18 0x00 0x00         
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3          
        Link policy: RSWITCH HOLD SNIFF PARK                      
        Link mode: SLAVE ACCEPT                                   
        Name: 'coyote.coyote.den-0'                               
        Class: 0x4a2104                                           
        Service Classes: Networking, Capturing, Telephony         
        Device Class: Computer, Desktop workstation               
        HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
        Manufacturer: CONWISE Technology Corporation Ltd (66)                 

[root@coyote bin]# hciconfig -a
hci0:   Type: USB              
        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
        UP RUNNING PSCAN ISCAN                                    
        RX bytes:15948 acl:12 sco:0 events:459 errors:0 <- increasing counts           
        TX bytes:4652 acl:12 sco:0 commands:414 errors:0 <-same for TX          
        Features: 0xff 0x3e 0x85 0x38 0x18 0x18 0x00 0x00         
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3          
        Link policy: RSWITCH HOLD SNIFF PARK                      
        Link mode: SLAVE ACCEPT                                   
        Name: 'coyote.coyote.den-0'                               
        Class: 0x4a2104                                           
        Service Classes: Networking, Capturing, Telephony         
        Device Class: Computer, Desktop workstation               
        HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
        Manufacturer: CONWISE Technology Corporation Ltd (66)                 

[root@coyote bin]# hciconfig -a
hci0:   Type: USB
        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
        UP RUNNING PSCAN ISCAN
        RX bytes:16225 acl:12 sco:0 events:462 errors:0 <-increased RX, events
        TX bytes:4661 acl:12 sco:0 commands:417 errors:0
        Features: 0xff 0x3e 0x85 0x38 0x18 0x18 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'coyote.coyote.den-0'
        Class: 0x4a2104
        Service Classes: Networking, Capturing, Telephony
        Device Class: Computer, Desktop workstation
        HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
        Manufacturer: CONWISE Technology Corporation Ltd (66)

[root@coyote bin]# hciconfig -a
hci0:   Type: USB
        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
        UP RUNNING PSCAN ISCAN
        RX bytes:16502 acl:12 sco:0 events:465 errors:0 <-RX, events up
        TX bytes:4670 acl:12 sco:0 commands:420 errors:0
        Features: 0xff 0x3e 0x85 0x38 0x18 0x18 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'coyote.coyote.den-0'
        Class: 0x4a2104
        Service Classes: Networking, Capturing, Telephony
        Device Class: Computer, Desktop workstation
        HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
        Manufacturer: CONWISE Technology Corporation Ltd (66)

[root@coyote bin]#

So traffic is indeed flowing!  But where to?

The device on the other end is sending a continuous string of
Coco3 at coyote.den
at about 3x/second

And it has an led that when connected, will blink on and off at 2 second 
intervals, but is not.  When it worked, it did blick correctly.

So traffic IS flowing, I just can't get the device to show it to me,  or get 
picocom or minicom to even find /dev/rfcomm0

[root@coyote bin]# cat /dev/rfcomm0
cat: /dev/rfcomm0: Host is down
[root@coyote bin]# minicom
minicom: cannot open /dev/rfcomm0: Host is down

Your comment about 
>Another idea is try to re-pair the devices. Are you running the
> passkey-agent and auth-agent?

Is another clue, but neither of those exist on this system.  What package are 
they part of?

I do have the bluetooth-wizard, which on its device display screen shows blank 
space where the device list should be.

bluetooth-analyzer shows a blank device list
bluetooth-sendto can select a file ok, but the next, send to device screen is 
also blank.

>> echo "hciconfig -a hci0 putkey 0000"
>> hciconfig -a hci0 putkey 0000
>> --------which returns:
>> Can't find link key for 0000 on hci0
>> ^C
>
>I've never used the command, but by its help screen you're using it wrong.
>That would refer to the bt device 0000, which isn't even a valid address
>format:
>
>putkey     <bdaddr>     Store link key on the device

Ok, understood, but where does it get the link key to 'putkey' then?>
The current version of the script doesn't have this command anymore.

>My advice would be not to manually attempt to handle the link key, but let
> the passkey-agent/auth-agent/whatever do it itself. Assuming blues-3.x
> here.
Now have 4.34

>> And as you can see I killed it there.  What am I doing wrong?
>> -------------script continues----------------
>> sleep 5
>> echo "rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8"
>> rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8
>
>This worked with no channel named? Then again, I don't know if one is really
>needed. Uncharted waters I'm heading into here...

Acc. the manpage, channel is optional, uses channel 1 if not given.>

>> sleep 5
>> echo "rfcomm -i 11:11:11:11:11:11 connect hci0 00:0c:84:00:86:F8"
>> rfcomm -i 11:11:11:11:11:11 connect hci0 00:0c:84:00:86:F8
>
>If you have only one local device, you don't need to tell it which one to
> use with -i, since there's only one choice to select anyway. So it could
> be:
>
>rfcomm connect 0 00:0c:84:00:86:F8 <channel>

I had a 'watch' running, stopped that: then
[root@coyote sysconfig]# rfcomm  show rfcomm0
rfcomm0: 11:11:11:11:11:11 -> 00:0C:84:00:86:F8 channel 1 closed
rfcomm connect 0 00:0c:84:00:86:F8  (a good 10 sec delay here)
Can't connect RFCOMM socket: Connection timed out

>
>Again, not sure about leaving off the channel part.
>
>> sleep 5
>> echo this should show the cocos address
>> rfcomm -i 11:11:11:11:11:11 show hci0
>> -------------------------------
>> And it did yesterday morning before I broke it somehow trying to make a
>> script that Just Worked(TM) :(
>
>I'd try to start fresh, with a re-pairing.
>
>> Where are the bluetooth guru's?  Or, where can I find the RFC documents
>> that describe how all this is supposed to work?
>
>If they're on the bt list, then they are silent. They never answer me there;
> I asked about getting bt headsets going under 4.x, and only one person
> remarked he thought he saw kernel messages. I'm assuming then that no-one
> uses headsets under 4.x. From the other questions on the list, no-one uses
> anything successfully under 4.x, unless you count /usr/bin/patch. Really
> I'm thinking of unsubscribing.

It doesn't seem to be all that helpful, you and I believe one other person has 
replied, always by personal email rather than the list.  That is not what 
keeping an archive of a list is all about. BTW, where is that list archive?

>> What I want to  do, and was doing, is to run a system shell on the bt
>> device on the other end, and minicom or picocom  to /dev/rfcomm0 as a
>> remote terminal on that system.
>
>When you get it going good, write the Howto. I'd like to read it ;)

Chuckle, So would I, like to read it that is! :)

/etc/init.d/bluetooth is also running.  kernel is 2.6.29.1-rc2 with all bt 
related stuffs enabled. lsmod |grep rfcomm returns:
[root@coyote bin]# lsmod|grep rfcomm
rfcomm                 35644  5
l2cap                  21260  16 rfcomm,bnep
bluetooth              52228  27 rfcomm,sco,bnep,l2cap,btusb

I went to google and looked up 'bluetoogh pairing' and got this:
http://www.bluetomorrow.com/content/section/180/284/
but no real howto.  And I did chase down quite a few other links, mostly for 
pairing with mobile phones or headsets, nothing on using them as a wireless 
rs232 circuit.  Which is what I want of course.

One more hciconfig -a after all that typing time:
hci0:   Type: USB
        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
        UP RUNNING PSCAN ISCAN
        RX bytes:17371 acl:12 sco:0 events:478 errors:0
        TX bytes:4729 acl:12 sco:0 commands:431 errors:0
        Features: 0xff 0x3e 0x85 0x38 0x18 0x18 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'coyote.coyote.den-0'
        Class: 0x4a2104
        Service Classes: Networking, Capturing, Telephony
        Device Class: Computer, Desktop workstation
        HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
        Manufacturer: CONWISE Technology Corporation Ltd (66)

Thank you jayjwa, and I appreciate very much your use of english as its the 
only language this old (74) fart knows.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My computer, my documents, my briefcase, my ASS!

   -- Ben Cook

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 7883 bytes --]

On Mon, Apr 06, 2009 at 02:57:02PM -0400, Gene Heskett wrote:
> The device on the other end is sending a continuous string of
> Coco3 at coyote.den
> at about 3x/second

Do you seriously have a Coco3 wired up to Bluetooth?  How?  Presumably not
with a native stack...some kind of dongle?

If you do have a Coco3 with a native Bluetooth stack...I want one.  ;)
The native Bluetooth stack, that is...I already have a Coco3 or two.

> And it has an led that when connected, will blink on and off at 2 second 
> intervals, but is not.  When it worked, it did blick correctly.
> 
> So traffic IS flowing, I just can't get the device to show it to me,  or get 
> picocom or minicom to even find /dev/rfcomm0
> 
> [root@coyote bin]# cat /dev/rfcomm0
> cat: /dev/rfcomm0: Host is down
> [root@coyote bin]# minicom
> minicom: cannot open /dev/rfcomm0: Host is down

Looks like it's bound to the wrong remote address, or the remote device
isn't listening for connections.

> Your comment about 
> >Another idea is try to re-pair the devices. Are you running the
> > passkey-agent and auth-agent?
> 
> Is another clue, but neither of those exist on this system.  What package are 
> they part of?

There is an agent written in Python named simple-agent in the Bluez
sources, under 'test'.  It's probably the closest thing to a simple
command-line utility.

> I do have the bluetooth-wizard, which on its device display screen shows blank 
> space where the device list should be.

Do you have any other Bluetooth devices to test with?  It would be
one thing if you can't see the specific device you're looking for,
but something else entirely if you can't see any devices *at all*.

> >> echo "hciconfig -a hci0 putkey 0000"
> >> hciconfig -a hci0 putkey 0000
> >> --------which returns:
> >> Can't find link key for 0000 on hci0
> >> ^C

You probably don't want to be using hciconfig or hcitool.  Use the DBus API
to talk to bluetoothd instead.

On Mon, Apr 06, 2009 at 02:57:02PM -0400, Gene Heskett wrote:
> On Monday 06 April 2009, jayjwa wrote:
> >On Sun, 5 Apr 2009, Gene Heskett wrote:
> >> Where are the bluetooth guru's?  Or, where can I find the RFC documents
> >> that describe how all this is supposed to work?

http://wiki.bluez.org/ has some HOWTOs that are somewhat out of
date but still useful as a starting point.  Bluez API documents
are in the bluez sources under doc/.  The Bluetooth specs are under
http://www.bluetooth.com/Bluetooth/Technology/Building/Specifications/,
but they're probably useless unless you want very high-level architectural
information, or you know exactly what technical detail you're looking for.

> >If they're on the bt list, then they are silent. They never answer me there;
> > I asked about getting bt headsets going under 4.x, and only one person
> > remarked he thought he saw kernel messages. I'm assuming then that no-one
> > uses headsets under 4.x. From the other questions on the list, no-one uses
> > anything successfully under 4.x, unless you count /usr/bin/patch. Really
> > I'm thinking of unsubscribing.

FWIW, I've gotten several bluetooth headsets to work under 3.36 and most
of 4.x for 20 < x < 34, using the A2DP profile and the bluez-alsa plugin
and the instructions at http://wiki.bluez.org/wiki/HOWTO/AudioDevices
which cover audio devices.

"My device doesn't work" questions on the mailing list often come down
to two common cases: either a) you will eventually get it to work by
following the wiki or reading the mailing list archives, so you don't
need an answer from a guru, or b) you won't get it to work because someone
(possibly you) has to write a patch, but the gurus are patiently waiting
for you to provide enough information to get started on one.

You may find it worthwhile to read the mailing list archives to see
what people have included in their postings that *do* get answers,
and see if you can supply something similar.

> It doesn't seem to be all that helpful, you and I believe one other person has 
> replied, always by personal email rather than the list.  That is not what 
> keeping an archive of a list is all about. 

I agree here.  If you get a private but helpful reply, please forward
it back to the list so that others can benefit from it.  If you are
providing a helpful reply, post it to the list so that people can find
it later.  ;-)

> BTW, where is that list archive?

vger.kernel.org mailing lists are widely distributed
and there are a number of public archives for them.  One is at
http://marc.info/?l=linux-bluetooth&w=1

I note that the link on www.bluez.org points to an error message on gmane.org.

> >> What I want to  do, and was doing, is to run a system shell on the bt
> >> device on the other end, and minicom or picocom  to /dev/rfcomm0 as a
> >> remote terminal on that system.

...but if the system is a Coco3, how is it doing Bluetooth?  I have
visions of a UART HCI Bluetooth dongle connected to the Coco3 and expected
to work as a RS-232 port...

> >When you get it going good, write the Howto. I'd like to read it ;)
> 
> Chuckle, So would I, like to read it that is! :)
[...]
> I went to google and looked up 'bluetoogh pairing' and got this:
> http://www.bluetomorrow.com/content/section/180/284/
> but no real howto.  And I did chase down quite a few other links, mostly for 
> pairing with mobile phones or headsets, nothing on using them as a wireless 
> rs232 circuit.  Which is what I want of course.

Here's a shot at a howto for a serial device.  This is kind of ugly,
and it occasionally uses brute force rather than the proper Bluetooth-
or BlueZ-compliant approach; however, I've managed to force quite a
few devices to work with procedures like this before I knew what I
was doing.  ;-)

Get the bluez source tarball so you have the 'test' directory.  In that
directly, you'll find 'simple-agent'.

Make sure the remote device is pairable (can't help you with that--the
procedure is specific to each remote device, and if the device isn't
pairable, no amount of trying from the bluez side will work).  Note that
some devices (especially things like mice and headsets) will allow only
one connection attempt after they're powered on, and whatever connects to
them has to pair with them on the first try--so if you mistype the PIN,
you might have to power the device back off and on again before you retry.

Run 'simple-agent hci0 <remote-device-bdaddr>'.  You should be prompted
for a PIN on both devices.  Use the same one.  ;-)

Run 'sdptool browse <remote-device-bdaddr>' (this will probably get me
flamed by others on this list ;).  This might give you a list of services
exported by the device.  It might not, in which case you probably want
to use the org.bluez.Device.DiscoverServices DBus API call, which will
give you a blob of XML you can decode with your handy-dandy copy of the
Bluetooth assigned numbers.  If sdptool works, you should get a list of
serial profile descriptions like this one:

	Service Name: Dialup Networking
	Service RecHandle: 0x10000
	Service Class ID List:
	  "Dialup Networking" (0x1103)
	  "Generic Networking" (0x1201)
	Protocol Descriptor List:
	  "L2CAP" (0x0100)
	  "RFCOMM" (0x0003)
	    Channel: 1
	Profile Descriptor List:
	  "Dialup Networking" (0x1103)
	    Version: 0x0100

The interesting parts are "Service Name" and "Channel".  There may be
multiple records, each with its own channel.

Run 'rfcomm bind /dev/rfcomm0 <remote-device-bdaddr> N' where N is the
channel number.  If you don't have success with 'sdptool browse,' you can
simply try channel numbers from 1 up to 15 or so.

Use a terminal program to see what you've connected to on rfcomm0.
Repeat with different channel numbers until you find what you're
looking for.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Gene Heskett]

On Monday 06 April 2009, Zygo Blaxell wrote:
>On Mon, Apr 06, 2009 at 02:57:02PM -0400, Gene Heskett wrote:
>> The device on the other end is sending a continuous string of
>> Coco3 at coyote.den
>> at about 3x/second
>
>Do you seriously have a Coco3 wired up to Bluetooth?  How?  Presumably not
>with a native stack...some kind of dongle?
>
Roger Taylor is selling a remake of the old Deluxe RS-232 pack, with an a7 
eb101 module taking the place of the db25 connector.  $65.  Uses the same old 
rs-232 drivers.  He is one of the movers & shakers of the coco list on 
maltedmedia.com.

>If you do have a Coco3 with a native Bluetooth stack...I want one.  ;)
>The native Bluetooth stack, that is...I already have a Coco3 or two.

Don't need one.  I had minicom connected through this bt dongle yesterday 
morning, and anything I could do from a shell on that machine, I could do from 
here with minicom talking to /dev/rfcomm0.

>> And it has an led that when connected, will blink on and off at 2 second
>> intervals, but is not.  When it worked, it did blick correctly.
>>
>> So traffic IS flowing, I just can't get the device to show it to me,  or
>> get picocom or minicom to even find /dev/rfcomm0
>>
>> [root@coyote bin]# cat /dev/rfcomm0
>> cat: /dev/rfcomm0: Host is down
>> [root@coyote bin]# minicom
>> minicom: cannot open /dev/rfcomm0: Host is down
>
>Looks like it's bound to the wrong remote address, or the remote device
>isn't listening for connections.

The bdaddr address is correct, 00:0C:84:00:86:F8, and that device has been 
reset to factory several times, meaning its pass key is 0000.

>> Your comment about
>>
>> >Another idea is try to re-pair the devices. Are you running the
>> > passkey-agent and auth-agent?
>>
>> Is another clue, but neither of those exist on this system.  What package
>> are they part of?
>
>There is an agent written in Python named simple-agent in the Bluez
>sources, under 'test'.  It's probably the closest thing to a simple
>command-line utility.

And the contents of the test directory are not part of the normal install I 
take it?
-------------------------------------[root@coyote test]# ./simple-agent
ERROR:dbus.proxies:Introspect error on :1.67:/: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents 
this sender from sending this message to this recipient, see message bus 
configuration file (rejected message had interface 
"org.freedesktop.DBus.Introspectable" member "Introspect" error name "(unset)" 
destination ":1.67")
Traceback (most recent call last):
  File "./simple-agent", line 86, in <module>
    path = manager.DefaultAdapter()
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in 
__call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in 
__call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 630, in 
call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A 
security policy in place prevents this sender from sending this message to 
this recipient, see message bus configuration file (rejected message had 
interface "org.bluez.Manager" member "DefaultAdapter" error name "(unset)" 
destination ":1.67")
----------------------------

D-Bus?  Another PIMA...
>
>> I do have the bluetooth-wizard, which on its device display screen shows
>> blank space where the device list should be.
>
>Do you have any other Bluetooth devices to test with?  It would be
>one thing if you can't see the specific device you're looking for,
>but something else entirely if you can't see any devices *at all*.

None at all now.  And I've tried both of these identical devices several 
times.
>
>> >> echo "hciconfig -a hci0 putkey 0000"
>> >> hciconfig -a hci0 putkey 0000
>> >> --------which returns:
>> >> Can't find link key for 0000 on hci0
>> >> ^C
>
>You probably don't want to be using hciconfig or hcitool.  Use the DBus API
>to talk to bluetoothd instead.

DBus api?  Does Fedora 10 have such a beast?  Not that I can find in kmenu.

>On Mon, Apr 06, 2009 at 02:57:02PM -0400, Gene Heskett wrote:
>> On Monday 06 April 2009, jayjwa wrote:
>> >On Sun, 5 Apr 2009, Gene Heskett wrote:
>> >> Where are the bluetooth guru's?  Or, where can I find the RFC documents
>> >> that describe how all this is supposed to work?
>
>http://wiki.bluez.org/ has some HOWTOs that are somewhat out of
>date but still useful as a starting point.  Bluez API documents
>are in the bluez sources under doc/.  The Bluetooth specs are under
>http://www.bluetooth.com/Bluetooth/Technology/Building/Specifications/,
>but they're probably useless unless you want very high-level architectural
>information, or you know exactly what technical detail you're looking for.
>
>> >If they're on the bt list, then they are silent. They never answer me
>> > there; I asked about getting bt headsets going under 4.x, and only one
>> > person remarked he thought he saw kernel messages. I'm assuming then
>> > that no-one uses headsets under 4.x. From the other questions on the
>> > list, no-one uses anything successfully under 4.x, unless you count
>> > /usr/bin/patch. Really I'm thinking of unsubscribing.
>
>FWIW, I've gotten several bluetooth headsets to work under 3.36 and most
>of 4.x for 20 < x < 34, using the A2DP profile and the bluez-alsa plugin
>and the instructions at http://wiki.bluez.org/wiki/HOWTO/AudioDevices
>which cover audio devices.
>
>"My device doesn't work" questions on the mailing list often come down
>to two common cases: either a) you will eventually get it to work by
>following the wiki or reading the mailing list archives, so you don't
>need an answer from a guru, or b) you won't get it to work because someone
>(possibly you) has to write a patch, but the gurus are patiently waiting
>for you to provide enough information to get started on one.
>
>You may find it worthwhile to read the mailing list archives to see
>what people have included in their postings that *do* get answers,
>and see if you can supply something similar.

And where are these archives?

>> It doesn't seem to be all that helpful, you and I believe one other person
>> has replied, always by personal email rather than the list.  That is not
>> what keeping an archive of a list is all about.
>
>I agree here.  If you get a private but helpful reply, please forward
>it back to the list so that others can benefit from it.  If you are
>providing a helpful reply, post it to the list so that people can find
>it later.  ;-)
>
>> BTW, where is that list archive?
>
>vger.kernel.org mailing lists are widely distributed
>and there are a number of public archives for them.  One is at
>http://marc.info/?l=linux-bluetooth&w=1

Thanks, I'll dig into that.

>I note that the link on www.bluez.org points to an error message on
> gmane.org.
>
>> >> What I want to  do, and was doing, is to run a system shell on the bt
>> >> device on the other end, and minicom or picocom  to /dev/rfcomm0 as a
>> >> remote terminal on that system.
>
>...but if the system is a Coco3, how is it doing Bluetooth?  I have
>visions of a UART HCI Bluetooth dongle connected to the Coco3 and expected
>to work as a RS-232 port...

Almost exactly.  This bt pack actually uses the rom image from the old rs-232 
pack with one fix, the old 50 baud setting is now a 115,2kb by hooking the 
crystal directly the the sc6551 uart.

>> >When you get it going good, write the Howto. I'd like to read it ;)
>>
>> Chuckle, So would I, like to read it that is! :)
>
>[...]
>
>> I went to google and looked up 'bluetoogh pairing' and got this:
>> http://www.bluetomorrow.com/content/section/180/284/
>> but no real howto.  And I did chase down quite a few other links, mostly
>> for pairing with mobile phones or headsets, nothing on using them as a
>> wireless rs232 circuit.  Which is what I want of course.
>
>Here's a shot at a howto for a serial device.  This is kind of ugly,
>and it occasionally uses brute force rather than the proper Bluetooth-
>or BlueZ-compliant approach; however, I've managed to force quite a
>few devices to work with procedures like this before I knew what I
>was doing.  ;-)
>
>Get the bluez source tarball so you have the 'test' directory.  In that
>directly, you'll find 'simple-agent'.
>
>Make sure the remote device is pairable (can't help you with that--the
>procedure is specific to each remote device, and if the device isn't
>pairable, no amount of trying from the bluez side will work).  Note that
>some devices (especially things like mice and headsets) will allow only
>one connection attempt after they're powered on, and whatever connects to
>them has to pair with them on the first try--so if you mistype the PIN,
>you might have to power the device back off and on again before you retry.

That is why I put this stuff in scripts, no typu's. :)

>Run 'simple-agent hci0 <remote-device-bdaddr>'.  You should be prompted
>for a PIN on both devices.  Use the same one.  ;-)

Same as above I believe:
-------------------------------------------------
./simple-agent hci0 00:0C:84:00:86:F8
ERROR:dbus.proxies:Introspect error on :1.67:/: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents 
this sender from sending this message to this recipient, see message bus 
configuration file (rejected message had interface 
"org.freedesktop.DBus.Introspectable" member "Introspect" error name "(unset)" 
destination ":1.67")
Traceback (most recent call last):
  File "./simple-agent", line 84, in <module>
    path = manager.FindAdapter(sys.argv[1])
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in 
__call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in 
__call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 630, in 
call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A 
security policy in place prevents this sender from sending this message to 
this recipient, see message bus configuration file (rejected message had 
interface "org.bluez.Manager" member "FindAdapter" error name "(unset)" 
destination ":1.67")
-----------------------------------------
>Run 'sdptool browse <remote-device-bdaddr>' (this will probably get me
>flamed by others on this list ;).  This might give you a list of services
>exported by the device.  It might not, in which case you probably want
>to use the org.bluez.Device.DiscoverServices DBus API call, which will
>give you a blob of XML you can decode with your handy-dandy copy of the
>Bluetooth assigned numbers.  If sdptool works, you should get a list of
>serial profile descriptions like this one:
>
>	Service Name: Dialup Networking
>	Service RecHandle: 0x10000
>	Service Class ID List:
>	  "Dialup Networking" (0x1103)
>	  "Generic Networking" (0x1201)
>	Protocol Descriptor List:
>	  "L2CAP" (0x0100)
>	  "RFCOMM" (0x0003)
>	    Channel: 1
>	Profile Descriptor List:
>	  "Dialup Networking" (0x1103)
>	    Version: 0x0100

Yup, I had such a list being returned, yesterday morning...

>The interesting parts are "Service Name" and "Channel".  There may be
>multiple records, each with its own channel.
>
>Run 'rfcomm bind /dev/rfcomm0 <remote-device-bdaddr> N' where N is the
>channel number.  If you don't have success with 'sdptool browse,' you can
>simply try channel numbers from 1 up to 15 or so.

Hummm, redid the 'release' & then 'bind' using your syntax, no error.  But:
[root@coyote test]# sdptool browse
Inquiring ... (10+ second delay, then returned this)
Browsing 00:0C:84:00:86:F8 ...
[root@coyote test]#

And I checked on the coco, it is still spitting out the string "CoCo3 at 
coyote.den" 3 or 4x a second.  IF its transmitting.  Yup, the screen is 
merrilly scrolling away yet.

>Use a terminal program to see what you've connected to on rfcomm0.
>Repeat with different channel numbers until you find what you're
>looking for.

See results above, essentially zip.  Been using channel 1 all along.  Darnit.

Poking around in /etc/dbus-1, I see there is a system.d subdir with a 
bluetooth.conf in it.  It references back to system.conf, but all that may as 
well be APL/swahili to me.

As always, I'm grateful for any help.

Thank you Zygo Blaxell.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The person you rejected yesterday could make you happy, if you say yes.

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

On Tue, Apr 07, 2009 at 12:08:48AM -0400, Gene Heskett wrote:
> On Monday 06 April 2009, Zygo Blaxell wrote:
> >Do you seriously have a Coco3 wired up to Bluetooth?  How?  Presumably not
> >with a native stack...some kind of dongle?
> >
> Roger Taylor is selling a remake of the old Deluxe RS-232 pack, with an a7 
> eb101 module taking the place of the db25 connector.  $65.  Uses the same old 
> rs-232 drivers.  He is one of the movers & shakers of the coco list on 
> maltedmedia.com.

After reading http://www.a7eng.com/downloads/a7-ds-eb101.pdf it looks
like the device has an automatic discovery mode which is activated by
pressing a switch for more than 5 but less than 10 seconds.  It seems
to assume it's talking to another device which has a serial port profile
service enabled...maybe it only works with other eb101's.

It also has a command mode (http://www.a7eng.com/downloads/a7-qs-serial.pdf)
which lets you read things like the device settings and information about
remote devices from the module's point of view.  Especially interesting
ones (page 9) are:

	get connectable  (should be on)
	get trustedlist  (should include your paired bluez device)


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Gene Heskett]

On Tuesday 07 April 2009, Zygo Blaxell wrote:
>On Tue, Apr 07, 2009 at 12:08:48AM -0400, Gene Heskett wrote:
>> On Monday 06 April 2009, Zygo Blaxell wrote:
>> >Do you seriously have a Coco3 wired up to Bluetooth?  How?  Presumably
>> > not with a native stack...some kind of dongle?
>>
>> Roger Taylor is selling a remake of the old Deluxe RS-232 pack, with an a7
>> eb101 module taking the place of the db25 connector.  $65.  Uses the same
>> old rs-232 drivers.  He is one of the movers & shakers of the coco list on
>> maltedmedia.com.
>
>After reading http://www.a7eng.com/downloads/a7-ds-eb101.pdf it looks
>like the device has an automatic discovery mode which is activated by
>pressing a switch for more than 5 but less than 10 seconds.  It seems
>to assume it's talking to another device which has a serial port profile
>service enabled...maybe it only works with other eb101's.
>
>It also has a command mode (http://www.a7eng.com/downloads/a7-qs-serial.pdf)
>which lets you read things like the device settings and information about
>remote devices from the module's point of view.  Especially interesting
>ones (page 9) are:
>
>	get connectable  (should be on)
>	get trustedlist  (should include your paired bluez device)

I fired up a terminal proggy on that device, but none of the answers I got 
were english, like its not running at 9600 baud on the serial interface.  I 
get answers, but they are something like |C> where I recall seeing an <ACK> or 
<NAK> out of it before.

I took some time and replaced the power connector coming out of the coco which 
was getting flaky after 15 years, and now I have much cleaner video.  It had 
one of those 4 pin automotive connectors where the male & female are swapped 
so that when mated, its polarized.  But I think they make those things with 
some sort of a pressure connection that goes away in 15 years just laying 
there.  So since I'm not getting english answers I think I'll toss that 
problem back at Roger & see what he says. 

I suppose I could diddle the baud rate of the terminal proggy too, maybe it 
didn't default to 9600 when I do a power up with the reset button held down, 
which is supposed to reset it to factory defaults.

Yeah, next test, brb.

I went thru the baud rate settings, testing each increment until I got back 
around to 9600, at which point the eb101 started giving me english answers.  
The answers all looked sensible, including an 'lst visible' which returned the 
address on these dinky dongles as 11:11:11:11:11:11, so I tried to do a
 'con 11:11:11:11:11:11 spp'
which was immediately ACK'd, but 5 seconds later returns an error 14, which is 
sort of a blanket error code for almost anything, like miss-matched pins, 
whatever.  l2ping did work before, but now is:
[root@coyote test]#  l2ping -i /dev/rfcomm0 00:0c:84:00:86:F8
Ping: 00:0c:84:00:86:F8 from 11:11:11:11:11:11 (data size 44) ...
4 bytes from 00:0c:84:00:86:F8 id 0 time 11.81ms
4 bytes from 00:0c:84:00:86:F8 id 1 time 7.87ms
4 bytes from 00:0c:84:00:86:F8 id 2 time 29.88ms
4 bytes from 00:0c:84:00:86:F8 id 3 time 26.88ms
4 bytes from 00:0c:84:00:86:F8 id 4 time 26.87ms
4 bytes from 00:0c:84:00:86:F8 id 5 time 25.86ms
4 bytes from 00:0c:84:00:86:F8 id 6 time 7.86ms
^C7 sent, 7 received, 0% loss

Progress?  DamnifIknow & its the witching hour so I'm gonna go checkout some 
zz's.  I'm also doing 'lights out manufacturing' except what I'm doing is 
sharpening a carbide tipped saw blade, using my milling machine which is run 
by emc, to position a dremel with a diamond wheel in it to very precisely 
grind about .005" off the face of each carbide chip, probably about .0002" per 
pass as I'm using a very gentle touch.  It will turn the blade 20 times, touch 
each tooth in turn for about 10 seconds per tooth, 40 teeth.  That operation 
will be done about dawn, and it can run itself till I wake up again. :)

Thanks a bunch.  I appreciate it, a lot.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Not all who own a harp are harpers.
		-- Marcus Terentius Varro

Re: The link I had working quit. Help

[Gene Heskett]

On Monday 06 April 2009, Zygo Blaxell wrote:
>On Mon, Apr 06, 2009 at 02:57:02PM -0400, Gene Heskett wrote:
>> The device on the other end is sending a continuous string of
>> Coco3 at coyote.den
>> at about 3x/second


>> BTW, where is that list archive?
>
>vger.kernel.org mailing lists are widely distributed
>and there are a number of public archives for them.  One is at
>http://marc.info/?l=linux-bluetooth&w=1
>
>From a search on pairing I found:
[root@coyote test]# hcidump -X -V
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff

But that is all it printed in about 2 minutes.

Then:
[root@coyote test]# ./test-discovery
[ 00:0C:84:00:86:F8 ]
    Name = eb101
    LegacyPairing = 1
    Alias = eb101
    Address = 00:0C:84:00:86:F8
    RSSI = 0
    Class = 0x001f00
[root@coyote test]#

But nothing seems to enable the pairing, and everytime I do that that far in 
the 'bluetooth-wizard' and it sees the eb101, it tells me to enter an 
apparently randomly derived 4 digit pin number, but the wizard gives me no 
place to enter it. Nor is there a 'proceed' button, and in 5 seconds or so it 
clears that screen and reports pairing failed.

>> >When you get it going good, write the Howto. I'd like to read it ;)
>>
>> Chuckle, So would I, like to read it that is! :)
>
>[...]
>
>> I went to google and looked up 'bluetoogh pairing' and got this:
>> http://www.bluetomorrow.com/content/section/180/284/
>> but no real howto.  And I did chase down quite a few other links, mostly
>> for pairing with mobile phones or headsets, nothing on using them as a
>> wireless rs232 circuit.  Which is what I want of course.
>
>Here's a shot at a howto for a serial device.  This is kind of ugly,
>and it occasionally uses brute force rather than the proper Bluetooth-
>or BlueZ-compliant approach; however, I've managed to force quite a
>few devices to work with procedures like this before I knew what I
>was doing.  ;-)
>
>Get the bluez source tarball so you have the 'test' directory.  In that
>directly, you'll find 'simple-agent'.
>
>Make sure the remote device is pairable (can't help you with that--the
>procedure is specific to each remote device, and if the device isn't
>pairable, no amount of trying from the bluez side will work).  Note that
>some devices (especially things like mice and headsets) will allow only
>one connection attempt after they're powered on, and whatever connects to
>them has to pair with them on the first try--so if you mistype the PIN,
>you might have to power the device back off and on again before you retry.
>
>Run 'simple-agent hci0 <remote-device-bdaddr>'.  You should be prompted
>for a PIN on both devices.  Use the same one.  ;-)

I am not, this after modifying /etc/dbus-1/systemd/bluetooth.conf to allow all 
bt stuffs.

Aha!  A chance comment I read someplace paid off!  I knew the PIN code for 
that device was 0000 after a factory reset, which had been done several times.  
The comment was that if a pairing failed, they had to be powered off before it 
could be tried again, so I went to the other end and did a powerdown reset, 
than came backup up to here and swapped one for the other of the 2 devices I 
had here, which have identical bdaddr's.

Then I ran
[root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8
RequestPinCode (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8)
Enter PIN Code: 0000
Release
New device (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8)

Ok, tapped the hdwe reset on the coco3 and let it reboot which restarts the 
shell I killed that should be available for minicom to talk to..  

Operative word is 'should':
[root@coyote test]# minicom
minicom: cannot open /dev/rfcomm0: No such file or directory
[root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8
Creating device failed: org.bluez.Error.AlreadyExists: Bonding already exists

[root@coyote test]# rfcomm release all
[root@coyote test]# rfcomm bind 0 00:0c:84:00:86:F8
[root@coyote test]# minicom
minicom: cannot open /dev/rfcomm0: No such file or directory

I think I'm battling with a bad error message that isn't telling me what I 
think it is.

[root@coyote test]# rfcomm connect 0 00:0c:84:00:86:F8 1
Can't connect RFCOMM socket: Host is down

[root@coyote test]# sdptool browse 00:0c:84:00:86:F8
Failed to connect to SDP server on 00:0C:84:00:86:F8: Host is down

So what is the real problem here other than I'm a clueless newbie?

>Run 'rfcomm bind /dev/rfcomm0 <remote-device-bdaddr> N' where N is the
>channel number.  If you don't have success with 'sdptool browse,' you can
>simply try channel numbers from 1 up to 15 or so.
Did that:
[root@coyote test]# rfcomm release all
[root@coyote test]# rfcomm bind /dev/rfcomm0 00:0C:84:00:86:F8 1

>Use a terminal program to see what you've connected to on rfcomm0.
>Repeat with different channel numbers until you find what you're
>looking for.

Terminal programs such as minicom cannot connect to /dev/rfcomm0, claiming it 
does not exist.
root@coyote test]# ls -l /dev/rfcomm*
crw------- 1 root root 216, 0 2009-04-07 13:08 /dev/rfcomm0
[root@coyote test]# minicom
minicom: cannot open /dev/rfcomm0: No such file or directory

Next?

KDE is doing funkity things so I'm going to restart x.  Maybe that will do 
something.



Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The world is coming to an end ... SAVE YOUR BUFFERS!!!

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 6181 bytes --]

On Tue, Apr 07, 2009 at 02:54:54PM -0400, Gene Heskett wrote:
> But nothing seems to enable the pairing, and everytime I do that that far in 
> the 'bluetooth-wizard' and it sees the eb101, it tells me to enter an 
> apparently randomly derived 4 digit pin number, but the wizard gives me no 
> place to enter it. Nor is there a 'proceed' button, and in 5 seconds or so it 
> clears that screen and reports pairing failed.

bluez-gnome (where your bluetooth-wizard comes from?) has a really stupid
UI design.  If bluetooth-wizard thinks you *can* enter a PIN into your
device, it will *require* you to enter a random one.  This idea doesn't
work so well on devices that don't have keyboards or that have fixed PINs,
and bluetooth-wizard knows only about broad categories of devices and a
handful of exceptions.  The opposite problem occurs on devices where
bluez-gnome thinks it knows a fixed-PIN device's PIN, but it actually
doesn't.

Also, bluez-gnome's discovery page won't show you discoverable devices that
are already known, so it can't tell you if a known device is in range.
'hcitool scan' will tell you about all devices in range, but it causes some
problems for bluetoothd if both are running at the same time.

If you can, use simple-agent instead of bluetooth-wizard.

> Aha!  A chance comment I read someplace paid off!  I knew the PIN code for 
> that device was 0000 after a factory reset, which had been done several times.  
> The comment was that if a pairing failed, they had to be powered off before it 
> could be tried again, so I went to the other end and did a powerdown reset, 
> than came backup up to here and swapped one for the other of the 2 devices I 
> had here, which have identical bdaddr's.

How do you have two devices with identical bdaddr's?  Doesn't that wreak
all sorts of havoc for a piconet?  I would expect it to make all the link
key management stop working, since link keys are randomly generated on
each device, but stored in a database keyed by bdaddr.  Also, the piconet
master clock for radio frequency hopping is keyed off the master's bdaddr,
and has to be unique for each piconet.

> Then I ran
> [root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8
> RequestPinCode (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8)
> Enter PIN Code: 0000
> Release
> New device (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8)
> 
> Ok, tapped the hdwe reset on the coco3 and let it reboot which restarts the 
> shell I killed that should be available for minicom to talk to..  

So at this point you should have a link key established between your
Bluetooth devices.  You have successfully completed pairing, and
if the remote device has non-volatile storage, it will stay paired.
Normal remote devices do have non-volatile storage for link keys,
but I'm not sure your devices are normal.

> Operative word is 'should':
> [root@coyote test]# minicom
> minicom: cannot open /dev/rfcomm0: No such file or directory
> [root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8
> Creating device failed: org.bluez.Error.AlreadyExists: Bonding already exists

Yep, still paired...at least on the BlueZ side.

> [root@coyote test]# rfcomm release all
> [root@coyote test]# rfcomm bind 0 00:0c:84:00:86:F8

I think this creates a device file named "0".  Try "/dev/rfcomm0" instead.

Also make sure that /dev/rfcomm0 exists after you've finished rfcomm bind.
If you're using udev (which all modern distros should be), this should
happen automatically after binding.  If it doesn't, you can try "MAKEDEV
rfcomm0" or "mknod /dev/rfcomm0 c 216 0".

> [root@coyote test]# minicom
> minicom: cannot open /dev/rfcomm0: No such file or directory
> 
> I think I'm battling with a bad error message that isn't telling me what I 
> think it is.

No, in this case it's probably telling you that /dev/rfcomm0 really
doesn't exist.  *Why* it doesn't exist is a separate question.  ;)

> [root@coyote test]# rfcomm connect 0 00:0c:84:00:86:F8 1
> Can't connect RFCOMM socket: Host is down

This usually means your remote device isn't connectable, or out of
range, or has turned itself off, or has crashed, or maybe some other
device has connected to the device you're trying to connect to.

Apparently it can also mean the device isn't paired...or at least I get
the same error when trying to bind rfcomm sockets to unpaired devices.
So maybe you're not so paired after all.

It should be /dev/rfcomm0, not just 0, I think.

> [root@coyote test]# sdptool browse 00:0c:84:00:86:F8
> Failed to connect to SDP server on 00:0C:84:00:86:F8: Host is down
> 
> So what is the real problem here other than I'm a clueless newbie?

It looks like your remote device is pairable, but maybe requires some kind
of magic button sequence to make it connectable.  That would be odd, but
within the realm of possibility.

Or, your Bluetooth adapter hangs right after pairing.  That would also
be odd, but possible.  There would probably be kernel log messages in
that case at around the time it fails.  Also, 'hciconfig hci0 reset'
might help if this is the case.

Another thing to watch out for is that a few devices like to power
themselves off if nothing is connected to them for some time.  I have a
headset that does this, which pretty much guarantees I'll never receive
a phone call with it.

Or possibly you have two devices with identical bdaddr, and they're both
turned on at the same time, or you've paired with one and are now trying
to connect to the other.

> Did that:
> [root@coyote test]# rfcomm release all
> [root@coyote test]# rfcomm bind /dev/rfcomm0 00:0C:84:00:86:F8 1
[...] 
> Terminal programs such as minicom cannot connect to /dev/rfcomm0, claiming it 
> does not exist.
> root@coyote test]# ls -l /dev/rfcomm*
> crw------- 1 root root 216, 0 2009-04-07 13:08 /dev/rfcomm0
> [root@coyote test]# minicom
> minicom: cannot open /dev/rfcomm0: No such file or directory
> 
> Next?

You seem to have paired successfully, but can't get any connections to
work afterwards.

Maybe try 'l2ping' to verify the remote device is still on?


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Gene Heskett]

On Tuesday 07 April 2009, Zygo Blaxell wrote:
>On Tue, Apr 07, 2009 at 02:54:54PM -0400, Gene Heskett wrote:
>> But nothing seems to enable the pairing, and everytime I do that that far
>> in the 'bluetooth-wizard' and it sees the eb101, it tells me to enter an
>> apparently randomly derived 4 digit pin number, but the wizard gives me no
>> place to enter it. Nor is there a 'proceed' button, and in 5 seconds or so
>> it clears that screen and reports pairing failed.
>
>bluez-gnome (where your bluetooth-wizard comes from?) has a really stupid
>UI design.  If bluetooth-wizard thinks you *can* enter a PIN into your
>device, it will *require* you to enter a random one.  This idea doesn't
>work so well on devices that don't have keyboards or that have fixed PINs,
>and bluetooth-wizard knows only about broad categories of devices and a
>handful of exceptions.  The opposite problem occurs on devices where
>bluez-gnome thinks it knows a fixed-PIN device's PIN, but it actually
>doesn't.
>
>Also, bluez-gnome's discovery page won't show you discoverable devices that
>are already known, so it can't tell you if a known device is in range.
>'hcitool scan' will tell you about all devices in range, but it causes some
>problems for bluetoothd if both are running at the same time.
>
>If you can, use simple-agent instead of bluetooth-wizard.
>
>> Aha!  A chance comment I read someplace paid off!  I knew the PIN code for
>> that device was 0000 after a factory reset, which had been done several
>> times. The comment was that if a pairing failed, they had to be powered
>> off before it could be tried again, so I went to the other end and did a
>> powerdown reset, than came backup up to here and swapped one for the other
>> of the 2 devices I had here, which have identical bdaddr's.
>
>How do you have two devices with identical bdaddr's?  Doesn't that wreak
>all sorts of havoc for a piconet?  I would expect it to make all the link
>key management stop working, since link keys are randomly generated on
>each device, but stored in a database keyed by bdaddr.  Also, the piconet
>master clock for radio frequency hopping is keyed off the master's bdaddr,
>and has to be unique for each piconet.
>
>> Then I ran
>> [root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8
>> RequestPinCode (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8)
>> Enter PIN Code: 0000
>> Release
>> New device (/org/bluez/2008/hci0/dev_00_0C_84_00_86_F8)
>>
>> Ok, tapped the hdwe reset on the coco3 and let it reboot which restarts
>> the shell I killed that should be available for minicom to talk to..
>
>So at this point you should have a link key established between your
>Bluetooth devices.  You have successfully completed pairing, and
>if the remote device has non-volatile storage, it will stay paired.
>Normal remote devices do have non-volatile storage for link keys,
>but I'm not sure your devices are normal.
>
>> Operative word is 'should':
>> [root@coyote test]# minicom
>> minicom: cannot open /dev/rfcomm0: No such file or directory
>> [root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8
>> Creating device failed: org.bluez.Error.AlreadyExists: Bonding already
>> exists
>
>Yep, still paired...at least on the BlueZ side.
>
>> [root@coyote test]# rfcomm release all
>> [root@coyote test]# rfcomm bind 0 00:0c:84:00:86:F8
>
>I think this creates a device file named "0".  Try "/dev/rfcomm0" instead.

[root@coyote test]# rfcomm release all

[root@coyote test]# ls -l /dev/rfcomm*
ls: cannot access /dev/rfcomm*: No such file or directory

[root@coyote test]#  rfcomm bind /dev/rfcomm0 00:0c:84:00:86:F8

[root@coyote test]# ls -l /dev/rfcomm*
crw------- 1 root root 216, 0 2009-04-07 17:25 /dev/rfcomm0

[root@coyote test]# minicom
minicom: cannot open /dev/rfcomm0: No such file or directory

[root@coyote test]# ls -l /dev/rfcomm*
crw------- 1 root root 216, 0 2009-04-07 17:25 /dev/rfcomm0

and still dead.

>
>Also make sure that /dev/rfcomm0 exists after you've finished rfcomm bind.
>If you're using udev (which all modern distros should be), this should
>happen automatically after binding.  If it doesn't, you can try "MAKEDEV
>rfcomm0" or "mknod /dev/rfcomm0 c 216 0".
>
>> [root@coyote test]# minicom
>> minicom: cannot open /dev/rfcomm0: No such file or directory
>>
>> I think I'm battling with a bad error message that isn't telling me what I
>> think it is.
>
>No, in this case it's probably telling you that /dev/rfcomm0 really
>doesn't exist.  *Why* it doesn't exist is a separate question.  ;)

If it doesn't exist, why can I see it in the /dev directory?

>> [root@coyote test]# rfcomm connect 0 00:0c:84:00:86:F8 1
>> Can't connect RFCOMM socket: Host is down
>
>This usually means your remote device isn't connectable, or out of
>range, or has turned itself off, or has crashed, or maybe some other
>device has connected to the device you're trying to connect to.

>Apparently it can also mean the device isn't paired...or at least I get
>the same error when trying to bind rfcomm sockets to unpaired devices.
>So maybe you're not so paired after all.
>
>It should be /dev/rfcomm0, not just 0, I think.
>
>> [root@coyote test]# sdptool browse 00:0c:84:00:86:F8
>> Failed to connect to SDP server on 00:0C:84:00:86:F8: Host is down
>>
>> So what is the real problem here other than I'm a clueless newbie?
>
>It looks like your remote device is pairable, but maybe requires some kind
>of magic button sequence to make it connectable.  That would be odd, but
>within the realm of possibility.
>
>Or, your Bluetooth adapter hangs right after pairing.  That would also
>be odd, but possible.  There would probably be kernel log messages in
>that case at around the time it fails.  Also, 'hciconfig hci0 reset'
>might help if this is the case.

I didn't even have to pair it to make it work late friday evening, and for 
several hours last saturday.  But I thought I'd change the default PIN and it 
hasn't worked since.

>Another thing to watch out for is that a few devices like to power
>themselves off if nothing is connected to them for some time.  I have a
>headset that does this, which pretty much guarantees I'll never receive
>a phone call with it.

I'd have to call that cute, and it hasn't anything to do with being bow 
legged.

>Or possibly you have two devices with identical bdaddr, and they're both
>turned on at the same time, or you've paired with one and are now trying
>to connect to the other.

Only one of those is plugged in at once.  I got them from USBGear, and both 
show the same bdaddr when queried by hciconfig -a.

>> Did that:
>> [root@coyote test]# rfcomm release all
>> [root@coyote test]# rfcomm bind /dev/rfcomm0 00:0C:84:00:86:F8 1
>
>[...]
>
>> Terminal programs such as minicom cannot connect to /dev/rfcomm0, claiming
>> it does not exist.
>> root@coyote test]# ls -l /dev/rfcomm*
>> crw------- 1 root root 216, 0 2009-04-07 13:08 /dev/rfcomm0
>> [root@coyote test]# minicom
>> minicom: cannot open /dev/rfcomm0: No such file or directory
>>
>> Next?
>
>You seem to have paired successfully, but can't get any connections to
>work afterwards.

Correct.
>
>Maybe try 'l2ping' to verify the remote device is still on?
Variations on the theme:
[root@coyote test]# l2ping 00:0c:84:00:86:F8
Can't connect: Host is down
[root@coyote test]# l2ping -i hci0 00:0c:84:00:86:F8
Can't connect: Host is down
[root@coyote test]# l2ping -i /dev/rfcomm0 00:0c:84:00:86:F8
Can't connect: Host is down

So maybe there is a clue here?

Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Linux, because we don't need no steenkin' Blue Screen of Death!

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

On Tue, Apr 07, 2009 at 05:35:28PM -0400, Gene Heskett wrote:
> [root@coyote test]# ls -l /dev/rfcomm*
> crw------- 1 root root 216, 0 2009-04-07 17:25 /dev/rfcomm0
> 
> [root@coyote test]# minicom
> minicom: cannot open /dev/rfcomm0: No such file or directory
> 
> [root@coyote test]# ls -l /dev/rfcomm*
> crw------- 1 root root 216, 0 2009-04-07 17:25 /dev/rfcomm0

Hmmm...

Maybe try simply 'cat /dev/rfcomm0'?  Or use 'screen' or 'cu'.

While the 'cat' process is running, you can adjust terminal settings
from another shell using 'stty', e.g. 'stty </dev/rfcomm0 9600 -echo'.

I am guessing when you try 'cat /dev/rfcomm0' it will exit immediately,
either with an EOF (which will print nothing) or an I/O error, or even
with 'Host is down'.

> If it doesn't exist, why can I see it in the /dev directory?

Because minicom is to testing raw serial connections what Roman numerals
are to the square root of Pi.  :-P

> I didn't even have to pair it to make it work late friday evening, and for 
> several hours last saturday.  But I thought I'd change the default PIN and it 
> hasn't worked since.

It's possible to turn off security on the eb101 device (says the manual).
Maybe changing the default PIN turns it on?

> >Maybe try 'l2ping' to verify the remote device is still on?
> Variations on the theme:
> [root@coyote test]# l2ping 00:0c:84:00:86:F8
> Can't connect: Host is down
> [root@coyote test]# l2ping -i hci0 00:0c:84:00:86:F8
> Can't connect: Host is down
> [root@coyote test]# l2ping -i /dev/rfcomm0 00:0c:84:00:86:F8
> Can't connect: Host is down
> 
> So maybe there is a clue here?

Could be that the USB dongle has hung on the Linux side, or the
eb101 device has shut itself down or been shut down by the Coco.
It would really help to have the eb101's status information.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Bastien Nocera]

On Tue, 2009-04-07 at 16:02 -0400, Zygo Blaxell wrote:
> 
> On Tue, Apr 07, 2009 at 02:54:54PM -0400, Gene Heskett wrote:
> > But nothing seems to enable the pairing, and everytime I do that
> that far in 
> > the 'bluetooth-wizard' and it sees the eb101, it tells me to enter
> an 
> > apparently randomly derived 4 digit pin number, but the wizard gives
> me no 
> > place to enter it. Nor is there a 'proceed' button, and in 5 seconds
> or so it 
> > clears that screen and reports pairing failed.
> 
> bluez-gnome (where your bluetooth-wizard comes from?) has a really
> stupid
> UI design.  If bluetooth-wizard thinks you *can* enter a PIN into your
> device, it will *require* you to enter a random one.  This idea
> doesn't
> work so well on devices that don't have keyboards or that have fixed
> PINs,
> and bluetooth-wizard knows only about broad categories of devices and
> a
> handful of exceptions.  The opposite problem occurs on devices where
> bluez-gnome thinks it knows a fixed-PIN device's PIN, but it actually
> doesn't.
> 
> Also, bluez-gnome's discovery page won't show you discoverable devices
> that
> are already known, so it can't tell you if a known device is in range.
> 'hcitool scan' will tell you about all devices in range, but it causes
> some
> problems for bluetoothd if both are running at the same time.
> 
> If you can, use simple-agent instead of bluetooth-wizard.

Or you can use gnome-bluetooth which has those problems fixed.

Re: The link I had working quit. Help

[Gene Heskett]

On Tuesday 07 April 2009, Bastien Nocera wrote:
>On Tue, 2009-04-07 at 16:02 -0400, Zygo Blaxell wrote:
>> On Tue, Apr 07, 2009 at 02:54:54PM -0400, Gene Heskett wrote:
>> > But nothing seems to enable the pairing, and everytime I do that
>>
>> that far in
>>
>> > the 'bluetooth-wizard' and it sees the eb101, it tells me to enter
>>
>> an
>>
>> > apparently randomly derived 4 digit pin number, but the wizard gives
>>
>> me no
>>
>> > place to enter it. Nor is there a 'proceed' button, and in 5 seconds
>>
>> or so it
>>
>> > clears that screen and reports pairing failed.
>>
>> bluez-gnome (where your bluetooth-wizard comes from?) has a really
>> stupid
>> UI design.  If bluetooth-wizard thinks you *can* enter a PIN into your
>> device, it will *require* you to enter a random one.  This idea
>> doesn't
>> work so well on devices that don't have keyboards or that have fixed
>> PINs,
>> and bluetooth-wizard knows only about broad categories of devices and
>> a
>> handful of exceptions.  The opposite problem occurs on devices where
>> bluez-gnome thinks it knows a fixed-PIN device's PIN, but it actually
>> doesn't.
>>
>> Also, bluez-gnome's discovery page won't show you discoverable devices
>> that
>> are already known, so it can't tell you if a known device is in range.
>> 'hcitool scan' will tell you about all devices in range, but it causes
>> some
>> problems for bluetoothd if both are running at the same time.
>>
>> If you can, use simple-agent instead of bluetooth-wizard.
>
>Or you can use gnome-bluetooth which has those problems fixed.

But, the F10 rpm has no executables in it, a long list of .png's and .mo's and 
some docs, but nothing in it goes in /bin, /sbin, /usr/bin or /usr/sbin.  Its 
all eye candy & no cattle.  I have it and its deps installed, so what is the 
cli incantation that is supposed to run it?

Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
It's hard to keep your shirt on when you're getting something off your chest.

Re: The link I had working quit. Help

[Gene Heskett]

On Tuesday 07 April 2009, Bastien Nocera wrote:
>On Tue, 2009-04-07 at 16:02 -0400, Zygo Blaxell wrote:
>> On Tue, Apr 07, 2009 at 02:54:54PM -0400, Gene Heskett wrote:
>> > But nothing seems to enable the pairing, and everytime I do that
>>
>> that far in
>>
>> > the 'bluetooth-wizard' and it sees the eb101, it tells me to enter
>>
>> an
>>
>> > apparently randomly derived 4 digit pin number, but the wizard gives
>>
>> me no
>>
>> > place to enter it. Nor is there a 'proceed' button, and in 5 seconds
>>
>> or so it
>>
>> > clears that screen and reports pairing failed.
>>
>> bluez-gnome (where your bluetooth-wizard comes from?) has a really
>> stupid
>> UI design.  If bluetooth-wizard thinks you *can* enter a PIN into your
>> device, it will *require* you to enter a random one.  This idea
>> doesn't
>> work so well on devices that don't have keyboards or that have fixed
>> PINs,
>> and bluetooth-wizard knows only about broad categories of devices and
>> a
>> handful of exceptions.  The opposite problem occurs on devices where
>> bluez-gnome thinks it knows a fixed-PIN device's PIN, but it actually
>> doesn't.
>>
>> Also, bluez-gnome's discovery page won't show you discoverable devices
>> that
>> are already known, so it can't tell you if a known device is in range.
>> 'hcitool scan' will tell you about all devices in range, but it causes
>> some
>> problems for bluetoothd if both are running at the same time.
>>
>> If you can, use simple-agent instead of bluetooth-wizard.
>
>Or you can use gnome-bluetooth which has those problems fixed.
>
If you are referring to 'bluetooth-wizard', it will not show me a device.  I'm 
told it will not show devices which are already paired.

I get what I assume is the same message from a:

[root@coyote test]#  ./simple-agent hci0 00:0C:84:00:86:F8
Creating device failed: org.bluez.Error.AlreadyExists: Bonding already exists

I just found /var/lib/bluetooth/11:11:11:11:11:11 which has a group of small 
files in it, 2 or 3 being subjected to an updated timestamp (data in these 
files is kept in GMT).

Is this the directory I need to mv someplace in order to rerun the bluetooth-
wizard?  Ok, did that, bluetooth-wizard did show me the device, but then the 
pin screen only showed for an almost subliminal time & then reported that it 
failed.

That generated a new /var/lib/bluetooth tree, so I nuked that, and ran 
"simple-agent hci0 <bdaddr of this dongle>"
That asked me for just one PIN and I gave it the default of 0000.  No errors.
And a new /var/lib/bluetooth tree was created.

An l2ping <bdaddr of remote>
Ping: 00:0C:84:00:86:F8 from 11:11:11:11:11:11 (data size 44) ...
4 bytes from 00:0C:84:00:86:F8 id 0 time 16.93ms
4 bytes from 00:0C:84:00:86:F8 id 1 time 10.86ms
4 bytes from 00:0C:84:00:86:F8 id 2 time 27.87ms
4 bytes from 00:0C:84:00:86:F8 id 3 time 28.87ms
4 bytes from 00:0C:84:00:86:F8 id 4 time 25.93ms
4 bytes from 00:0C:84:00:86:F8 id 5 time 25.89ms

Is this normal?

I just now went down to the coco and started a shell on both /t2 (wired) and 
/t3 (bluetooth)
minicom -s & set the serial port to /dev/ttyS0, exit and I am now a remote 
terminal on that machine.
-----------------------screen snip---------------
Welcome to minicom 2.3

OPTIONS: I18n
Compiled on Aug 29 2008, 07:16:49.
Port /dev/ttyS0

               Press CTRL-A Z for help on special keys


Shell+ v2.2a 09/04/08 11:03:01

{t2|04}/DD:dir

 Directory of .  2009/04/08 11:03
BOOTTRACK       CMDS            DEFS            HDBDOS11.DSK    MAXTOR
MODULES         NEWBOOT         NITROS9         NOS96309        OLDCMDS
OLDDEFS         OLDSYS          PcDos.doc       PcDos.doc1      Pcdos.lzh
SYS             UTILS2          cc3go           UTILS2.tmp      dskini
dummy           gene            startyup        test.p          old-sysgo
utils2.merge-list               print-test.b09  sysgo           sysgo.asm
SRC             discscan4floppy dsave.out       startup         devel
p               ekodrvr

{t2|04}/DD:
------------and its waiting for me to issue new commands--------------
If all this was working, I should get an essentially identical response using 
/dev/rfcomm0, right|wrong?

But a second minicom -s, check to see the serial port is /dev/rfcomm0, which 
does exist, select exit to minicom's main screen and it exits, reporting:
minicom: cannot open /dev/rfcomm0: No route to host

So that is where I am at.  Last Saturday morning it Just Worked(TM) without 
all this hassle.  I would like it to work again.  What is the next 
troubleshooting step here?, I'll go at your pace this time.

To those who suggested I use cu, or screen:  I don't have a cu, and 'screen' 
cannot open any device I've named.  From a lengthy read of the manpage, 
'screen' is a VT100 terminal, but without the ability to work with anything 
but the local system, so I don't see as it could be useful here.

I'll go see if I can find this cu.  Thanks everybody.

>--
>To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If you don't like the way I drive, stay off the sidewalk!

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]

On Wed, Apr 08, 2009 at 11:06:11AM -0400, Gene Heskett wrote:
> >Or you can use gnome-bluetooth which has those problems fixed.
> >
> If you are referring to 'bluetooth-wizard', it will not show me a device.  I'm 
> told it will not show devices which are already paired.

gnome-bluetooth is a fork of bluez-gnome.  You'd probably have to build it out
of svn at svn://svn.gnome.org/svn/gnome-bluetooth unless someone's making
binary packages somewhere.

> I get what I assume is the same message from a:
> 
> [root@coyote test]#  ./simple-agent hci0 00:0C:84:00:86:F8
> Creating device failed: org.bluez.Error.AlreadyExists: Bonding already exists
> 
> I just found /var/lib/bluetooth/11:11:11:11:11:11 which has a group of small 
> files in it, 2 or 3 being subjected to an updated timestamp (data in these 
> files is kept in GMT).
> 
> Is this the directory I need to mv someplace in order to rerun the bluetooth-
> wizard?  Ok, did that, bluetooth-wizard did show me the device, but then the 
> pin screen only showed for an almost subliminal time & then reported that it 
> failed.
> 
> That generated a new /var/lib/bluetooth tree, so I nuked that, and ran 
> "simple-agent hci0 <bdaddr of this dongle>"
> That asked me for just one PIN and I gave it the default of 0000.  No errors.
> And a new /var/lib/bluetooth tree was created.
> 
> An l2ping <bdaddr of remote>
> Ping: 00:0C:84:00:86:F8 from 11:11:11:11:11:11 (data size 44) ...
> 4 bytes from 00:0C:84:00:86:F8 id 0 time 16.93ms
> 4 bytes from 00:0C:84:00:86:F8 id 1 time 10.86ms
> 4 bytes from 00:0C:84:00:86:F8 id 2 time 27.87ms
> 4 bytes from 00:0C:84:00:86:F8 id 3 time 28.87ms
> 4 bytes from 00:0C:84:00:86:F8 id 4 time 25.93ms
> 4 bytes from 00:0C:84:00:86:F8 id 5 time 25.89ms
> 
> Is this normal?

All of that looks good.  Do you have a line in /var/lib/bluetooth/*/linkkeys
that looks like:

00:12:47:00:00:01 547603D831DB77377F203B74921E2F1A 0 4

(with a different bdaddr and key value, of course ;).

Actually it might be a good idea to post /var/lib/bluetooth/*/* here.  It
will contain the information that bluetoothd grabs at pairing time that is
often unavailable from utilities like sdptool later.

> But a second minicom -s, check to see the serial port is /dev/rfcomm0, which 
> does exist, select exit to minicom's main screen and it exits, reporting:
> minicom: cannot open /dev/rfcomm0: No route to host

And that doesn't.

> So that is where I am at.  Last Saturday morning it Just Worked(TM) without 
> all this hassle.  I would like it to work again.  What is the next 
> troubleshooting step here?, I'll go at your pace this time.

Did you manage to get at the configuration variables of the eb101 from the
Coco3 side?  It looks like it's working (you can pair with it and ping it)
but somehow it has been configured to reject serial port connections.

Maybe the Coco3 is asserting a modem control line that makes the eb101 think
it should be offline?

> To those who suggested I use cu, or screen:  I don't have a cu, and 'screen' 
> cannot open any device I've named.  From a lengthy read of the manpage, 
> 'screen' is a VT100 terminal, but without the ability to work with anything 
> but the local system, so I don't see as it could be useful here.

If you run 'screen /dev/rfcomm0' it will open a window on /dev/rfcomm0.
For a real serial port you may need something like 
'screen /dev/ttyS0 9600 cs8 -parenb'.  It's a fairly minimal terminal
program which doesn't mess around trying to send modem AT commands or
assert modem control lines unnecessarily.

> I'll go see if I can find this cu.  Thanks everybody.

'cu' is part of 'uucp'.  On Debian it's packaged separately, on other
systems you'll need the rest of the uucp package as well.  It's a fairly
minimalist terminal program that I used to use for serial consoles
on headless systems and embedded devices, until I discovered that the
functionality was built into screen.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Gene Heskett]

[-- Attachment #1: Type: text/plain, Size: 4553 bytes --]

On Wednesday 08 April 2009, Zygo Blaxell wrote:
>On Wed, Apr 08, 2009 at 11:06:11AM -0400, Gene Heskett wrote:
>> >Or you can use gnome-bluetooth which has those problems fixed.
>>
>> If you are referring to 'bluetooth-wizard', it will not show me a device. 
>> I'm told it will not show devices which are already paired.
>
>gnome-bluetooth is a fork of bluez-gnome.  You'd probably have to build it
> out of svn at svn://svn.gnome.org/svn/gnome-bluetooth unless someone's
> making binary packages somewhere.
>
I see.  Since I've built and installed bluezx-4.34, am I new enough?

>> I get what I assume is the same message from a:
>>
>> [root@coyote test]#  ./simple-agent hci0 00:0C:84:00:86:F8
>> Creating device failed: org.bluez.Error.AlreadyExists: Bonding already
>> exists
>>
>> I just found /var/lib/bluetooth/11:11:11:11:11:11 which has a group of
>> small files in it, 2 or 3 being subjected to an updated timestamp (data in
>> these files is kept in GMT).
>>
>> Is this the directory I need to mv someplace in order to rerun the
>> bluetooth- wizard?  Ok, did that, bluetooth-wizard did show me the device,
>> but then the pin screen only showed for an almost subliminal time & then
>> reported that it failed.
>>
>> That generated a new /var/lib/bluetooth tree, so I nuked that, and ran
>> "simple-agent hci0 <bdaddr of this dongle>"
>> That asked me for just one PIN and I gave it the default of 0000.  No
>> errors. And a new /var/lib/bluetooth tree was created.
>>
>> An l2ping <bdaddr of remote>
>> Ping: 00:0C:84:00:86:F8 from 11:11:11:11:11:11 (data size 44) ...
>> 4 bytes from 00:0C:84:00:86:F8 id 0 time 16.93ms
>> 4 bytes from 00:0C:84:00:86:F8 id 1 time 10.86ms
>> 4 bytes from 00:0C:84:00:86:F8 id 2 time 27.87ms
>> 4 bytes from 00:0C:84:00:86:F8 id 3 time 28.87ms
>> 4 bytes from 00:0C:84:00:86:F8 id 4 time 25.93ms
>> 4 bytes from 00:0C:84:00:86:F8 id 5 time 25.89ms
>>
>> Is this normal?
>
>All of that looks good.  Do you have a line in /var/lib/bluetooth/*/linkkeys
>that looks like:
>
>00:12:47:00:00:01 547603D831DB77377F203B74921E2F1A 0 4

00:0C:84:00:86:F8 8601686DF51140E7989038D3E35430E2 0 4
>
>(with a different bdaddr and key value, of course ;).
>
>Actually it might be a good idea to post /var/lib/bluetooth/*/* here.  It
>will contain the information that bluetoothd grabs at pairing time that is
>often unavailable from utilities like sdptool later.

I'll attach it as a tarball.  Done.
>
>> But a second minicom -s, check to see the serial port is /dev/rfcomm0,
>> which does exist, select exit to minicom's main screen and it exits,
>> reporting: minicom: cannot open /dev/rfcomm0: No route to host
>
>And that doesn't.
>
>> So that is where I am at.  Last Saturday morning it Just Worked(TM)
>> without all this hassle.  I would like it to work again.  What is the next
>> troubleshooting step here?, I'll go at your pace this time.
>
>Did you manage to get at the configuration variables of the eb101 from the
>Coco3 side?  It looks like it's working (you can pair with it and ping it)
>but somehow it has been configured to reject serial port connections.
>
>Maybe the Coco3 is asserting a modem control line that makes the eb101 think
>it should be offline?
>
>> To those who suggested I use cu, or screen:  I don't have a cu, and
>> 'screen' cannot open any device I've named.  From a lengthy read of the
>> manpage, 'screen' is a VT100 terminal, but without the ability to work
>> with anything but the local system, so I don't see as it could be useful
>> here.
>
>If you run 'screen /dev/rfcomm0' it will open a window on /dev/rfcomm0.
>For a real serial port you may need something like
>'screen /dev/ttyS0 9600 cs8 -parenb'.  It's a fairly minimal terminal
>program which doesn't mess around trying to send modem AT commands or
>assert modem control lines unnecessarily.
>
>> I'll go see if I can find this cu.  Thanks everybody.
>
>'cu' is part of 'uucp'.  On Debian it's packaged separately, on other
>systems you'll need the rest of the uucp package as well.  It's a fairly
>minimalist terminal program that I used to use for serial consoles
>on headless systems and embedded devices, until I discovered that the
>functionality was built into screen.

Got it, cu doesn't know the port(s) I named with the -p option.  And the 
manpage doesn't seem to describe that part either. :(


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Love isn't only blind, it's also deaf, dumb, and stupid.


[-- Attachment #2: 11:11:11:11:11:11.tar --]
[-- Type: application/x-tar, Size: 10240 bytes --]

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

On Wed, Apr 08, 2009 at 02:50:37PM -0400, Gene Heskett wrote:
> >gnome-bluetooth is a fork of bluez-gnome.  You'd probably have to build it
> > out of svn at svn://svn.gnome.org/svn/gnome-bluetooth unless someone's
> > making binary packages somewhere.
> >
> I see.  Since I've built and installed bluezx-4.34, am I new enough?

bluez is the user-space part of the bluetooth stack.  gnome-bluetooth is the UI.

> Got it, cu doesn't know the port(s) I named with the -p option.  And the 
> manpage doesn't seem to describe that part either. :(

	cu -l /dev/ttyS0 -s 9600

or for rfcomm most likely just

	cu -l /dev/rfcomm0

though with a real RS-232 port on the remote device I don't
know if you have to match baud rates or not.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Gene Heskett]

On Wednesday 08 April 2009, Zygo Blaxell wrote:
>On Wed, Apr 08, 2009 at 02:50:37PM -0400, Gene Heskett wrote:
>> >gnome-bluetooth is a fork of bluez-gnome.  You'd probably have to build
>> > it out of svn at svn://svn.gnome.org/svn/gnome-bluetooth unless
>> > someone's making binary packages somewhere.
>>
>> I see.  Since I've built and installed bluezx-4.34, am I new enough?
>
>bluez is the user-space part of the bluetooth stack.  gnome-bluetooth is the
> UI.
>
>> Got it, cu doesn't know the port(s) I named with the -p option.  And the
>> manpage doesn't seem to describe that part either. :(
>
>	cu -l /dev/ttyS0 -s 9600
>
>or for rfcomm most likely just
>
>	cu -l /dev/rfcomm0
>
>though with a real RS-232 port on the remote device I don't
>know if you have to match baud rates or not.

This is slightly different:
[root@coyote test]# cu -l /dev/rfcomm0 -s 9600
cu: open (/dev/rfcomm0): No route to host
cu: /dev/rfcomm0: Line in use

Line in use?

Thanks.


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genius, n.:
	A chemist who discovers a laundry additive that rhymes with "bright."

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Wed, Apr 08, 2009 at 03:35:04PM -0400, Gene Heskett wrote:
> This is slightly different:
> [root@coyote test]# cu -l /dev/rfcomm0 -s 9600
> cu: open (/dev/rfcomm0): No route to host
> cu: /dev/rfcomm0: Line in use
> 
> Line in use?

"Line in use" means that cu couldn't lock the device or open it.
It's not an OS-level error.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Gene Heskett]

On Wednesday 08 April 2009, Zygo Blaxell wrote:
>On Wed, Apr 08, 2009 at 03:35:04PM -0400, Gene Heskett wrote:
>> This is slightly different:
>> [root@coyote test]# cu -l /dev/rfcomm0 -s 9600
>> cu: open (/dev/rfcomm0): No route to host
>> cu: /dev/rfcomm0: Line in use
>>
>> Line in use?
>
>"Line in use" means that cu couldn't lock the device or open it.
>It's not an OS-level error.

I had forgotten to bring the sw printoutof page 9 up so I could enter it here.  
There is no comm proggy I can run on the coco from a shell/terminal, so I 
can't just copy/paste, darnit.

Anyway the a7 eb101 responses are as follows:

get address local returns the correct bdaddr of that device.
get address remote	err 4
get connectable		on
get ecbonding		responder
get ecconnection	auto
get encryption		on
get esschar		+
get flow		hardware  (this changed to none after I did an 'rst factory'
get linktimeout		0
get name local		eb101
get name remote		err 4
get parity		none
get security		off
get sleep		off
get sniff		on
get status		false
get trustedlist		empty return
get txpower		10
get visible		11:11:11:11:11:11

And finally, a 'con 11:11:11:11:11:11' munches along for several seconds 
before returning an 'err 14'

Did anyone take a look at that tarball I sent yet?

Many Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The PILLSBURY DOUGHBOY is CRYING for an END to BURT REYNOLDS movies!!

Re: The link I had working quit. Help

[Zygo Blaxell]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Wed, Apr 08, 2009 at 10:40:11PM -0400, Gene Heskett wrote:
> Anyway the a7 eb101 responses are as follows:
> 
> get address local returns the correct bdaddr of that device.
> get address remote	err 4
> get connectable		on

connectable is good...

> get ecbonding		responder
> get ecconnection	auto
> get encryption		on
> get esschar		+
> get flow		hardware  (this changed to none after I did an 'rst factory'
> get linktimeout		0
> get name local		eb101
> get name remote		err 4
> get parity		none
> get security		off

security off is interesting, given encryption is on...you might want
to try the other three combinations of those flags.

> get sleep		off
> get sniff		on
> get status		false
> get trustedlist		empty return

Now that's a problem.  You should have the address of the USB dongle here
if you've paired with it.  That suggests that pairing maybe isn't working
on the eb101?  Or maybe you have to use 'set trustedlist'?

> get txpower		10
> get visible		11:11:11:11:11:11
> 
> And finally, a 'con 11:11:11:11:11:11' munches along for several seconds 
> before returning an 'err 14'

That makes sense...you haven't set up a serial port service on the Linux
machine for the eb101 to connect to.

> Did anyone take a look at that tarball I sent yet?

Not yet, although from eyeballing quickly it looks like bluetoothd has
done service discovery and picked up service records.  I'll decode it
the next time I have the tarball, the Bluetooth spec, and some time all
together in one place.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: The link I had working quit. Help

[Gene Heskett]

On Thursday 09 April 2009, Zygo Blaxell wrote:
>On Wed, Apr 08, 2009 at 10:40:11PM -0400, Gene Heskett wrote:
>> Anyway the a7 eb101 responses are as follows:
>>
>> get address local returns the correct bdaddr of that device.
>> get address remote	err 4
>> get connectable		on
>
>connectable is good...
>
>> get ecbonding		responder
>> get ecconnection	auto
>> get encryption		on
>> get esschar		+
>> get flow		hardware  (this changed to none after I did an 'rst factory'
>> get linktimeout		0
>> get name local		eb101
>> get name remote		err 4
>> get parity		none
>> get security		off
>
>security off is interesting, given encryption is on...you might want
>to try the other three combinations of those flags.
>
>> get sleep		off
>> get sniff		on
>> get status		false
>> get trustedlist		empty return
>
>Now that's a problem.  You should have the address of the USB dongle here
>if you've paired with it.  That suggests that pairing maybe isn't working
>on the eb101?  Or maybe you have to use 'set trustedlist'?
>
>> get txpower		10
>> get visible		11:11:11:11:11:11
>>
>> And finally, a 'con 11:11:11:11:11:11' munches along for several seconds
>> before returning an 'err 14'
>
>That makes sense...you haven't set up a serial port service on the Linux
>machine for the eb101 to connect to.
>
>> Did anyone take a look at that tarball I sent yet?
>
>Not yet, although from eyeballing quickly it looks like bluetoothd has
>done service discovery and picked up service records.  I'll decode it
>the next time I have the tarball, the Bluetooth spec, and some time all
>together in one place.

Thank you very much Zygo.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The reader this message encounters not failing to understand is cursed.

Re: The link I had working quit. Help

[Gene Heskett]

On Wednesday 08 April 2009, Zygo Blaxell wrote:
>
>If you run 'screen /dev/rfcomm0' it will open a window on /dev/rfcomm0.
>For a real serial port you may need something like
>'screen /dev/ttyS0 9600 cs8 -parenb'.

This works in  place of minicom for the wired port above if I give the screen 
a linefeed it returns the shell string
 "{t2|04}/DD/NITROS9/6309L2/MODULES/SCF:"

And otherwise appears to work except it thinks the mouse is keys on the 
keyboard, rolling the wheel to scroll back up just gets me garbage on the 
shell's command line.

but 'screen /dev/rfcomm0 9600 -parenb' exits in 5 seconds or so.

Thanks all.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Sysadmins busy fighting SPAM.

Re: The link I had working quit. Help

[Gene Heskett]

On Monday 06 April 2009, jayjwa wrote:

Whats with this list server, its broken!  Even if I hit reply all, it goes 
back out as personal unless I manually add the lists address.  Talk about a 
broken server setup...

>On Mon, 6 Apr 2009, Gene Heskett wrote:
>>> Another idea is try to re-pair the devices. Are you running the
>>> passkey-agent and auth-agent?
>>
>> What are those?  I never heard of them before.  I just built and installed
>> bluez-4.34
>
>That changes everything. I thought you had bluez-3.x here.

No, I started with the 4.30 rpms, and installed from the tarball over the top 
of that by --prefix=/usr when I configured it.

>I've never got
>anything working with 4.x, short of a partial headset test. But bluez-4.x
> has something like passkey-agent, the "simple-agent". You'll need to get
> the actual sources because I doubt it's in the RPM package.

That is what I'm trying to use, and dbus looks to be denying it.
----------------------------------------------------------------
[root@coyote test]# ./simple-agent hci0 00:0C:84:00:86:F8
ERROR:dbus.proxies:Introspect error on :1.67:/: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents 
this sender from sending this message to this recipient, see message bus 
configuration file (rejected message had interface 
"org.freedesktop.DBus.Introspectable" member "Introspect" error name "(unset)" 
destination ":1.67")
Traceback (most recent call last):
  File "./simple-agent", line 84, in <module>
    path = manager.FindAdapter(sys.argv[1])
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in 
__call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in 
__call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 630, in 
call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A 
security policy in place prevents this sender from sending this message to 
this recipient, see message bus configuration file (rejected message had 
interface "org.bluez.Manager" member "FindAdapter" error name "(unset)" 
destination ":1.67")
-----------------------------------------------
No matter what I run in this test directory, the returned error msg is exactly 
the same as above.  I've posted to the fedora list to see if anyone there has 
a clue.

> If you have
> something else you're using to do pairing with, and it works, use that.

If I did, I sure would. :)

> Honestly, I don't know what people are supposed to use to pair with in 4.x,
> since most distrobutions come without simple-agent and bluez-gnome has so
> many dependences (GUI).

Its also installed but I'm a kde fan.

>> #!/bin/bash
>> echo attempting to get bt link to the coco3
>> echo "rfcomm release 0"
>> rfcomm release 0
>> sleep 2
>> ls -l /dev/rfcomm*
>> sleep 2
>> rfcomm -i 11:11:11:11:11:11 show hci0
>> sleep 2
>> echo "resetting hci0"
>> hciconfig reset hsi0
>> sleep 2
>> ls -l /dev/rfcomm*
>> sleep 2
>> rfcomm -i 11:11:11:11:11:11 show hci0
>> sleep 2
>> ls -l /dev/rfcomm*
>> sleep 2
>> echo "hciconfig -a"
>> hciconfig -a
>> sleep 2
>> ls -l /dev/rfcomm*
>> sleep 2
>> echo "rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8"
>> rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8
>
>This still shows "hci0" when I think it would be the rfcomm minor number,
>rfcomm bind 0 <bt addr> <channel>
>
>> sleep 2
>> ls -l /dev/rfcomm*
>> sleep 2
>> echo "rfcomm connect 0 00:0c:84:00:86:F8 1"
>> rfcomm connect 0 00:0c:84:00:86:F8 1
>> echo this should show the cocos address
>> rfcomm -i 11:11:11:11:11:11 show 0
>>
>>
>> And the shell output is:
>> [root@coyote bin]# ./connect2coco3
>> attempting to get bt link to the coco3
>> rfcomm release 0
>> ls: cannot access /dev/rfcomm*: No such file or directory
>> Get info failed: No such device
>> resetting hci0
>> hci0:   Type: USB
>>        BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1
>>        UP RUNNING PSCAN ISCAN
>>        RX bytes:15003 acl:10 sco:0 events:440 errors:0<-note RX count,
>> events TX bytes:4548 acl:10 sco:0 commands:403 errors:0<-TX will increase
>
>It would help to see the services running on the coco3:
>
>sdptool browse <coco btaddr>
-------------------------------------------
[root@coyote bin]# sdptool browse 00:0C:84:00:86:F8
Browsing 00:0C:84:00:86:F8 ...
[root@coyote bin]#
-----------------------------------------------
>> ls: cannot access /dev/rfcomm*: No such file or directory
>> rfcomm -i 11:11:11:11:11:11 bind 0 00:0c:84:00:86:F8
>> crw------- 1 root root 216, 0 2009-04-06 14:11 /dev/rfcomm0
>> rfcomm connect 0 00:0c:84:00:86:F8 1
>> Can't connect RFCOMM socket: Host is down
>> this should show the cocos address
>> rfcomm0: 11:11:11:11:11:11 -> 00:0C:84:00:86:F8 channel 1 clean
>
>The file will always be there, only it's not "pointing" to anything if
>everything didn't work out OK.

/dev/rfcomm0 is removed by the release, and created by the bind.

>>> That would refer to the bt device 0000, which isn't even a valid address
>>> format:
>>>
>>> putkey     <bdaddr>     Store link key on the device
>>
>> Ok, understood, but where does it get the link key to 'putkey' then?>
>> The current version of the script doesn't have this command anymore.
>
>>>From pairing, I'm guessing.
>
>>>> echo "rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8"
>>>> rfcomm -i 11:11:11:11:11:11 bind hci0 00:0c:84:00:86:F8
>>>
>>> This worked with no channel named? Then again, I don't know if one is
>>> really needed. Uncharted waters I'm heading into here...
>>
>> Acc. the manpage, channel is optional, uses channel 1 if not given.>
>
>So we hope your service you want to access on the remote end is indeed
> running on channel 1! If not, this won't work.

According to the docs I got from the a7 site, channel 1 is the default.
>
>> I had a 'watch' running, stopped that: then
>> [root@coyote sysconfig]# rfcomm  show rfcomm0
>> rfcomm0: 11:11:11:11:11:11 -> 00:0C:84:00:86:F8 channel 1 closed
>> rfcomm connect 0 00:0c:84:00:86:F8  (a good 10 sec delay here)
>> Can't connect RFCOMM socket: Connection timed out
>
>Let the application make the connection. Just bind the device. That's how
> I've done it always. The application will then open /dev/rfcomm0 and do its
> thing.

except:
[root@coyote bin]# minicom
minicom: cannot open /dev/rfcomm0: No such file or directory

but its there right now.
[root@coyote bin]# ls -l /dev/rfcomm*
crw------- 1 root root 216, 0 2009-04-07 00:33 /dev/rfcomm0

I've downloaded all the bluez-3.30 stuff and if no more answers seem to be 
forthcoming, I may try it sometime tomorrow.

>>> uses headsets under 4.x. From the other questions on the list, no-one
>>> uses anything successfully under 4.x, unless you count /usr/bin/patch.
>>> Really I'm thinking of unsubscribing.
>>
>> It doesn't seem to be all that helpful, you and I believe one other person
>> has replied, always by personal email rather than the list.  That is not
>> what keeping an archive of a list is all about. BTW, where is that list
>> archive?
>
>Well, I replied directly to you because no one else was answering or
> helping. I assumed they either didn't know or care.
>
>> I went to google and looked up 'bluetoogh pairing' and got this:
>> http://www.bluetomorrow.com/content/section/180/284/
>> but no real howto.  And I did chase down quite a few other links, mostly
>> for pairing with mobile phones or headsets, nothing on using them as a
>> wireless rs232 circuit.  Which is what I want of course.
>
>I'm guessing pairing is still needed, but you're really outside my area of
>experience here.
>
>> Thank you jayjwa, and I appreciate very much your use of english as its
>> the only language this old (74) fart knows.
>
>Me too, though I did pick up a very small amount of German when I was there.

There was a time 60 years ago when I could read enough german to fix a 
telefunken radio, but then the japanese moved in with their dialect of 
Engrish, some of which is pretty comical.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
When smashing monuments, save the pedstals -- they always come in handy.
		-- Stanislaw J. Lem, "Unkempt Thoughts"