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

Re: [bluetooth-dev] HCI/L2CAP layer experts needed!!!



Michael,

>Do we have any HCI/L2CAP layer experts ?
Every other person on the list ;-)

>Notice two things: The first ACL packet has the PB (Packet Boundary) field set to 10B (0x2) wich means First L2CAP packet.
>The next ACL packet has PB set to 01B (Continuation packet).
>Notice also that I do not repeat the L2CAP header in packet #2.
Looks ok to me.

>My problem is that both packets gets thrown away, they simply don't reach the destination. Actually I have a guess about what could be the reason, because I have read somewhere that the L2CAP header length field is used as an consistency check on the ACL packets. This consistency check will of cause fail on both individual packets, because in packet #1 the L2CAP length field is too long, and in packet #2 it isn't there.
That check should not affect fragmented packets as long as total L2CAP length is correct.

>My questions is as follows:
>- Is my segmentation priciple OK ?
Yes.

>- If it is OK (and I were able to transport the packets), how do I know wich CID ACL packet #2 is for, 
>when I do not add the L2CAP header ?
There is no way to determine CID of second,third,etc fragment. You have to make sure that you send all fragments in the right order and without intermixing 
with any other data.
In my opinion it is sort of HCI limitation. And it actually causes problems when you have multiple connections.

I'd suggest to take a look at BlueZ L2CAP and HCI Core (http://bluez.sf.net). Fragmentation works just fine even with large L2CAP packets.
HCI Connection scheduler makes sure that we don't mix fragmented packets from different L2CAP channels.

Max
  




Maksim Krasnyanskiy		
Senior Kernel Engineer
Qualcomm Incorporated

maxk@xxxxxxx.com
(408) 557-1092

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