This patch fixes the packet type for ESCO Link which was incorrectly
set for EDR ESCO Packet Types. Anding esco_type with ~EDR_ESCO_MASK
results in loosing information of esco packet type (EDR Packet
types are inverted as per BT Spec) that resulted in wrong calculation
of packet type in hci_setup_sync() API causing the HCI Setup Synchronous
Connection Command to fail.
Signed-off-by: Hemant Gupta <[email protected]>
---
net/bluetooth/hci_conn.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 947172b..bff6bc1 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -396,7 +396,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->pkt_type = hdev->pkt_type & SCO_PTYPE_MASK;
break;
case ESCO_LINK:
- conn->pkt_type = hdev->esco_type & ~EDR_ESCO_MASK;
+ conn->pkt_type = hdev->esco_type ^ ~EDR_ESCO_MASK;
break;
}
--
1.7.0.4
Hi Anderson,
On Tue, Apr 3, 2012 at 7:20 PM, Anderson Lizardo
<[email protected]> wrote:
> Hi Hemant,
>
> On Tue, Apr 3, 2012 at 9:15 AM, Hemant Gupta
> <[email protected]> wrote:
>> This patch fixes the packet type for ESCO Link which was incorrectly
>> set for EDR ESCO Packet Types. Anding esco_type with ~EDR_ESCO_MASK
>> results in loosing information of esco packet type (EDR Packet
>> types are inverted as per BT Spec) that resulted in wrong calculation
>> of packet type in hci_setup_sync() API causing the HCI Setup Synchronous
>> Connection Command to fail.
>>
>> Signed-off-by: Hemant Gupta <[email protected]>
>> ---
>> ?net/bluetooth/hci_conn.c | ? ?2 +-
>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> index 947172b..bff6bc1 100644
>> --- a/net/bluetooth/hci_conn.c
>> +++ b/net/bluetooth/hci_conn.c
>> @@ -396,7 +396,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
>> ? ? ? ? ? ? ? ? ? ? ? ?conn->pkt_type = hdev->pkt_type & SCO_PTYPE_MASK;
>> ? ? ? ? ? ? ? ?break;
>> ? ? ? ?case ESCO_LINK:
>> - ? ? ? ? ? ? ? conn->pkt_type = hdev->esco_type & ~EDR_ESCO_MASK;
>> + ? ? ? ? ? ? ? conn->pkt_type = hdev->esco_type ^ ~EDR_ESCO_MASK;
>
> I don't know ESCO, but using XOR (~MASK) will basically invert all
> bits not set in the mask (and keep those in the mask untouched).
>
> This means even reserved/RFU bits will be set. I suspect this is not desirable.
Thanks for the suggestion, I have updated the patch today. Please have
a look at the same and let me know your comments.
>
> Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Marcel,
On Tue, Apr 3, 2012 at 7:30 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Hemant,
>
>> >> This patch fixes the packet type for ESCO Link which was incorrectly
>> >> set for EDR ESCO Packet Types. Anding esco_type with ~EDR_ESCO_MASK
>> >> results in loosing information of esco packet type (EDR Packet
>> >> types are inverted as per BT Spec) that resulted in wrong calculation
>> >> of packet type in hci_setup_sync() API causing the HCI Setup Synchronous
>> >> Connection Command to fail.
>> >
>> > any chance you can add a hcidump trace to the commit message to show
>> > this failure?
>> >
>> I am attaching the hcicump Logs, that can be viewed in Capture File
>> Viewer of FTS.
>> In that the problem can be seen in HCI Tab, Frame # 619, where the
>> packet type is
>> incorrect resulting in command failure with error code 0x1a.
>
> so me installing a Windows to just view the logs is not going to
> happen ;)
>
> Since you run BlueZ on one side, please just create a hcidump trace. If
> you store them in BTSnoop format, you can open it with FTS as well.
>
I have uploaded another patch, please have a look. I found some issues in my
fix yesterday, so I have updated the patch with proper commit message.
> Regards
>
> Marcel
>
>
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Hemant,
> >> This patch fixes the packet type for ESCO Link which was incorrectly
> >> set for EDR ESCO Packet Types. Anding esco_type with ~EDR_ESCO_MASK
> >> results in loosing information of esco packet type (EDR Packet
> >> types are inverted as per BT Spec) that resulted in wrong calculation
> >> of packet type in hci_setup_sync() API causing the HCI Setup Synchronous
> >> Connection Command to fail.
> >
> > any chance you can add a hcidump trace to the commit message to show
> > this failure?
> >
> I am attaching the hcicump Logs, that can be viewed in Capture File
> Viewer of FTS.
> In that the problem can be seen in HCI Tab, Frame # 619, where the
> packet type is
> incorrect resulting in command failure with error code 0x1a.
so me installing a Windows to just view the logs is not going to
happen ;)
Since you run BlueZ on one side, please just create a hcidump trace. If
you store them in BTSnoop format, you can open it with FTS as well.
Regards
Marcel
Hi Hemant,
On Tue, Apr 3, 2012 at 9:15 AM, Hemant Gupta
<[email protected]> wrote:
> This patch fixes the packet type for ESCO Link which was incorrectly
> set for EDR ESCO Packet Types. Anding esco_type with ~EDR_ESCO_MASK
> results in loosing information of esco packet type (EDR Packet
> types are inverted as per BT Spec) that resulted in wrong calculation
> of packet type in hci_setup_sync() API causing the HCI Setup Synchronous
> Connection Command to fail.
>
> Signed-off-by: Hemant Gupta <[email protected]>
> ---
> ?net/bluetooth/hci_conn.c | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 947172b..bff6bc1 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -396,7 +396,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
> ? ? ? ? ? ? ? ? ? ? ? ?conn->pkt_type = hdev->pkt_type & SCO_PTYPE_MASK;
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case ESCO_LINK:
> - ? ? ? ? ? ? ? conn->pkt_type = hdev->esco_type & ~EDR_ESCO_MASK;
> + ? ? ? ? ? ? ? conn->pkt_type = hdev->esco_type ^ ~EDR_ESCO_MASK;
I don't know ESCO, but using XOR (~MASK) will basically invert all
bits not set in the mask (and keep those in the mask untouched).
This means even reserved/RFU bits will be set. I suspect this is not desirable.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Marcel,
On Tue, Apr 3, 2012 at 7:05 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Hemant,
>
>> This patch fixes the packet type for ESCO Link which was incorrectly
>> set for EDR ESCO Packet Types. Anding esco_type with ~EDR_ESCO_MASK
>> results in loosing information of esco packet type (EDR Packet
>> types are inverted as per BT Spec) that resulted in wrong calculation
>> of packet type in hci_setup_sync() API causing the HCI Setup Synchronous
>> Connection Command to fail.
>
> any chance you can add a hcidump trace to the commit message to show
> this failure?
>
I am attaching the hcicump Logs, that can be viewed in Capture File
Viewer of FTS.
In that the problem can be seen in HCI Tab, Frame # 619, where the
packet type is
incorrect resulting in command failure with error code 0x1a.
> Regards
>
> Marcel
>
>
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Hemant,
> This patch fixes the packet type for ESCO Link which was incorrectly
> set for EDR ESCO Packet Types. Anding esco_type with ~EDR_ESCO_MASK
> results in loosing information of esco packet type (EDR Packet
> types are inverted as per BT Spec) that resulted in wrong calculation
> of packet type in hci_setup_sync() API causing the HCI Setup Synchronous
> Connection Command to fail.
any chance you can add a hcidump trace to the commit message to show
this failure?
Regards
Marcel