On Mon, Apr 06, 2009 at 02:57:02PM -0400, Gene Heskett wrote: > The device on the other end is sending a continuous string of > Coco3 at coyote.den > at about 3x/second Do you seriously have a Coco3 wired up to Bluetooth? How? Presumably not with a native stack...some kind of dongle? If you do have a Coco3 with a native Bluetooth stack...I want one. ;) The native Bluetooth stack, that is...I already have a Coco3 or two. > And it has an led that when connected, will blink on and off at 2 second > intervals, but is not. When it worked, it did blick correctly. > > So traffic IS flowing, I just can't get the device to show it to me, or get > picocom or minicom to even find /dev/rfcomm0 > > [root@coyote bin]# cat /dev/rfcomm0 > cat: /dev/rfcomm0: Host is down > [root@coyote bin]# minicom > minicom: cannot open /dev/rfcomm0: Host is down Looks like it's bound to the wrong remote address, or the remote device isn't listening for connections. > Your comment about > >Another idea is try to re-pair the devices. Are you running the > > passkey-agent and auth-agent? > > Is another clue, but neither of those exist on this system. What package are > they part of? There is an agent written in Python named simple-agent in the Bluez sources, under 'test'. It's probably the closest thing to a simple command-line utility. > I do have the bluetooth-wizard, which on its device display screen shows blank > space where the device list should be. Do you have any other Bluetooth devices to test with? It would be one thing if you can't see the specific device you're looking for, but something else entirely if you can't see any devices *at all*. > >> echo "hciconfig -a hci0 putkey 0000" > >> hciconfig -a hci0 putkey 0000 > >> --------which returns: > >> Can't find link key for 0000 on hci0 > >> ^C You probably don't want to be using hciconfig or hcitool. Use the DBus API to talk to bluetoothd instead. On Mon, Apr 06, 2009 at 02:57:02PM -0400, Gene Heskett wrote: > On Monday 06 April 2009, jayjwa wrote: > >On Sun, 5 Apr 2009, Gene Heskett wrote: > >> Where are the bluetooth guru's? Or, where can I find the RFC documents > >> that describe how all this is supposed to work? http://wiki.bluez.org/ has some HOWTOs that are somewhat out of date but still useful as a starting point. Bluez API documents are in the bluez sources under doc/. The Bluetooth specs are under http://www.bluetooth.com/Bluetooth/Technology/Building/Specifications/, but they're probably useless unless you want very high-level architectural information, or you know exactly what technical detail you're looking for. > >If they're on the bt list, then they are silent. They never answer me there; > > I asked about getting bt headsets going under 4.x, and only one person > > remarked he thought he saw kernel messages. I'm assuming then that no-one > > uses headsets under 4.x. From the other questions on the list, no-one uses > > anything successfully under 4.x, unless you count /usr/bin/patch. Really > > I'm thinking of unsubscribing. FWIW, I've gotten several bluetooth headsets to work under 3.36 and most of 4.x for 20 < x < 34, using the A2DP profile and the bluez-alsa plugin and the instructions at http://wiki.bluez.org/wiki/HOWTO/AudioDevices which cover audio devices. "My device doesn't work" questions on the mailing list often come down to two common cases: either a) you will eventually get it to work by following the wiki or reading the mailing list archives, so you don't need an answer from a guru, or b) you won't get it to work because someone (possibly you) has to write a patch, but the gurus are patiently waiting for you to provide enough information to get started on one. You may find it worthwhile to read the mailing list archives to see what people have included in their postings that *do* get answers, and see if you can supply something similar. > It doesn't seem to be all that helpful, you and I believe one other person has > replied, always by personal email rather than the list. That is not what > keeping an archive of a list is all about. I agree here. If you get a private but helpful reply, please forward it back to the list so that others can benefit from it. If you are providing a helpful reply, post it to the list so that people can find it later. ;-) > BTW, where is that list archive? vger.kernel.org mailing lists are widely distributed and there are a number of public archives for them. One is at http://marc.info/?l=linux-bluetooth&w=1 I note that the link on www.bluez.org points to an error message on gmane.org. > >> What I want to do, and was doing, is to run a system shell on the bt > >> device on the other end, and minicom or picocom to /dev/rfcomm0 as a > >> remote terminal on that system. ...but if the system is a Coco3, how is it doing Bluetooth? I have visions of a UART HCI Bluetooth dongle connected to the Coco3 and expected to work as a RS-232 port... > >When you get it going good, write the Howto. I'd like to read it ;) > > Chuckle, So would I, like to read it that is! :) [...] > I went to google and looked up 'bluetoogh pairing' and got this: > http://www.bluetomorrow.com/content/section/180/284/ > but no real howto. And I did chase down quite a few other links, mostly for > pairing with mobile phones or headsets, nothing on using them as a wireless > rs232 circuit. Which is what I want of course. Here's a shot at a howto for a serial device. This is kind of ugly, and it occasionally uses brute force rather than the proper Bluetooth- or BlueZ-compliant approach; however, I've managed to force quite a few devices to work with procedures like this before I knew what I was doing. ;-) Get the bluez source tarball so you have the 'test' directory. In that directly, you'll find 'simple-agent'. Make sure the remote device is pairable (can't help you with that--the procedure is specific to each remote device, and if the device isn't pairable, no amount of trying from the bluez side will work). Note that some devices (especially things like mice and headsets) will allow only one connection attempt after they're powered on, and whatever connects to them has to pair with them on the first try--so if you mistype the PIN, you might have to power the device back off and on again before you retry. Run 'simple-agent hci0 <remote-device-bdaddr>'. You should be prompted for a PIN on both devices. Use the same one. ;-) Run 'sdptool browse <remote-device-bdaddr>' (this will probably get me flamed by others on this list ;). This might give you a list of services exported by the device. It might not, in which case you probably want to use the org.bluez.Device.DiscoverServices DBus API call, which will give you a blob of XML you can decode with your handy-dandy copy of the Bluetooth assigned numbers. If sdptool works, you should get a list of serial profile descriptions like this one: Service Name: Dialup Networking Service RecHandle: 0x10000 Service Class ID List: "Dialup Networking" (0x1103) "Generic Networking" (0x1201) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1 Profile Descriptor List: "Dialup Networking" (0x1103) Version: 0x0100 The interesting parts are "Service Name" and "Channel". There may be multiple records, each with its own channel. Run 'rfcomm bind /dev/rfcomm0 <remote-device-bdaddr> N' where N is the channel number. If you don't have success with 'sdptool browse,' you can simply try channel numbers from 1 up to 15 or so. Use a terminal program to see what you've connected to on rfcomm0. Repeat with different channel numbers until you find what you're looking for.
Attachment:
signature.asc
Description: Digital signature
