Invalid attribute value length (recvd error response)

[Vincent25]

Target : NRF52832 as Server

Description of the problem (seen in wireshark)

Client : write request (0x12)

Server: Rcvd Error Response - Invalide Attribute value length ,

I don't understand the problem because i think the answer is provided by the nrf framework.

I didn't write any code to answer to the write.

i only indicate the datas of the characteristics written by the client

with an indication

according to me the answer is in the specification (0xD)

how can i answer the code 0xD?

Is it provided by the framework?

thank you

[Edvin]

Hello,

I don't think you are looking in the right place.

From your second screenshot, the Sequence number is wrong. This means that the device that sent this message is using the wrong sequence number because the other device (or the sniffer, actually) didn't pick up the last packet. This requires a retransmit, but that is not something that you have to worry about, because the SoftDevice (the Bluetooth Stack) will handle that for you. 

Are you using indications?

If this is something that you need to and want to use, either because the specification requires it for this particular BLE service, or if you intend to use indications in your application, that is ok. If not, I recommend that you look into using notifications instead. 

The difference between indications and notifications is what layer the message is ACKed in. (Not related to the Sequence Number from your sniffer trace, because that is the acknowledge in another layer).

So when you use notifications, the packet with the data is Aknowledged in the Link Layer. This means that when the receiver has received the message with the correct CRC, it is ACKed immediately, and then the message is forwarded to your application. 

Now, indications are not acked in the link layer, but in the application layer. This means that when you receive the packet/message, it is forwarded to the application, and you want to either check the content, or perform some action (i.e. lock a doorlock and check that this is a valid state, or that the doorlock isn't jammed) before you acknowledge the indication. 

It is not possible for a client to write to a characteristic/service using indications. Indications and notifications is sort of a subscription for a service that the server (peripheral) will send to the client (central). 

What is the reason you started sniffing this connection? What is the issue that occured in your application? Did you try to write something to a service from a central, and the characeristic didn't update? Did you receive any events on the peripheral side? If so, what event?

Best regards,

Edvin

[Vincent25]

Hi Edwin,

  Thank you for your reply!!!!!

My aim is to connect an home trainer to Zwift.

I follow the specification of FTMS (buetooth org)

In this specification there is a control point and the client (Zwift) write into it.

The client writes with a write request. it's in the FTMS specification.

And the server sens a "write response". I think it is a 0x13 according to the generic specification I gave you.

Added to that, I answer an indication . I put the code of the indication in my programm.

But i think the problem seen in wireshark is not caused by the indication but by the write response.

Is the write response done by the framework?

Why do i use a the nrfSniffer?

because i don't have any support of any sample code of ftms client.

And there is no support provided by zwift.

you are the only one support for me (thank you for that!!!)

I use nrf connect to communicate with my server and it works.

i don't try to sniff the communication beetween nrfconnect an my server . I 'll do it soon.

for the moment the communication between  my server and zwift work fine except this write into the control point

thank you

Vincent

[Edvin]

So the nRF is the Bluetooth Low Energy central/client, and not the peripheral/server?

You don't have to read the BLE specification that carefully. Our SoftDevice (Bluetooth stack) handles most of the low layer stuff, but if you as a central have enabled indications and you have received an indication, you need to reply/acknowledge to it from your application. Please take a look at this message sequence chart:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.0.1/group___b_l_e___g_a_t_t_c___h_v_i___m_s_c.html

So you need to call sd_ble_gattc_hv_confirm(handle); some time after you have received the indication.

BR,

Edvin

[Vincent25]

Hi Edvin,

Thank you for your answer.

I  think Idon't have to replyto an indication .

I developp the server.

So I must reply to the client which write a request into a control point characteristic.

And first of all I must write a response

and after i must indicate the datas of the control point

for the write response actuallly in my software i don't do anythink and for the indication, i indicate the values as described in the following specification

added to that i think i make a mistake because the client (zwift ) repeat always the same write request and the error from the server (me) i always the same.

best regards

Thank you for your help.

Vincent

 

[Vincent25]

Hi Edvin,

  I tried to write into the control point with nRFConnect

And i think it works fine

Here is the write request from nRFConnect:

.

And here is the answer from the server (my software)

we can see that the UUID is well decoded and the response provided by the framework (0x13) is sent by the server. I think it's OK.

But when I catch the write request sent by Zwift , i have this.

How can I have a problem in my software if the sniffer cannot decode the request?

and i see that exactly the same frame is sent every 2 or 3 seconds. so it's not a problem of radio because the sniffer see exactly the same bits sent by zwift.

Do you have any idea to proceed?

Thank you

Vincent