L2CAP SDU Length

RE: L2CAP SDU Length

ovrebekk — Fri, 21 Aug 2020 06:46:07 GMT

Hi Torsten

I am happy to help, good to hear you got it working 🙂

I wasn't aware packets could be simply dropped on the iOS side, but I haven't handled a lot of iOS support either.

Best regards
Torbjørn

RE: L2CAP SDU Length

Torsten Robitzki — Tue, 04 Aug 2020 09:49:38 GMT

Hello Torbjørn,
yes, in Vol. 3, 3.4 there is one figure that describes the frame layout of L2CAP connection-oriented channel SDUs (in Version 5.2. of the spec, it’s figure 3.12, but I think we are talking about the same here).

Sorry, I think I’ve missed, that there is already the "Total SDU length, in bytes.“ in the ble_l2cap_evt_ch_rx_t. This is exactly what I need to find the start / end of an SDU.

And yes, I totally agree with you, that in a perfect world, there should be nearly no use for L2CAP. However, in reality a lot of BLE controller stacks (like the ones from Apple) give no back pressure when writing to a characteristic, but just silently drop data and more important, don’t let you fully utilize a connection event.

I’m implementing a BLE SWD debug probe. It’s possible to upload with more than 80 kByte/s, using L2CAP. Currently I use some kind of OTS control point procedures, to write commands to the probe and use the L2CAP channel to send the data that belongs to the commands. Using this schema, it takes a whole connection event just to transfer the control point request. So I would like to prepend the control point request to the data SDU. This requires me to recognize the start of a SDU on the receiving side.

Thanks for your support!

Torsten

RE: L2CAP SDU Length

ovrebekk — Tue, 04 Aug 2020 08:53:57 GMT

Hi Torsten

Sorry for the slow response. Kenneth is currently out in vacation, and I will handle your case in the mean time.

Which part of the spec are you referring to?
Figure 3.6 in vol 3, part A, chapter 3.4?

If I understand correctly you want to assemble a larger packet manually by adding up smaller transfers over the air?

The ble_app_ots example in the SDK should work more or less the same way, I don't know if you have had a look at that?
The object transfer service is essentially designed to send files or records over an L2CAP COC channel, so it sounds relevant to what you are trying to do.

Also, are you sure that using L2CAP COC is needed in the first place?
When using larger MTU's and attribute sizes the overhead when using standard GATT services over L2CAP COC is very small.

Best regards
Torbjørn

RE: L2CAP SDU Length

Torsten Robitzki — Wed, 29 Jul 2020 16:27:25 GMT

UpUp :-)

RE: L2CAP SDU Length

Torsten Robitzki — Tue, 14 Jul 2020 11:40:13 GMT

I'm quite sure, the information (frame boundaries) are available over-air, because the spec says so ;-) Maybe, if this information is not made available by the softdevice, is there a chance that I could request that information as a feature request toward the softdevice? (in theory, an event denoting the frame start and frame size would be sufficient, I think)

RE: L2CAP SDU Length

Kenneth — Tue, 14 Jul 2020 11:34:36 GMT

I can see from the event that only a pointer to the buffer and a length is passed to the application, so you must handle this in some other way yes. I believe maybe the L2CAP packet only have 4 bytes overhead (length + channel ID), so likely the data you request is not available over-air.