Re: #define OGF_TESTING_CMD potentially wrong?

Hi Peter,

> a few days ago I posted a message concerning testing, i.e. on how to put 
> a Bluetooth module into the test modes specified in the Bluetooth 
> specification Core 2.1 (27.07.2007) using:
> 
> 	hcitool cmd <OGF> <OCF> [params]
> 
> In concrete I was interested in HCI_Write_Loopback_Mode and 
> HCI_Enable_Device_Under_Test_Mode, for which OCF are defined as 0x0002 
> and 0x0003, respectively. OGF is defined as 0x06 in the specification.
> 
> hcitool delivers the command at the bluetooth module. However, hcidump, 
> which uses #defines and tables from bluez-libs, resolves this commands 
> as Unknown, as it would defined in include/hci.h
> 
> #define OGF_TESTING_CMD 0x3e
> 
> If I used OGF=0x3e in the above hcitool command, hcidump would resolve 
> the string correctly, but the bluetooth module would not do what it was 
> told to do.
> 
> To me it appears that the #define in hci.h is potentially wrong, or 
> maybe refers to an older version of the specification, when testing 
> might have been vendor specific.

that hcidump shows something as unknown, doesn't mean that it didn't
work. Actually hcidump is only a passive tool like tcpdump. So feel free
to send a patch to fix hcidump, but this doesn't mean that hcitool is
not working.

Regards

Marcel



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/