This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Invalid attribute value length (recvd error response)

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

Parents
  • 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

  • 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

  • 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

     

  • 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

  • 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?

  • 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:

  • 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. 

Reply
  • 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. 

Children
No Data
Related