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:

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

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.

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
>> [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!

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

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