Invalid attribute value length (recvd error response)

RE: Invalid attribute value length (recvd error response)

Edvin — Fri, 31 Jan 2020 15:38:14 GMT

Can you show me how you answer to it with the indication? And where you call sd_ble_gatts_rw_authorize_reply? You can show me some snippets or something.

The indication will appear as a separate line, and not just part of a packet. To be honest, I don't know what you are trying to show me with the screenshots. Perhaps you can send the sniffer trace as a pcapng file? (default file type that it is saved as).

Just to say something sensible about the latest screenshot, this is the packet from the central to the peripheral, containing the write request. The reply to that will not be in the same packet. This is only communication from central to peripheral.

RE: Invalid attribute value length (recvd error response)

Vincent25 — Fri, 31 Jan 2020 14:50:32 GMT

Hi Edvin,

Yes i catch a write request event.

And i answer to it with an indication.

But i don't see the indication on wireshark!

so is it normal?

Or should i see a line in wireshark with "indication" written ?

added to that, i have an other question:

how do you explain that with nRFconnect i see a correct sequence with wireshark but when it is zwift, in wireshark it seem to have some errors.

but i think it cannot be a problem of radio because Zwift send only exactly the same write request and it is only shown in wireshark with an error:

Here is the write request sent by zwift:

and here is the write request sent by nRFConnect (me)

And how do you explain that with nRFConnect there is a good UUID detection with wireshark but not when the write is sent by Zwift?

I 'll see the sample you sent to me

thank you

Vincent

and here is the write request sent by me with nRFConnect:

RE: Invalid attribute value length (recvd error response)

Edvin — Fri, 31 Jan 2020 10:37:45 GMT

You are developing the peripheral. Ok.

So since the peripheral owns the characteristic with the indication, you don't need to reply to it. That is correct. The Zwift should reply to it, but let us assume it does.

What you are asking is how to reply to the write request? Do you get the event in your application?

Please take a look at this sequence chart:

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

So you need to call sd_ble_gatts_rw_authorize_reply() after you receive the write request event. Do you get this event?

RE: Invalid attribute value length (recvd error response)

Vincent25 — Fri, 31 Jan 2020 08:18:08 GMT

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

RE: Invalid attribute value length (recvd error response)

Vincent25 — Thu, 30 Jan 2020 15:56:55 GMT

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

RE: Invalid attribute value length (recvd error response)

Edvin — Thu, 30 Jan 2020 15:22:38 GMT

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

RE: Invalid attribute value length (recvd error response)

Vincent25 — Thu, 30 Jan 2020 13:00:32 GMT

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

RE: Invalid attribute value length (recvd error response)

Edvin — Thu, 30 Jan 2020 10:19:08 GMT

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