Packets with a variable len equal to zero were not received.
Since no more data expected (and input buffer entirely consumed), we
need to complete/forward the packet immediately instead of waiting for
more data.
Fix this by completing the packet on !dlen.
happening if two cases:
- no variable data len
- variable data len is zero.
Signed-off-by: Loic Poulain <[email protected]>
---
drivers/bluetooth/hci_h4.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index 57faddc..5bd8301 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -223,8 +223,7 @@ struct sk_buff *h4_recv_buf(struct hci_dev *hdev, struct sk_buff *skb,
switch ((&pkts[i])->lsize) {
case 0:
/* No variable data length */
- (&pkts[i])->recv(hdev, skb);
- skb = NULL;
+ dlen = 0;
break;
case 1:
/* Single octet variable length */
@@ -252,6 +251,12 @@ struct sk_buff *h4_recv_buf(struct hci_dev *hdev, struct sk_buff *skb,
kfree_skb(skb);
return ERR_PTR(-EILSEQ);
}
+
+ if (!dlen) {
+ /* no more data, complete frame */
+ (&pkts[i])->recv(hdev, skb);
+ skb = NULL;
+ }
} else {
/* Complete frame */
(&pkts[i])->recv(hdev, skb);
--
1.9.1
Hi Loic,
> Packets with a variable len equal to zero were not received.
> Since no more data expected (and input buffer entirely consumed), we
> need to complete/forward the packet immediately instead of waiting for
> more data.
>
> Fix this by completing the packet on !dlen.
> happening if two cases:
> - no variable data len
> - variable data len is zero.
>
> Signed-off-by: Loic Poulain <[email protected]>
> ---
> drivers/bluetooth/hci_h4.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
I updated the commit message slightly and then applied the patch to bluetooth-next tree.
Regards
Marcel
Hi Loic,
>> please give me an example of such a packet. I am currently failing to see what is wrong with the code and how this patch would actually help.
>>
>> Is this for vendor packet types or does this actually happen with standard H:4 packet types?
>
>
> Yes, this is for some vendor specific packets.
> For example, I have to deal with LPM packet with the following format:
>
> |0xf1|opcode|dlen|data|
>
> This kind of packet can be easily added to the h4_recv_pkt list.
> However, some of these packets don't have any data (just PM ack packet):
> 0xf1|0x03|0x00
>
> If we receive this packet, the h4_recv_buf function will retrieve the dlen (0) and just wait for more data. As long as there is not new data received (new packet), the LPM packet is not transmitted to the bt core.
so the part that confused me is when you said, that you are fixing this for no variable data length. That part is actually not broken. There you just re-order the code.
Regards
Marcel
Hi Marcel,
> please give me an example of such a packet. I am currently failing to see what is wrong with the code and how this patch would actually help.
>
> Is this for vendor packet types or does this actually happen with standard H:4 packet types?
Yes, this is for some vendor specific packets.
For example, I have to deal with LPM packet with the following format:
|0xf1|opcode|dlen|data|
This kind of packet can be easily added to the h4_recv_pkt list.
However, some of these packets don't have any data (just PM ack packet):
0xf1|0x03|0x00
If we receive this packet, the h4_recv_buf function will retrieve the
dlen (0) and just wait for more data. As long as there is not new data
received (new packet), the LPM packet is not transmitted to the bt core.
Regards,
Loic
--
Intel Open Source Technology Center
http://oss.intel.com/
Hi Loic,
> Packets with a variable len equal to zero were not received.
> Since no more data expected (and input buffer entirely consumed), we
> need to complete/forward the packet immediately instead of waiting for
> more data.
>
> Fix this by completing the packet on !dlen.
> happening if two cases:
> - no variable data len
> - variable data len is zero.
please give me an example of such a packet. I am currently failing to see what is wrong with the code and how this patch would actually help.
Is this for vendor packet types or does this actually happen with standard H:4 packet types?
Regards
Marcel