2009-04-06 18:57:02

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:
[[email protected] 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

[[email protected] bin]# cat /dev/rfcomm0 (gets nothing)
^C

[[email protected] 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)

[[email protected] 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)

[[email protected] 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)

[[email protected] 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)

[[email protected] 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

[[email protected] bin]# cat /dev/rfcomm0
cat: /dev/rfcomm0: Host is down
[[email protected] 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
[[email protected] 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:
[[email protected] 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



2009-04-09 18:28:33

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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.


2009-04-09 14:55:06

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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.


Attachments:
(No filename) (1.47 kB)
signature.asc (197.00 B)
Digital signature
Download all attachments

2009-04-09 02:40:11

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:
>> [[email protected] 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!!


2009-04-08 19:36:40

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

On Wed, Apr 08, 2009 at 03:35:04PM -0400, Gene Heskett wrote:
> This is slightly different:
> [[email protected] 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.


Attachments:
(No filename) (329.00 B)
signature.asc (197.00 B)
Digital signature
Download all attachments

2009-04-08 19:35:04

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:
[[email protected] 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."


2009-04-08 19:30:08

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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.


Attachments:
(No filename) (730.00 B)
signature.asc (197.00 B)
Digital signature
Download all attachments

2009-04-08 19:03:20

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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.


2009-04-08 18:50:37

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:
>>
>> [[email protected] 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.


Attachments:
(No filename) (4.45 kB)
11:11:11:11:11:11.tar (10.00 kB)
Download all attachments

2009-04-08 16:17:30

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:
>
> [[email protected] 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.


Attachments:
(No filename) (3.83 kB)
signature.asc (197.00 B)
Digital signature
Download all attachments

2009-04-08 15:06:11

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:

[[email protected] 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 [email protected]
>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!


2009-04-08 04:26:13

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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.


2009-04-08 04:11:10

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:
[[email protected] 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


2009-04-07 23:05:18

by Bastien Nocera

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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.


2009-04-07 21:56:19

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

On Tue, Apr 07, 2009 at 05:35:28PM -0400, Gene Heskett wrote:
> [[email protected] test]# ls -l /dev/rfcomm*
> crw------- 1 root root 216, 0 2009-04-07 17:25 /dev/rfcomm0
>
> [[email protected] test]# minicom
> minicom: cannot open /dev/rfcomm0: No such file or directory
>
> [[email protected] 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:
> [[email protected] test]# l2ping 00:0c:84:00:86:F8
> Can't connect: Host is down
> [[email protected] test]# l2ping -i hci0 00:0c:84:00:86:F8
> Can't connect: Host is down
> [[email protected] 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.


Attachments:
(No filename) (1.75 kB)
signature.asc (197.00 B)
Digital signature
Download all attachments

2009-04-07 21:35:28

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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
>> [[email protected] 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':
>> [[email protected] test]# minicom
>> minicom: cannot open /dev/rfcomm0: No such file or directory
>> [[email protected] 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.
>
>> [[email protected] test]# rfcomm release all
>> [[email protected] test]# rfcomm bind 0 00:0c:84:00:86:F8
>
>I think this creates a device file named "0". Try "/dev/rfcomm0" instead.

[[email protected] test]# rfcomm release all

[[email protected] test]# ls -l /dev/rfcomm*
ls: cannot access /dev/rfcomm*: No such file or directory

[[email protected] test]# rfcomm bind /dev/rfcomm0 00:0c:84:00:86:F8

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

[[email protected] test]# minicom
minicom: cannot open /dev/rfcomm0: No such file or directory

[[email protected] 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".
>
>> [[email protected] 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?

>> [[email protected] 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.
>
>> [[email protected] 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:
>> [[email protected] test]# rfcomm release all
>> [[email protected] 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.
>> [email protected] test]# ls -l /dev/rfcomm*
>> crw------- 1 root root 216, 0 2009-04-07 13:08 /dev/rfcomm0
>> [[email protected] 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:
[[email protected] test]# l2ping 00:0c:84:00:86:F8
Can't connect: Host is down
[[email protected] test]# l2ping -i hci0 00:0c:84:00:86:F8
Can't connect: Host is down
[[email protected] 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!


2009-04-07 20:40:55

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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)


Attachments:
(No filename) (1.14 kB)
signature.asc (197.00 B)
Digital signature
Download all attachments

2009-04-07 20:02:01

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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
> [[email protected] 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':
> [[email protected] test]# minicom
> minicom: cannot open /dev/rfcomm0: No such file or directory
> [[email protected] 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.

> [[email protected] test]# rfcomm release all
> [[email protected] 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".

> [[email protected] 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. ;)

> [[email protected] 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.

> [[email protected] 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:
> [[email protected] test]# rfcomm release all
> [[email protected] 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.
> [email protected] test]# ls -l /dev/rfcomm*
> crw------- 1 root root 216, 0 2009-04-07 13:08 /dev/rfcomm0
> [[email protected] 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?


Attachments:
(No filename) (5.91 kB)
signature.asc (197.00 B)
Digital signature
Download all attachments

2009-04-07 18:54:54

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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:
[[email protected] 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:
[[email protected] 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
[[email protected] 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
[[email protected] 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':
[[email protected] test]# minicom
minicom: cannot open /dev/rfcomm0: No such file or directory
[[email protected] test]# ./simple-agent hci0 00:0C:84:00:86:F8
Creating device failed: org.bluez.Error.AlreadyExists: Bonding already exists

[[email protected] test]# rfcomm release all
[[email protected] test]# rfcomm bind 0 00:0c:84:00:86:F8
[[email protected] 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.

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

[[email protected] 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:
[[email protected] test]# rfcomm release all
[[email protected] 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.
[email protected] test]# ls -l /dev/rfcomm*
crw------- 1 root root 216, 0 2009-04-07 13:08 /dev/rfcomm0
[[email protected] 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!!!


2009-04-07 04:08:48

by Gene Heskett

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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
>>
>> [[email protected] bin]# cat /dev/rfcomm0
>> cat: /dev/rfcomm0: Host is down
>> [[email protected] 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?
-------------------------------------[[email protected] 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 http://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:
[[email protected] test]# sdptool browse
Inquiring ... (10+ second delay, then returned this)
Browsing 00:0C:84:00:86:F8 ...
[[email protected] 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.


2009-04-06 22:14:44

by Zygo Blaxell

[permalink] [raw]
Subject: Re: The link I had working quit. Help

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
>
> [[email protected] bin]# cat /dev/rfcomm0
> cat: /dev/rfcomm0: Host is down
> [[email protected] 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 http://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.


Attachments:
(No filename) (7.53 kB)
signature.asc (197.00 B)
Digital signature
Download all attachments