[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Modif of function hci_receive_bcsp : strange behavior



> -----Original Message-----
> From: Steven Singer [mailto:steven.singer@xxxxxxx.com]
> Sent: 26 February 2002 18:48
> To: Alain Paschoud
> Cc: Bluetooth Dev; pkj@xxxxxxx.com
> Subject: Re: [bluetooth-dev] Modif of function hci_receive_bcsp :
> strange behavior
> 
> Hi Alain,
> 
> While looking through your log, I noticed this. It's nothing 
> to do with your current problem, but it relates to the the
> problem you were discussing in the thread "BCSP synchronisation"
> 
> > send_cmd_queue:  (7):
> > 0x01 0x05 0x0c 0x03 0x00 0x73 0x60
> 
> Which decodes as:
> 
> 01   HCI Command Packet
> 0c05 Command HCI_Set_Event_Filter
> 03   3 bytes of parameters
> 00   Clear all filters
> 73   *** Illegal trailing byte ***
> 60   *** Illegal trailing byte ***
> 
> To quote from the Bluetooth 1.1 Core spec, part H:1 section 
> 4.7.3, page 625 (the table about filter types):
> 
>   [Filter type 0x00 means] Clear All Filters (Note: In this case, the
>   Filter_Condition_type and Condition parameters should not be given,
>   they should have a length of 0 bytes. Filter_Type should be the only
>   parameter.)
> 
> The trailing junk is causing BlueCore to generate the hardware error
> 0x1c which you see later in your log. I think you're getting lucky at
> the moment and the command is being processed correctly on your
> firmware version (hci-12.7). I say this as I can see you get a command
> complete (status success) back. In fact I think this behaviour is
> wrong. In the Bluetooth 1.1 Core spec, part H:1 section 6.18, page
> 772, it says:
> 
>   The 'Invalid HCI Command Parameters' error code is returned by the
>   Host Controller in the Status parameter of an event when the total
>   parameter length [...] does not conform to what is specified in this
>   document.
> 
> So really all host controllers should be giving an error code for this
> command. The fact that the bug has survived so long suggests that host
> controllers do not check their command arguments rigorously.
> 
> 	- Steven

Worship :)

The thing is that it wasn't trying to clear the filters, it was trying
to set one. It was only that someone had added an & too many in the
wrong place which meant it tried to use the address instead of the
values (which should have been 2,0,1) when setting the filter...

The problem has now been fixed and the solution commited to the CVS.

Thanks again.

//Peter
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com