Hi Gustavo,
On Fri, Oct 29, 2010 at 5:50 PM, Gustavo F. Padovan
<padovan@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> * Vinicius Gomes <vinicius.gomes@xxxxxxxxxxxxx> [2010-10-29 09:41:55 -0400]:
>
>> Hi Ville,
>>
>> On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@xxxxxxxxx> wrote:
>> > Hi Anderson,
>> >
>> > On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
>> >> From: Vinicius Costa Gomes <vinicius.gomes@xxxxxxxxxxxxx>
>> >>
>> >> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
