* [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
@ 2010-10-22 23:56 Anderson Briglia
2010-10-29 10:44 ` Ville Tervo
0 siblings, 1 reply; 6+ messages in thread
From: Anderson Briglia @ 2010-10-22 23:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
As L2CAP packets coming over LE don't have any more encapsulation,
other than L2CAP, we are able to process them as soon as they arrive.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/l2cap.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 2bf083e..1ac44f4 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
{
struct l2cap_conn *conn = hcon->l2cap_data;
+ struct l2cap_hdr *hdr;
+ int len;
if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
goto drop;
BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
+ if (hcon->type == LE_LINK) {
+ hdr = (struct l2cap_hdr *) skb->data;
+ len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
+
+ if (len == skb->len) {
+ /* Complete frame received */
+ l2cap_recv_frame(conn, skb);
+ return 0;
+ }
+
+ goto drop;
+ }
+
if (flags & ACL_START) {
- struct l2cap_hdr *hdr;
struct sock *sk;
u16 cid;
- int len;
if (conn->rx_len) {
BT_ERR("Unexpected start frame (len %d)", skb->len);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
2010-10-22 23:56 [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE Anderson Briglia
@ 2010-10-29 10:44 ` Ville Tervo
2010-10-29 13:41 ` Vinicius Gomes
0 siblings, 1 reply; 6+ messages in thread
From: Ville Tervo @ 2010-10-29 10:44 UTC (permalink / raw)
To: ext Anderson Briglia
Cc: linux-bluetooth@vger.kernel.org, Vinicius Costa Gomes
Hi Anderson,
On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>
> As L2CAP packets coming over LE don't have any more encapsulation,
> other than L2CAP, we are able to process them as soon as they arrive.
Why is this change needed? Was something broken without this patch?
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/l2cap.c | 17 +++++++++++++++--
> 1 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 2bf083e..1ac44f4 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
> static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
> {
> struct l2cap_conn *conn = hcon->l2cap_data;
> + struct l2cap_hdr *hdr;
> + int len;
>
> if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
> goto drop;
>
> BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
>
> + if (hcon->type == LE_LINK) {
> + hdr = (struct l2cap_hdr *) skb->data;
> + len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
> +
> + if (len == skb->len) {
> + /* Complete frame received */
> + l2cap_recv_frame(conn, skb);
> + return 0;
> + }
> +
> + goto drop;
> + }
> +
> if (flags & ACL_START) {
> - struct l2cap_hdr *hdr;
> struct sock *sk;
> u16 cid;
> - int len;
>
> if (conn->rx_len) {
> BT_ERR("Unexpected start frame (len %d)", skb->len);
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ville
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
2010-10-29 10:44 ` Ville Tervo
@ 2010-10-29 13:41 ` Vinicius Gomes
2010-10-29 20:50 ` Gustavo F. Padovan
0 siblings, 1 reply; 6+ messages in thread
From: Vinicius Gomes @ 2010-10-29 13:41 UTC (permalink / raw)
To: Ville Tervo; +Cc: ext Anderson Briglia, linux-bluetooth@vger.kernel.org
Hi Ville,
On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Hi Anderson,
>
> On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
>> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>>
>> As L2CAP packets coming over LE don't have any more encapsulation,
>> other than L2CAP, we are able to process them as soon as they arrive.
>
> Why is this change needed? Was something broken without this patch?
>
This change is needed because without it the receiving side would
always think that it was receiving continuation frames.
As the flags parameter is zero, it would fall into the "} else {"
condition, and because no frame was received before, conn->rx_len
would be zero and the frame would be discarded. Without this patch I
was seeing those "Unexpected continuation frame ..." messages on the
receiving side.
>
>
>>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>> ---
>> net/bluetooth/l2cap.c | 17 +++++++++++++++--
>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index 2bf083e..1ac44f4 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
>> static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
>> {
>> struct l2cap_conn *conn = hcon->l2cap_data;
>> + struct l2cap_hdr *hdr;
>> + int len;
>>
>> if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
>> goto drop;
>>
>> BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
>>
>> + if (hcon->type == LE_LINK) {
>> + hdr = (struct l2cap_hdr *) skb->data;
>> + len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
>> +
>> + if (len == skb->len) {
>> + /* Complete frame received */
>> + l2cap_recv_frame(conn, skb);
>> + return 0;
>> + }
>> +
>> + goto drop;
>> + }
>> +
>> if (flags & ACL_START) {
>> - struct l2cap_hdr *hdr;
>> struct sock *sk;
>> u16 cid;
>> - int len;
>>
>> if (conn->rx_len) {
>> BT_ERR("Unexpected start frame (len %d)", skb->len);
>> --
>> 1.7.0.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Ville
>
Cheers,
--
Vinicius
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
2010-10-29 13:41 ` Vinicius Gomes
@ 2010-10-29 20:50 ` Gustavo F. Padovan
2010-10-30 3:31 ` Vinicius Gomes
2010-11-01 8:51 ` Ville Tervo
0 siblings, 2 replies; 6+ messages in thread
From: Gustavo F. Padovan @ 2010-10-29 20:50 UTC (permalink / raw)
To: Vinicius Gomes
Cc: Ville Tervo, ext Anderson Briglia,
linux-bluetooth@vger.kernel.org
Hi,
* Vinicius Gomes <vinicius.gomes@openbossa.org> [2010-10-29 09:41:55 -0400]:
> Hi Ville,
>
> On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > Hi Anderson,
> >
> > On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
> >> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> >>
> >> As L2CAP packets coming over LE don't have any more encapsulation,
> >> other than L2CAP, we are able to process them as soon as they arrive.
> >
> > Why is this change needed? Was something broken without this patch?
> >
>
> This change is needed because without it the receiving side would
> always think that it was receiving continuation frames.
>
> As the flags parameter is zero, it would fall into the "} else {"
> condition, and because no frame was received before, conn->rx_len
> would be zero and the frame would be discarded. Without this patch I
> was seeing those "Unexpected continuation frame ..." messages on the
> receiving side.
>From what I understood the flags are only for ACL connections and LE
links doesn't have fragmentation, right? So we don't need to check flags
here, actually it seems we don't have flags for LE like ACL.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
2010-10-29 20:50 ` Gustavo F. Padovan
@ 2010-10-30 3:31 ` Vinicius Gomes
2010-11-01 8:51 ` Ville Tervo
1 sibling, 0 replies; 6+ messages in thread
From: Vinicius Gomes @ 2010-10-30 3:31 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Ville Tervo, ext Anderson Briglia,
linux-bluetooth@vger.kernel.org
Hi Gustavo,
On Fri, Oct 29, 2010 at 5:50 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi,
>
> * Vinicius Gomes <vinicius.gomes@openbossa.org> [2010-10-29 09:41:55 -0400]:
>
>> Hi Ville,
>>
>> On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
>> > Hi Anderson,
>> >
>> > On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
>> >> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>> >>
>> >> As L2CAP packets coming over LE don't have any more encapsulation,
>> >> other than L2CAP, we are able to process them as soon as they arrive.
>> >
>> > Why is this change needed? Was something broken without this patch?
>> >
>>
>> This change is needed because without it the receiving side would
>> always think that it was receiving continuation frames.
>>
>> As the flags parameter is zero, it would fall into the "} else {"
>> condition, and because no frame was received before, conn->rx_len
>> would be zero and the frame would be discarded. Without this patch I
>> was seeing those "Unexpected continuation frame ..." messages on the
>> receiving side.
>
> From what I understood the flags are only for ACL connections and LE
> links doesn't have fragmentation, right? So we don't need to check flags
> here, actually it seems we don't have flags for LE like ACL.
>
Yeah, that is what the patch tries to solve. I was just trying to make
clear why the old code doesn't work (seems that I didn't do a good job
;-) .
> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
>
Cheers,
--
Vinicius
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
2010-10-29 20:50 ` Gustavo F. Padovan
2010-10-30 3:31 ` Vinicius Gomes
@ 2010-11-01 8:51 ` Ville Tervo
1 sibling, 0 replies; 6+ messages in thread
From: Ville Tervo @ 2010-11-01 8:51 UTC (permalink / raw)
To: ext Gustavo F. Padovan
Cc: Vinicius Gomes, ext Anderson Briglia,
linux-bluetooth@vger.kernel.org
Hi,
On Fri, Oct 29, 2010 at 10:50:33PM +0200, ext Gustavo F. Padovan wrote:
> Hi,
>
> * Vinicius Gomes <vinicius.gomes@openbossa.org> [2010-10-29 09:41:55 -0400]:
>
> > Hi Ville,
> >
> > On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > > Hi Anderson,
> > >
> > > On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
> > >> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> > >>
> > >> As L2CAP packets coming over LE don't have any more encapsulation,
> > >> other than L2CAP, we are able to process them as soon as they arrive.
> > >
> > > Why is this change needed? Was something broken without this patch?
> > >
> >
> > This change is needed because without it the receiving side would
> > always think that it was receiving continuation frames.
> >
> > As the flags parameter is zero, it would fall into the "} else {"
> > condition, and because no frame was received before, conn->rx_len
> > would be zero and the frame would be discarded. Without this patch I
> > was seeing those "Unexpected continuation frame ..." messages on the
> > receiving side.
>
> From what I understood the flags are only for ACL connections and LE
> links doesn't have fragmentation, right? So we don't need to check flags
> here, actually it seems we don't have flags for LE like ACL.
Yes it has. See spec. Vol 2 Part E 5.4.2.
It seems that controller should not be sending 0 PB flag in any situation
(except loopback). Vinicius that controller are you using?
I haven't seen this ever in my testing.
--
Ville
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-11-01 8:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-22 23:56 [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE Anderson Briglia
2010-10-29 10:44 ` Ville Tervo
2010-10-29 13:41 ` Vinicius Gomes
2010-10-29 20:50 ` Gustavo F. Padovan
2010-10-30 3:31 ` Vinicius Gomes
2010-11-01 8:51 ` Ville Tervo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).