Add Extended Tokens Feature(RFC 8974) in libcoap.

[529433]

Is your feature request related to a problem? Please describe.

I noticed that the serialization of state into tokens is limited by the fact that both Coap over UDP[RFC7252] and Coap over reliable transports[RFC8323] restrict the maximum token length to 8 bytes.But in RFC8974, to overcome this limitation, the token length can be expanded.When is this feature planned to be added to libcoap?

Describe the solution you'd like

Add in support for extended tokens.

Thanks in advance

[mrdeep1]

I actually have code in place to do this, but was waiting for some the other PRs to be merged that add in extra token usage.

[529433]

Thank you for replying. @mrdeep1

[mrdeep1]

@529433 If you could try out #938 (which is waiting for review and merge) and confirm that this works for you, that would be great.

[529433]

Ok，i will try it #938。

[529433]

I use coap-client and coap-server in the example to test the extended token, capture packets, and analyze Coap packets. However, the result is very confusing.




Why Does a Request Become Two Coap Messages?
Why is the binary content of the first packet so strange?
The second packet appears to match the extended tokens, but the Wireshark fails to identify the packet.

Is the coap-client in the example incorrect?
Thanks in advance

[mrdeep1]

Thanks for doing this review,

Why Does a Request Become Two Coap Messages?

RFC8973 Section 2.2. Discovering Support and in particular
RFC8974 Section 2.2.2. Trial and Error is the test for the Extended Token support which is the first packet you are seeing. The second packet is your actual request.

Why is the binary content of the first packet so strange?

This is the test packet for determining whether the server has Extended Token support or not.

The second packet appears to match the extended tokens, but the Wireshark fails to identify the packet.

It appears that wireshark does not know how to decode Extended Tokens and hence the reporting confusion. The libcoap logs show the correctly decoded packets. For example, wireshark reports the token length as 13, whereas the 13 indicates that you need the first byte of the token (in this case 01) added to 13 which gives 14 as per RFC8974 Section 2.1. Extended Token Length (TKL) Field

Is the coap-client in the example incorrect?

The example is correct and working as expected.

[mrdeep1]

I have updated the documentation for #938 to reflect the initial Extended Token test PDU that is sent.

[529433]

Thank you for your reply,i will check RFC8974 Section 2.2.2. Trial and Error to figure out the meaning of the first packet.

[mrdeep1]

@529433 How is it all going?