Hi Arman, >>> Hmm, according to the spec the "Optional authentication signature for >>> the Attribute Opcode and Attribute Parameters" is 12 octets in length. >>> See "Core v4.1, Vol 3, Part F, Section 3.3.1, Table 3: Format of >>> Attribute PDU", and tell me what I'm missing. Or are you suggesting >>> that we calculate the authentication signature in bt_att? My idea was >>> that the calculation of the signature and resolving (for incoming >>> signed requests) would be handled by an upper layer. >> >> We have to calculate the signature brand new anyway since it is generated over the actual PDU. So yes, lets store the master + slave signature keys in bt_att and handle the signature generation and verification internally. >> > > In that case, we need to access the remote and local sign counters as > well, which change dynamically. Should bt_att store and internally > manage that count then? Basically, the first time the CSRK is > generated, the upper layer stores it by calling > bt_att_set_signing_key() and that function internally initializes the > local sign counter to 0? Similarly, bt_att would also keep track of > the remote sign count? so for the ATT channels you will get a new fd for each connection, either from connect() or from accept() and when you create the bt_att via bt_att_new(), then you also need to set they CSRK if you have them available. But you have a point with the sign counters. I think that for the lifetime of the bt_att, the sign counter should be managed internally. However it might be a good idea to provide the current sign counter when setting the signature key. In addition if we want to make the sign counter persistent, we need a way to read the current one so we can store it. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
