BG95-M3 CoAP: ETag option wrongly encoded

Hi there,

I noticed my BG95-M3 (FW BG95M3LAR02A03_01.014.01.014) hex-encodes the ETag option value in a nonsense way which seems to be a bug:

Get a backend resource in application/json format, response includes an ETag option for subsequent requests:

AT+QCOAPCFG="pdpcid",1,1
Preformatted text`AT+QCOAPCFG="trans",1,4,5
AT+QCOAPOPEN=1,"SOME_HOST",5683
AT+QCOAPHEADER=1,1000,1
AT+QCOAPOPTION=1,0,0,11,"SOME_PATH_SEGMENT"
AT+QCOAPOPTION=1,0,1,17,50
AT+QCOAPSEND=1,0,1,3
...
+QCOAPRECV: 1,1000,2.05,6,D304BFD0D34E,2,4,"F46ECDE6",12,50,183
<resource payload>

Request works, F46ECDE6 is the servers current resource ETag value.

Now request the same resource again, and this time apply the ETag:

AT+QCOAPCFG="pdpcid",1,1
AT+QCOAPCFG="trans",1,4,5
AT+QCOAPOPEN=1,"SOME_HOST",5683
AT+QCOAPHEADER=1,1000,1
AT+QCOAPOPTION=1,0,0,11,"SOME_PATH_SEGMENT"
AT+QCOAPOPTION=1,0,1,17,50
AT+QCOAPOPTION=1,0,2,4,"F46ECDE6"
AT+QCOAPSEND=1,0,1,7

The backend receives the following wrong ETag value: 46343645

Seems this resulted from taking the first 4 characters of my Etag option value (F46E), converting each into their ASCII HEX representation and concatenating the results - which obviously is wrong and makes it impossible to send the received ETag value back to the server in order to safe bandwidth!

Can anybody confirm this is a firmware issue?

Regards,
Sven

This issue seem a bug ,

I need involve in more R&D engineer to resolved it , if it blocked your work , pls reach out to : stephen.li@quectel.com ,

we will reslove it by mail loop or internal ticket.