LE BB error LENGTH_ERROR while trying to send notifications.

[JeanMBoones]

We have a application where data transfers happen through a mechanism where the external client does a write-without-response to send in a command.  The response to the command is sent out in a series of notifications.  This normally all works correctly.  

We are doing a test where where we connect  and configure the CCC and just before writing the command, we do a data length update to 27 bytes (previously 247).  The MTU is still at 247.  I write the response data using sd_ble_gatts_hvx which is 89 bytes.   The SD reports success.  This should be split into 4 LL layer packets of up to 27 bytes.  Instead we get several packets that contain LENGTH_ERROR  (See trace screen shot).  The sodera is reporting "Length in header too big for packet type".  

The notification never comes through and the SD never reports the BLE_GATTS_EVT_HVN_TX_COMPLETE event.  Ive checked that the ble_gatts_hvx_params_t structure and length variable stay in scope and are not being overwritten.  

We are using SD S140 v6.1.1 and SDK 15.3

[ovrebekk]

Hi 

Are you able to share the full sniffer log from the sodera sniffer, so we can take a closer look at the communication?

I assume the 'external client' is not a Nordic device, but maybe a smart phone of some kind?

Best regards
Torbjørn

[JeanMBoones]

The other device is a Nordic Dev board.  nrf52840 SDK Board (PCA10056)

[ovrebekk]

Hi 

Thanks for sharing the log, I have forwarded it to the stack team. 

The developer looking at it was quite adamant that at least one of the devices were not running the SoftDevice stack.

Can you confirm which devices you are running on the client and server side?

Best regards
Torbjørn

[JeanMBoones]

The peripheral (advertiser, server?) is running the S140 stack (v6.1.1).  This is the device that is sending out the seemingly incorrect packets.  The central (client?) is running Zephyr  OS v2.0.0.

[ovrebekk]

Hi

Normally the peripheral is the advertiser and server, and the central is the scanner and client, yes. But for the sake of confusion you can have a server on the central side also (and a corresponding client in the peripheral). 

Discussing this with the developers they have seen an issue before where the Zephyr open source link layer would incorrectly send a packet to the peer device at the same time the peer is sending something. This will lead to a packet collision on air, which can confuse the sniffer since it's suddenly receiving two packets at once. 

Is there any chance you can try to configure the central device to use the Nordic link layer instead of the open source one, to see if the issue remains?

Best regards
Torbjørn

[JeanMBoones]

I am not sure its possible to swap things over as its a testing system.  I will give this to the testers.  Thanks.

[ovrebekk]

Hi

Please do. 

The SoftDevice architecture is very mature at this point, and bugs of this nature are extremely rare, so I am pretty sure the issue will go away if you run the SoftDevice/Nordic link layer on both sides. 

Also, you could check which version of the open source link layer they are currently running. There might be a more updated version on the master branch of the Zephyr repository. 

Best regards
Torbjørn