* Newbie, can't find device
@ 2009-03-26 0:37 Gene Heskett
2009-03-26 10:59 ` jayjwa
2009-03-26 11:36 ` David Stockwell
0 siblings, 2 replies; 7+ messages in thread
From: Gene Heskett @ 2009-03-26 0:37 UTC (permalink / raw)
To: linux-bluetooth
Greetings;
gnubie to bluetooth that is. I bought some dongles to replace a cable that is
just long enough to present EMP surge problems between this box and a
bluetooth kit installed to replace the connector in an RS-232 pack for a
legacy computer, an old TRS-80 Color Computer 3 that has all the goodies in it
that 20 some years of development can give.
I get this from demsg:
[ 8.884948] Bluetooth: Core ver 2.14
[ 8.885051] Bluetooth: HCI device and connection manager initialized
[ 8.885054] Bluetooth: HCI socket layer initialized
[ 9.112240] Bluetooth: Generic Bluetooth USB driver ver 0.4
[ 21.015636] Bluetooth: L2CAP ver 2.11
[ 21.015639] Bluetooth: L2CAP socket layer initialized
[ 21.165128] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 21.165131] Bluetooth: BNEP filters: protocol multicast
[ 21.245887] Bluetooth: SCO (Voice Link) ver 0.6
[ 21.245890] Bluetooth: SCO socket layer initialized
[ 22.084606] Bluetooth: RFCOMM socket layer initialized
[ 22.084616] Bluetooth: RFCOMM TTY layer initialized
[ 22.084618] Bluetooth: RFCOMM ver 1.10
But no new devices are being created by udev.
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:1104 acl:0 sco:0 events:45 errors:0
TX bytes:445 acl:0 sco:0 commands:45 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: 0x4a2100
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
Manufacturer: CONWISE Technology Corporation Ltd (66)
Where do I go from here. What I need to do is run a session of minicom to it
but minicom cannot find the device 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)
If a group of _\bN persons implements a COBOL compiler, there will be _\bN-1
passes. Someone in the group has to be the manager.
-- T. Cheatham
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Newbie, can't find device
2009-03-26 0:37 Newbie, can't find device Gene Heskett
@ 2009-03-26 10:59 ` jayjwa
[not found] ` <200903261157.28413.gene.heskett@verizon.net>
2009-03-26 11:36 ` David Stockwell
1 sibling, 1 reply; 7+ messages in thread
From: jayjwa @ 2009-03-26 10:59 UTC (permalink / raw)
To: linux-bluetooth
On Wed, 25 Mar 2009, Gene Heskett wrote:
> gnubie to bluetooth that is. I bought some dongles to replace a cable that is
> just long enough to present EMP surge problems between this box and a
> bluetooth kit installed to replace the connector in an RS-232 pack for a
> legacy computer, an old TRS-80 Color Computer 3 that has all the goodies in it
> that 20 some years of development can give.
>
> I get this from demsg:
> [ 8.884948] Bluetooth: Core ver 2.14
> [ 8.885051] Bluetooth: HCI device and connection manager initialized
> [ 8.885054] Bluetooth: HCI socket layer initialized
> [ 9.112240] Bluetooth: Generic Bluetooth USB driver ver 0.4
> [ 21.015636] Bluetooth: L2CAP ver 2.11
> [ 21.015639] Bluetooth: L2CAP socket layer initialized
> [ 21.165128] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [ 21.165131] Bluetooth: BNEP filters: protocol multicast
> [ 21.245887] Bluetooth: SCO (Voice Link) ver 0.6
> [ 21.245890] Bluetooth: SCO socket layer initialized
> [ 22.084606] Bluetooth: RFCOMM socket layer initialized
> [ 22.084616] Bluetooth: RFCOMM TTY layer initialized
> [ 22.084618] Bluetooth: RFCOMM ver 1.10
>
> But no new devices are being created by udev.
>
> 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:1104 acl:0 sco:0 events:45 errors:0
> TX bytes:445 acl:0 sco:0 commands:45 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: 0x4a2100
> Service Classes: Networking, Capturing, Telephony
> Device Class: Computer, Uncategorized
> HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
> Manufacturer: CONWISE Technology Corporation Ltd (66)
>
> Where do I go from here. What I need to do is run a session of minicom to it
> but minicom cannot find the device either.
I don't use udev, but maybe you can adapt this to your setup. I think you need
an rfcomm device. udev may create the devices when they are actually opened.
They list in /proc/devices on my system, major number 216, minors 0 and 1.
crw-rw-rw- 1 root root 216, 0 2009-02-22 23:01 /dev/rfcomm0
crw-rw-rw- 1 root root 216, 1 2007-12-16 07:29 /dev/rfcomm1
Using bluez-3.36 -
Scan for your device -
# hcitool scan
# passkey-agent --default (PIN) (address of your device) &
# auth-agent &
Find the channel the thing you want is on -
# sdptool browse 00:1C:62:19:B1:6A
...
Service Name: Bluetooth Modem
Service RecHandle: 0x10006
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 8
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
Bind the rfcomm device to the btaddress and channel, here an example with a
btmodem at 00:1C:62:19:B1:6A channel 8 -
# rfcomm bind 0 00:1C:62:19:B1:6A 8
Means bind to rfcomm0 the address 00:1C:62:19:B1:6A at ch. 8.
Now give /dev/rfcomm0 to Minicom, etc. I find Kermit (ckermit,
http://www.columbia.edu/kermit/ckermit.html) more usable. When you're done,
unbind it -
# rfcomm release 0
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Newbie, can't find device
2009-03-26 0:37 Newbie, can't find device Gene Heskett
2009-03-26 10:59 ` jayjwa
@ 2009-03-26 11:36 ` David Stockwell
1 sibling, 0 replies; 7+ messages in thread
From: David Stockwell @ 2009-03-26 11:36 UTC (permalink / raw)
To: Gene Heskett, linux-bluetooth
Hello...
----- Original Message -----
From: "Gene Heskett" <gene.heskett@verizon.net>
To: <linux-bluetooth@vger.kernel.org>
Sent: Wednesday, March 25, 2009 7:37 PM
Subject: Newbie, can't find device
> Greetings;
>
Core v2.14? Very, very old. I think we are on version 4.33, which has
been completely re-architected on a DBus foundation. With DBus, the
"devices" are created as object paths that handle defined messages via
DBus.
What sort of box are you running on? Which kernel version? Which
distro? I get a little concerned (and somewhat nostalgic/nauseous) when
I see a "Trash-80" cited (I think you are wanting to use Bluetooth to
talk to it).
Just my two cents and worth about that much.
DS
> I get this from demsg:
> [ 8.884948] Bluetooth: Core ver 2.14
> [ 8.885051] Bluetooth: HCI device and connection manager
> initialized
> [ 8.885054] Bluetooth: HCI socket layer initialized
> [ 9.112240] Bluetooth: Generic Bluetooth USB driver ver 0.4
> [ 21.015636] Bluetooth: L2CAP ver 2.11
> [ 21.015639] Bluetooth: L2CAP socket layer initialized
> [ 21.165128] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [ 21.165131] Bluetooth: BNEP filters: protocol multicast
> [ 21.245887] Bluetooth: SCO (Voice Link) ver 0.6
> [ 21.245890] Bluetooth: SCO socket layer initialized
> [ 22.084606] Bluetooth: RFCOMM socket layer initialized
> [ 22.084616] Bluetooth: RFCOMM TTY layer initialized
> [ 22.084618] Bluetooth: RFCOMM ver 1.10
>
> But no new devices are being created by udev.
>
> 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:1104 acl:0 sco:0 events:45 errors:0
> TX bytes:445 acl:0 sco:0 commands:45 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: 0x4a2100
> Service Classes: Networking, Capturing, Telephony
> Device Class: Computer, Uncategorized
> HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP
> Subver: 0x1f4
> Manufacturer: CONWISE Technology Corporation Ltd (66)
>
> Where do I go from here. What I need to do is run a session of
> minicom to it
> but minicom cannot find the device 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)
> If a group of _\bN persons implements a COBOL compiler, there will be
> _\bN-1
> passes. Someone in the group has to be the manager.
> -- T. Cheatham
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Newbie, can't find device
[not found] ` <200903261157.28413.gene.heskett@verizon.net>
@ 2009-03-27 0:23 ` jayjwa
[not found] ` <200903262205.52669.gene.heskett@verizon.net>
0 siblings, 1 reply; 7+ messages in thread
From: jayjwa @ 2009-03-27 0:23 UTC (permalink / raw)
To: Gene Heskett; +Cc: linux-bluetooth
On Thu, 26 Mar 2009, Gene Heskett wrote:
>> I don't use udev, but maybe you can adapt this to your setup. I think you
>> need an rfcomm device. udev may create the devices when they are actually
>> opened. They list in /proc/devices on my system, major number 216, minors 0
>> and 1.
>>
>> crw-rw-rw- 1 root root 216, 0 2009-02-22 23:01 /dev/rfcomm0
>> crw-rw-rw- 1 root root 216, 1 2007-12-16 07:29 /dev/rfcomm1
>
> /proc/devices is a file, not a dir on this F10 system.
>
> I have only:
> 216 rfcomm
It's supposed to be a file. Can you use mknod to make a rfcomm device? Is that
allowed in udev? I've never worked with it; I find that making the devices by
hand works well for me. If you can, the command would be like:
mknod -m 666 /dev/rfcomm0 c 216 0
mknod -m 666 /dev/rfcomm0 c 216 1
However, if the bluetooth adapter isn't working for some reason, then udev is
right not to make devices for it since to it, it doesn't yet exist.
>> # hcitool scan
>
> 20 secs quiet, empty return. There is a twin to it plugged into a kubuntu box
> about 10 feet away, but its hciconfig says hci0 is down. and
> 'hciconfig hci0 up' returns no such device.
The dongle on the kubuntu box isn't ready/supported/working. You should see it
by scanning, and I've never had to do a manual 'hciconfig hci0 up' at any
time. If it's a USB congle, does it show with 'lsusb'? When you plug it in,
what kernel messages do you get? Are the bluez/dbus/usb systems all complete
on that box?
>> # passkey-agent --default (PIN) (address of your device) &
>> # auth-agent &
>>
>> Find the channel the thing you want is on -
>>
>> # sdptool browse 00:1C:62:19:B1:6A
>
> Is a repeat of the null return above.
>
> From a terminal screen:
> [root@coyote src]# hcitool scan
> Scanning ...
> [root@coyote src]# hciconfig -a 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:1390 acl:0 sco:0 events:50 errors:0
> TX bytes:462 acl:0 sco:0 commands:49 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: 0x4a2100
> Service Classes: Networking, Capturing, Telephony
> Device Class: Computer, Uncategorized
> HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4
> Manufacturer: CONWISE Technology Corporation Ltd (66)
>
> [root@coyote src]# sdptool browse 11:11:11:11:11:11
> Failed to connect to SDP server on 11:11:11:11:11:11: No route to host
> [root@coyote src]#
That's expected. This will always fail until the kubuntu dongle is working.
> [root@coyote src]# rfcomm bind 0 11:11:11:11:11:11 8
> [root@coyote src]# hcitool dev
> Devices:
> hci0 11:11:11:11:11:11
> [root@coyote src]# rfcomm bind 0 11:11:11:11:11:11 8
> Can't create device: Address already in use
> [root@coyote src]# rfcomm release 0 11:11:11:11:11:11
> [root@coyote src]# rfcomm bind 0 11:11:11:11:11:11 8
> [root@coyote src]#
>
> So that appears to work since I can't do it a 2nd time w/o a release in
> between. But there is still no device being created.
This one is the same as above, it won't work until the partner dongle is
working correctly. It must be contactable and in working order before you can
make an rfcomm connection to it and transfer data.
Try taking your working adapter and putting it into the kubuntu box. If it
works, it was the other dongle, if it doesn't, it's the other system itself at
fault.
> I followed the thread just in front of this message and made my
> /etc/dbus-1/system.d/bluetooth.conf match the final version there, but I don't
> believe it made any diff> At what point in the down/up sequence (which gives
> a null return, even for repeats BTW, and hciconfig continues to say its up
> even if I have sent several downs. And on the kubuntu box, it says its always
> down)
The previous post I made about dbus was to fix permission problems when bluez
interacts with dbus after dbus is updated to the currect release, which is
much more strick with permissions. I don't think that is causing the issue
here. From here, I'd focus on getting 'hciconfig -a' to return the correct
information on the kubuntu box. Once that works, all the other errors should
clear up.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Newbie, can't find device
[not found] ` <200903262205.52669.gene.heskett@verizon.net>
@ 2009-03-30 5:03 ` jayjwa
[not found] ` <200903300928.02545.gene.heskett@verizon.net>
0 siblings, 1 reply; 7+ messages in thread
From: jayjwa @ 2009-03-30 5:03 UTC (permalink / raw)
To: linux-bluetooth
On Thu, 26 Mar 2009, Gene Heskett wrote:
>> The dongle on the kubuntu box isn't ready/supported/working. You should see
>> it by scanning, and I've never had to do a manual 'hciconfig hci0 up' at
>> any time. If it's a USB congle, does it show with 'lsusb'? When you plug it
>> in, what kernel messages do you get? Are the bluez/dbus/usb systems all
>> complete on that box?
>>
> UNK at this point. I'll ssh into it and find out:
> gene@goat:~$ lsusb
> Bus 002 Device 004: ID 0e5e:6622 That is the devices make:prod ID
>
> gene@goat:~$ sudo lsusb -v| grep -A75 'Bus 002 Device 004:'
> Bus 002 Device 004: ID 0e5e:6622
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 16
> idVendor 0x0e5e
> idProduct 0x6622
> bcdDevice 1.34
> iManufacturer 0
> iProduct 0
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 108
> bNumInterfaces 2
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0010 1x 16 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> cannot read device status, Connection timed out (110)
> can't get device qualifier: Connection timed out
> can't get debug descriptor: Connection timed out
> cannot read device status, Connection timed out (110)
That's not good. The command should complete normally. You seem to be missing
about half the data mine displays for this type of device. I'm no USB device
expert, but I'd guess the root of the problem is the bluetooth adapter itself.
My listing starts like this:
Bus 004 Device 002: ID 050d:0121 Belkin Components F5D5050 100Mbps Ethernet
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x050d Belkin Components
idProduct 0x0121 F5D5050 100Mbps Ethernet
bcdDevice 1.00
iManufacturer 1 Broadcom Corp
iProduct 2 BELKIN BLUETOOTH USB ADAPTER CL. 1
iSerial 0
bNumConfigurations 1
and ends with:
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 07 21 05 88 13 40 00
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Newbie, can't find device
[not found] ` <200903300928.02545.gene.heskett@verizon.net>
@ 2009-04-01 3:21 ` jayjwa
2009-04-03 3:20 ` Gene Heskett
0 siblings, 1 reply; 7+ messages in thread
From: jayjwa @ 2009-04-01 3:21 UTC (permalink / raw)
To: Gene Heskett; +Cc: linux-bluetooth
On Mon, 30 Mar 2009, Gene Heskett wrote:
> Last night I went through a make xconfig with the intent of turning on the
> module building of anything even remotely related, rebuilt 2.6.28.9 and
> rebooted. FWIW, 2.6.29 is unusable due to loss of networking problems at about
> a 24 hour uptime.
>
> hciconfig -a now returns:
>
> [root@coyote /]# 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:1416 acl:0 sco:0 events:53 errors:0
> TX bytes:475 acl:0 sco:0 commands:53 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: 0x022104
> Service Classes: Networking
> 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)
That looks better. It should be OK now. Maybe it was missing a module.
> And on the reboot, there was a /net directory created on the / drive, but its
> empty.
Not sure what that is, but it's not related to Bluetooth. The only "/net"
directories I'm familiar with are /ect/net from the 'etcnet' Linux networking
project, and the 'net' directory created in the modules tree by Madwifi
wireless kernel module install. Some people make a '/mnt/net' for things like
NFS remote filesystem mounts ...
> From dmseg now:
> [root@coyote linux-2.6.28.9]# dmesg |grep Bluetooth
> [ 8.998327] Bluetooth: Core ver 2.13
> [ 8.998405] Bluetooth: HCI device and connection manager initialized
> [ 8.998407] Bluetooth: HCI socket layer initialized
> [ 9.140422] Bluetooth: Generic Bluetooth USB driver ver 0.3
> [ 21.147971] Bluetooth: L2CAP ver 2.11
> [ 21.147974] Bluetooth: L2CAP socket layer initialized
> [ 21.304643] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [ 21.304646] Bluetooth: BNEP filters: protocol multicast
> [ 21.402288] Bluetooth: SCO (Voice Link) ver 0.6
> [ 21.402291] Bluetooth: SCO socket layer initialized
> [ 22.124825] Bluetooth: RFCOMM socket layer initialized
> [ 22.124837] Bluetooth: RFCOMM TTY layer initialized
> [ 22.124838] Bluetooth: RFCOMM ver 1.10
>
> But there is not yet a /dev/hciX device being created.
That's expected because no such thing exists, the same as there's no
"/dev/eth0" or such on Linux.
> What is next?
That depends on what you want to do exactly. You should be able to follow the
commands from my first post, to bind an rfcomm device (assuming you're trying
to connect to something like a bluetooth modem, since you mentioned Minicom).
You should be able to view the services available on the remote system now:
sdptool browse <address>
Find the one you want, and note the channel it's on. You can then use rfcomm,
which should make your /dev/rfcomm0 device that's giving access to the remote
device at the specified channel. See 'rfcomm --help' for rfcomm commands (it
doesn't have a "--help" parameter, but doing that will cause the same output
as if it did.)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Newbie, can't find device
2009-04-01 3:21 ` jayjwa
@ 2009-04-03 3:20 ` Gene Heskett
0 siblings, 0 replies; 7+ messages in thread
From: Gene Heskett @ 2009-04-03 3:20 UTC (permalink / raw)
To: jayjwa; +Cc: linux-bluetooth
On Tuesday 31 March 2009, jayjwa wrote:
>
>That depends on what you want to do exactly. You should be able to follow
> the commands from my first post, to bind an rfcomm device (assuming you're
> trying to connect to something like a bluetooth modem, since you mentioned
> Minicom). You should be able to view the services available on the remote
> system now:
>
>
>sdptool browse <address>
sdptool browse local returns a lot of stuff that means little to me until I
'learn the lingo'
Specifying anything but 'local' times out eventually.
>Find the one you want, and note the channel it's on. You can then use
> rfcomm, which should make your /dev/rfcomm0 device that's giving access to
> the remote device at the specified channel. See 'rfcomm --help' for rfcomm
> commands (it doesn't have a "--help" parameter, but doing that will cause
> the same output as if it did.)
>
I have made some small progress in that there are some hcitool commands that
do not return the error screen. For instance:
[root@coyote blueman-1.02]# hcitool dev
Devices:
hci0 11:11:11:11:11:11
This after using "rfcomm bind HCI0 11:11:11:11:11:11 1" and then doing a
listen on channel 1 through 30, but I have NDI how many channels are actually
allocated in the rules for bt devices.
The other end is running a program that outputs the string "CoCo3 at
coyote.den" through that device at 9600 baud about 2x/second till I kill it.
Nothing is heard by hci0 here.
So walk me through setting this up from scratch on the linux end, to connect
to a bt device on the other and about 20 feet away, that if its beacon is
running, and I have no clue how to ascertain that, with an 'eb101' string and
I presume its bdaddr in addition to the string I'm sending. That end is set
for 9600 baud, and I've not stumbled over how to set this end for that speed
yet, so take that into consideration please.
Thank you very much.
--
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)
Break into jail and claim police brutality.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-04-03 3:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-26 0:37 Newbie, can't find device Gene Heskett
2009-03-26 10:59 ` jayjwa
[not found] ` <200903261157.28413.gene.heskett@verizon.net>
2009-03-27 0:23 ` jayjwa
[not found] ` <200903262205.52669.gene.heskett@verizon.net>
2009-03-30 5:03 ` jayjwa
[not found] ` <200903300928.02545.gene.heskett@verizon.net>
2009-04-01 3:21 ` jayjwa
2009-04-03 3:20 ` Gene Heskett
2009-03-26 11:36 ` David Stockwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox