Newbie, can't find device

Newbie, can't find device

[Gene Heskett]

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

Re: Newbie, can't find device

[jayjwa]

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

Re: Newbie, can't find device

[jayjwa]

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.

Re: Newbie, can't find device

[jayjwa]

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)

Re: Newbie, can't find device

[jayjwa]

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

Re: Newbie, can't find device

[Gene Heskett]

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.

Re: Newbie, can't find device

[David Stockwell]

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