I'd like to use bluez to perform a device inquiry with RSSI using a
bluetooth 1.2 device. Currently, I'm using an Anycom USB-120
bluetooth adapter with the latest firmware installed.
I want to check the inquiry mode of the bluetooth device first and
then change it if needed. Based on my reading of the bluez headers
and the bluetooth spec, this is what I came up with.
// first read the current mode and see if we need to change it
{
struct hci_request req;
char raw_rp[EVT_CMD_COMPLETE_SIZE + READ_INQUIRY_MODE_RP_SIZE];
read_inquiry_mode_rp *rp;
req.ogf = OGF_LINK_CTL;
req.ocf = OCF_READ_INQUIRY_MODE;
req.cparam = 0;
req.clen = 0;
req.rparam = &raw_rp;
req.rlen = READ_INQUIRY_MODE_RP_SIZE;
err = hci_send_req( sock, &req, 0 );
if( err ) {
if( errno == EPERM ) {
fprintf(stderr, "permission denied while reading inquiry "
"mode. Are you sure you're superuser?\n");
}
return -1;
}
rp = (read_inquiry_mode_rp*)(raw_rp + EVT_CMD_COMPLETE_SIZE);
if( rp->status != 0 ) {
fprintf(stderr, "error 0x%x reading inquiry mode\n",
rp->status);
return -1;
}
change_inquiry_mode = (! rp->mode);
fprintf(stderr, "done reading inquiry mode. %s to set\n",
change_inquiry_mode?"Need":"Do not need");
}
// set the inquiry mode (use RSSI or not) if needed
if( change_inquiry_mode )
{
write_inquiry_mode_cp wim_cp;
struct hci_request req;
char raw_rp[EVT_CMD_COMPLETE_SIZE + WRITE_INQUIRY_MODE_RP_SIZE];
write_inquiry_mode_rp *rp;
wim_cp.mode = do_inquiry_with_rssi;
req.ogf = OGF_LINK_CTL;
req.ocf = OCF_WRITE_INQUIRY_MODE;
req.event = EVT_CMD_COMPLETE;
req.cparam = &wim_cp;
req.clen = WRITE_INQUIRY_MODE_CP_SIZE;
req.rparam = &raw_rp;
req.rlen = EVT_CMD_COMPLETE_SIZE + WRITE_INQUIRY_MODE_RP_SIZE;
err = hci_send_req( sock, &req, 0 );
if( err ) {
fprintf(stderr, "error while setting inquiry mode. errno %d\n",
errno);
perror("hci_send_cmd");
return -1;
}
rp = (write_inquiry_mode_rp*)(raw_rp + EVT_CMD_COMPLETE_SIZE);
if( rp->status != 0 ) {
fprintf(stderr, "error 0x%x setting inquiry mode\n",
rp->status);
return -1;
}
fprintf(stderr, "Done setting inquiry mode\n");
}
My first question is - is this the correct way to do it?
When I run this with the anycom bluetooth device, the very first
hci_send_req never returns. I expected the READ_INQUIRY_MODE command
to generate a CMD_COMPLETE event, but no event is ever generated (I
tested this separately). Also, when hcidump is run concurrently with
this program, it doesn't pick anything up (no events are read by
hcidump) The same happens if I try to set the inquiry mode directly
without reading it first (the WRITE_INQUIRY_MODE command never
returns)
Here's the information that bluez gets out of the bluetooth adapter
# hciconfig -a hci1 features
hci1: Type: USB
BD Address: 00:0B:0D:30:0A:99 ACL MTU: 120:20 SCO MTU: 64:0
Features: 0xff 0xff 0x05 0x78 0x18 0x10 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
<enhanced iscan> <interlaced iscan> <interlaced pscan>
<inquiry with RSSI> <AFH cap. slave> <AFH class. sla
# hciconfig -a hci1
hci1: Type: USB
BD Address: 00:0B:0D:30:0A:99 ACL MTU: 120:20 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:1205 acl:0 sco:0 events:31 errors:0
TX bytes:324 acl:0 sco:0 commands:18 errors:0
Features: 0xff 0xff 0x05 0x78 0x18 0x10 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Can't read local name on hci1. Connection timed out(110)
Any and all help is appreciated. Thanks!
-albert
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Albert,
> > Attached is a patch for bluez-libs. Two functions are added.
>
> please ignore previous message. That patch doesn't follow the
> naming/tabbing conventions in the rest of bluez-libs. Attached is a
> patch that does.
the coding style is still not correct and you screwed the patch up by
inserting memset() that overrides previous set values. Besides this you
set the rq.rlen wrong.
I implemented the hci_{read|write}_inquiry_mode() functions by myself
and also changed hciconfig to use them. My version is not so different
from yours, but the details matter. Please compare them and start
sending in more patches to enhance the Bluetooth library.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> Attached is a patch for bluez-libs. Two functions are added.
please ignore previous message. That patch doesn't follow the
naming/tabbing conventions in the rest of bluez-libs. Attached is a
patch that does.
-albert
> You should re-read the HCI part of the Bluetooth specification, because
> the OGF and OCF values are packed in a specific format. If the latest
> version of hcidump shows unknown then you should think about an error on
> your side, because I already added full Bluetooth 1.2 support.
Attached is a patch for bluez-libs. Two functions are added.
int hci_read_inquiry_mode(int dd, uint8_t *mode, int to);
int hci_write_inquiry_mode(int dd, uint8_t mode, int to);
Thanks for all your help!
-albert
Hi Albert,
> > what is actually attached on your USB bus (check with lsusb), because
> > this device is a CSR dongle and the one from your other email is not.
>
> Sorry about that. There were two bluetooth adapters attached. I've
> removed the csr dongle. Here's the relevant output of lsusb -v
if I ask for lsusb then I don't expect lsusb -v, because otherwise I had
asked for it ;)
> Also, I tried a 2.6.8 kernel compiled with no SCO support in the
> hci_usb driver. The results I got were slightly different. Again,
> here is the output of hciconfig features and hciconfig -a
>
> $ uname -a
> Linux ocha 2.6.8-ash-20041019-1 #1 Tue Oct 19 12:14:55 EDT 2004 i686 GNU/Linux
> $ hciconfig -a hci0
> hci0: Type: USB
> BD Address: 00:0B:0D:30:0A:99 ACL MTU: 120:20 SCO MTU: 64:0
> UP RUNNING PSCAN ISCAN
> RX bytes:1641 acl:0 sco:0 events:85 errors:0
> TX bytes:445 acl:0 sco:0 commands:46 errors:0
> Features: 0xff 0xff 0x05 0x78 0x18 0x10 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'ocha-0'
> Class: 0x000100
> Service Classes: Unspecified
> Device Class: Computer, Uncategorized
> HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x757
> Manufacturer: Silicon Wave (11)
> $ hciconfig hci0 features
> hci0: Type: USB
> BD Address: 00:0B:0D:30:0A:99 ACL MTU: 120:20 SCO MTU: 64:0
> Features: 0xff 0xff 0x05 0x78 0x18 0x10 0x00 0x00
> <3-slot packets> <5-slot packets> <encryption> <slot offset>
> <timing accuracy> <role switch> <hold mode> <sniff mode>
> <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
> <HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
> <enhanced iscan> <interlaced iscan> <interlaced pscan>
> <inquiry with RSSI> <AFH cap. slave> <AFH class. slave>
> <AFH class. master>
>
> If I try to issue hci_read_inquiry_mode (ocf 0x44) and
> hci_write_inquiry_mode (ocf 0x45) commands, here's what hcidump -x
> shows
>
> $ hcidump -x
> HCIDump - HCI packet analyzer ver 1.12
> device: hci0 snap_len: 1028 filter: 0xffffffff
> < HCI Command: Unknown (0x01|0x0044) plen 0
> > HCI Event: Command Status (0x0f) plen 4
> 01 01 44 04
> < HCI Command: Unknown (0x01|0x0045) plen 1
> 01
> > HCI Event: Command Status (0x0f) plen 4
> 01 01 45 04
>
> So it appears that even though the device claims to support
> read_inquiry_mode and write_inquiry_mode, it does not recognize the
> commands. I've double checked the bt 1.2 specs and { 0x44, 0x44 } are
> the correct OCF values. I'll check back with the folks at Anycom and
> see if they can give me any useful information.
You should re-read the HCI part of the Bluetooth specification, because
the OGF and OCF values are packed in a specific format. If the latest
version of hcidump shows unknown then you should think about an error on
your side, because I already added full Bluetooth 1.2 support.
Try "hciconfig hci0 inqmode [mode]" to read to write the inquiry mode.
> In the meantime, do you know of any commercially available USB
> Bluetooth 1.2 compliant adapters we could obtain?
If you only care about the inquiry with RSSI support then you can buy
the AVM BlueFRITZ! USB v2.0. Even if this dongle claims not to support
it, it does. Anycom also has a Bluetooth 1.2 dongle and of course you
can update the D-Link DBT-120 Rev. B3 with the Apple firmware.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> what is actually attached on your USB bus (check with lsusb), because
> this device is a CSR dongle and the one from your other email is not.
Sorry about that. There were two bluetooth adapters attached. I've
removed the csr dongle. Here's the relevant output of lsusb -v
Bus 002 Device 002: ID 1310:0001
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x1310
idProduct 0x0001
bcdDevice 15.00
iManufacturer 1 SiW
iProduct 2 SiW
iSerial 3 990A300D0B00
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
Remote Wakeup
MaxPower 50mA
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 bytes 16 once
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 bytes 64 once
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 bytes 64 once
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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 bytes 0 once
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 bytes 0 once
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 bytes 9 once
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 bytes 9 once
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 bytes 17 once
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 bytes 17 once
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 bytes 25 once
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 bytes 25 once
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 bytes 33 once
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 bytes 33 once
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 bytes 49 once
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 bytes 49 once
bInterval 1
----------------
Also, I tried a 2.6.8 kernel compiled with no SCO support in the
hci_usb driver. The results I got were slightly different. Again,
here is the output of hciconfig features and hciconfig -a
$ uname -a
Linux ocha 2.6.8-ash-20041019-1 #1 Tue Oct 19 12:14:55 EDT 2004 i686 GNU/Linux
$ hciconfig -a hci0
hci0: Type: USB
BD Address: 00:0B:0D:30:0A:99 ACL MTU: 120:20 SCO MTU: 64:0
UP RUNNING PSCAN ISCAN
RX bytes:1641 acl:0 sco:0 events:85 errors:0
TX bytes:445 acl:0 sco:0 commands:46 errors:0
Features: 0xff 0xff 0x05 0x78 0x18 0x10 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'ocha-0'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0x757
Manufacturer: Silicon Wave (11)
$ hciconfig hci0 features
hci0: Type: USB
BD Address: 00:0B:0D:30:0A:99 ACL MTU: 120:20 SCO MTU: 64:0
Features: 0xff 0xff 0x05 0x78 0x18 0x10 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
<enhanced iscan> <interlaced iscan> <interlaced pscan>
<inquiry with RSSI> <AFH cap. slave> <AFH class. slave>
<AFH class. master>
If I try to issue hci_read_inquiry_mode (ocf 0x44) and
hci_write_inquiry_mode (ocf 0x45) commands, here's what hcidump -x
shows
$ hcidump -x
HCIDump - HCI packet analyzer ver 1.12
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Unknown (0x01|0x0044) plen 0
> HCI Event: Command Status (0x0f) plen 4
01 01 44 04
< HCI Command: Unknown (0x01|0x0045) plen 1
01
> HCI Event: Command Status (0x0f) plen 4
01 01 45 04
So it appears that even though the device claims to support
read_inquiry_mode and write_inquiry_mode, it does not recognize the
commands. I've double checked the bt 1.2 specs and { 0x44, 0x44 } are
the correct OCF values. I'll check back with the folks at Anycom and
see if they can give me any useful information.
In the meantime, do you know of any commercially available USB
Bluetooth 1.2 compliant adapters we could obtain?
Thanks!!
-albert
Hi Albert,
> > > When I run this with the anycom bluetooth device, the very first
> > > hci_send_req never returns. I expected the READ_INQUIRY_MODE command
> > > to generate a CMD_COMPLETE event, but no event is ever generated (I
> > > tested this separately). Also, when hcidump is run concurrently with
> > > this program, it doesn't pick anything up (no events are read by
> > > hcidump) The same happens if I try to set the inquiry mode directly
> > > without reading it first (the WRITE_INQUIRY_MODE command never
> > > returns)
> >
> > I never saw that on my dongle. Please recompile your kernel without the
> > SCO audio support for the hci_usb driver. What kind of USB host
> > controller are you using? What kernel version do you use?
>
> I am using kernel 2.4.27, compiled from sources available in the
> debian repository. I recompiled without SCO audio support for hci_usb
> and got the same result.
>
> How do I find out what kind of USB host controller I'm using? lspci
> gives the following output:
>
> 0000:00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 04)
> 0000:00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 04)
> 0000:00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 04)
>
> dmesg shows the following lines related to USB
>
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> usb-uhci.c: $Revision: 1.275 $ time 17:39:55 Oct 14 2004
> usb-uhci.c: High bandwidth mode enabled
> usb-uhci.c: USB UHCI at I/O 0xff80, IRQ 19
> usb-uhci.c: Detected 2 ports
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> usb-uhci.c: USB UHCI at I/O 0xff60, IRQ 18
> usb-uhci.c: Detected 2 ports
> usb.c: new USB bus registered, assigned bus number 2
> hub.c: USB hub found
> usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
> hub.c: new USB device 00:1f.2-2, assigned address 2
> usb.c: USB device 2 (vend/prod 0xa12/0x1) is not claimed by any active driver.
> BlueZ HCI USB driver ver 2.7 Copyright (C) 2000,2001 Qualcomm Inc
> usb.c: registered new driver hci_usb
> hub.c: new USB device 00:1f.4-1, assigned address 2
what is actually attached on your USB bus (check with lsusb), because
this device is a CSR dongle and the one from your other email is not.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> looks like it is correct. Send me a patch for the Bluetooth library to
> include this as API functions.
I'll do this once I manage to get everything working, just to be sure
it is correct.
> > When I run this with the anycom bluetooth device, the very first
> > hci_send_req never returns. I expected the READ_INQUIRY_MODE command
> > to generate a CMD_COMPLETE event, but no event is ever generated (I
> > tested this separately). Also, when hcidump is run concurrently with
> > this program, it doesn't pick anything up (no events are read by
> > hcidump) The same happens if I try to set the inquiry mode directly
> > without reading it first (the WRITE_INQUIRY_MODE command never
> > returns)
>
> I never saw that on my dongle. Please recompile your kernel without the
> SCO audio support for the hci_usb driver. What kind of USB host
> controller are you using? What kernel version do you use?
I am using kernel 2.4.27, compiled from sources available in the
debian repository. I recompiled without SCO audio support for hci_usb
and got the same result.
How do I find out what kind of USB host controller I'm using? lspci
gives the following output:
0000:00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 04)
0000:00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 04)
0000:00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 04)
dmesg shows the following lines related to USB
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 17:39:55 Oct 14 2004
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB UHCI at I/O 0xff80, IRQ 19
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
usb-uhci.c: USB UHCI at I/O 0xff60, IRQ 18
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
hub.c: new USB device 00:1f.2-2, assigned address 2
usb.c: USB device 2 (vend/prod 0xa12/0x1) is not claimed by any active driver.
BlueZ HCI USB driver ver 2.7 Copyright (C) 2000,2001 Qualcomm Inc
usb.c: registered new driver hci_usb
hub.c: new USB device 00:1f.4-1, assigned address 2
-albert
Hi Albert,
> I'd like to use bluez to perform a device inquiry with RSSI using a
> bluetooth 1.2 device. Currently, I'm using an Anycom USB-120
> bluetooth adapter with the latest firmware installed.
>
> I want to check the inquiry mode of the bluetooth device first and
> then change it if needed. Based on my reading of the bluez headers
> and the bluetooth spec, this is what I came up with.
>
> // first read the current mode and see if we need to change it
> {
> struct hci_request req;
> char raw_rp[EVT_CMD_COMPLETE_SIZE + READ_INQUIRY_MODE_RP_SIZE];
> read_inquiry_mode_rp *rp;
>
> req.ogf = OGF_LINK_CTL;
> req.ocf = OCF_READ_INQUIRY_MODE;
> req.cparam = 0;
> req.clen = 0;
> req.rparam = &raw_rp;
> req.rlen = READ_INQUIRY_MODE_RP_SIZE;
>
> err = hci_send_req( sock, &req, 0 );
> if( err ) {
> if( errno == EPERM ) {
> fprintf(stderr, "permission denied while reading inquiry "
> "mode. Are you sure you're superuser?\n");
> }
> return -1;
> }
>
> rp = (read_inquiry_mode_rp*)(raw_rp + EVT_CMD_COMPLETE_SIZE);
> if( rp->status != 0 ) {
> fprintf(stderr, "error 0x%x reading inquiry mode\n",
> rp->status);
> return -1;
> }
> change_inquiry_mode = (! rp->mode);
>
> fprintf(stderr, "done reading inquiry mode. %s to set\n",
> change_inquiry_mode?"Need":"Do not need");
> }
>
> // set the inquiry mode (use RSSI or not) if needed
> if( change_inquiry_mode )
> {
> write_inquiry_mode_cp wim_cp;
> struct hci_request req;
> char raw_rp[EVT_CMD_COMPLETE_SIZE + WRITE_INQUIRY_MODE_RP_SIZE];
> write_inquiry_mode_rp *rp;
> wim_cp.mode = do_inquiry_with_rssi;
>
> req.ogf = OGF_LINK_CTL;
> req.ocf = OCF_WRITE_INQUIRY_MODE;
> req.event = EVT_CMD_COMPLETE;
> req.cparam = &wim_cp;
> req.clen = WRITE_INQUIRY_MODE_CP_SIZE;
> req.rparam = &raw_rp;
> req.rlen = EVT_CMD_COMPLETE_SIZE + WRITE_INQUIRY_MODE_RP_SIZE;
>
> err = hci_send_req( sock, &req, 0 );
> if( err ) {
> fprintf(stderr, "error while setting inquiry mode. errno %d\n",
> errno);
> perror("hci_send_cmd");
> return -1;
> }
>
> rp = (write_inquiry_mode_rp*)(raw_rp + EVT_CMD_COMPLETE_SIZE);
> if( rp->status != 0 ) {
> fprintf(stderr, "error 0x%x setting inquiry mode\n",
> rp->status);
> return -1;
> }
>
> fprintf(stderr, "Done setting inquiry mode\n");
> }
>
> My first question is - is this the correct way to do it?
looks like it is correct. Send me a patch for the Bluetooth library to
include this as API functions.
> When I run this with the anycom bluetooth device, the very first
> hci_send_req never returns. I expected the READ_INQUIRY_MODE command
> to generate a CMD_COMPLETE event, but no event is ever generated (I
> tested this separately). Also, when hcidump is run concurrently with
> this program, it doesn't pick anything up (no events are read by
> hcidump) The same happens if I try to set the inquiry mode directly
> without reading it first (the WRITE_INQUIRY_MODE command never
> returns)
I never saw that on my dongle. Please recompile your kernel without the
SCO audio support for the hci_usb driver. What kind of USB host
controller are you using? What kernel version do you use?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel