BC68 bad CoAP ACK

Hello, I’m working with generic CoAP stack inside the BC68 module (firmware BC68JAR01A08)
I discovered a wrong behavior when the CoAP server reply our POST without a piggybacked response but using a separated way. First the server ACK our POST with an ‘EmptyMessage’ an then send the CoAP response using a separated CON packet. The BC68 module replies with a CoAP ACK using bad source port (5683 instead of 56830 used in the CoAP context and in the previous POST (CON request message)

I created a CoAP context using source port 56830 and then set CoAP Head and Options.
Then I send POST CoAP CONfirmable request using source port 56830 and destination port 5683 (the CoAP server).
The CoAP server replies with CoAP ACK message without response (Empty Message) using source port 5683 and destination port 56830 then, after a short while, it send the CoAP response (2.05) using a new CONfirmable message with source port 5683 and destination 56830 (the BC68 module).
The CoAP stack into BC68 module replies with ACK to CON response message received, using destination port 5683 but wrong source port 5683 instead of 56830 defined in the CoAP context.

In this case the server continues to send CoAP (CON) response 2.05 and the BC68 continues to replay with bad ACK packet, until the server reply timeout expiration.

Is it a known issue? There is some workaround or new firmware to fix it?

Hi Paolo
The local port 5683 has been occupied by the bottom layer. The local port setting range is 1~65536.

Don’t use 5683 and 5684.

Hello Abner,

may be I didn’t explained well the issue…
I dont use port 5683, but I use port 56830 as source port (configured on CoAP context creation), but the BC68 module uses wrong source port when it generates th ACK packet to a CONfirmable CoAP Response emitted by CoAP server.
The CONfirmable CoAP Response is emitted by server with source port 5683 (the server) and destination port 56830 (the BC68 coap client), but the BC68 CoAP client autonomously replies with ACK packet but using wrong source port 5683 instead of 56830 as defined in the coap context

Hi Paolo
Thanks for your feedback. This issue can be solved in our next firmware version. BTW, if urgent test, we can provide you a test firmware version asap.

Hi Abner, we repeated the test using latest BC68 firmware V0110 provided by Italian support, but the issue is still present. I really appreciate if you can provide a test firmware ASAP to check if the issue is solved.

Moreover we discovered another serious CoAP issue
When the server doesn’t replies at all to BC68 CoAP CONfirmable Request (no ACK/EmptyMessage or ACK/ResponseCode sent by server) the BC68 module doesn’t retries CONfirmable Request transmissions and AT+QCOAPDATASTATUS command always returns “1 Sent, waiting for the response of IoT platform”. We wait up to 10 minutes but the trasmission state never changed. We expected to receive “3 Timeout” or “2 Sending failed” after a while, and we expected also CONfirmable Request retrasmission after ACK timeout expiration.
In this state we cannot terminate the CoAP context because AT+QCOAPDEL command always return ‘CME Error 50’, so the only way to resume CoAP stack operations is the force a BC68 module reset.

Hi Paolo
please upgrade it to leastest frimware to have a try.The following link is the firmware package:

BC68_update

This version is only for testing, can’t be used in MP state. We will fix problem in the next firmware.

Hi Abner

thank you very much for your prompt support!
The testing release fixes both the discovered CoAP issues, the bad source port on ACK to CONfirmable Reponses and the missed CONfirmable Request retrasmission when the server doesn’t replies to BC68 POST Requests.
Now also the AT+QCOAPDATASTATUS responses are consistent with real transaction state.

Good job!

I notice that the base version number of testing firmware is R01A08 (ATI returns BC68JAR01A08_BETA1119) but our current firmware release is BC68JAR01A10. So your ‘starting release’ where CoAP fixing are applied seems older than latest released firmware.
Is it true or is just a ‘labeling’ issue?

In any case I’ll wait for next public firmware release that officially will fixes the CoAP issues.
Can you provide a possible release scheduling?

Regarding the CoAP we opened another thread on this forum BC68 CoAP Block1/2 OPTIONS can you help us also with issue?

Thank you again

Hi Paolo


I saw the version description in your question, so I solved the problem based on your version.

Hi Abner,

I also wrote that we repeated the test using latest official firmware

no problem anyway, your testing firmware fulfills all our application requirements at the moment

Can you help us also with this BC68 CoAP Block1/2 OPTIONS issue ?

Hi Paolo
Can you help us also with this BC68 CoAP Block1/2 OPTIONS issue ?
【abner】I have replied to you.