Description

During the testing of #17962, I discovered that something in the transmission behaviour of nanocoap is not working correctly. Using e.g. tests/nanocoap_cli: client put fe80::3478:9157:9fd5:81c3%5 5683 /somepath somedata, to create a resource on a server. The first transmission succeeds, but if you repeat the command, a retransmission is also triggered immediately. Even though the first transmission succeeds, the first call to sock_udp_sendv() in nanocoap_sock_request_cb() returns the expected value, but the message is not sent out (?). At least it does not appear in wireshark. Then the first call to sock_udp_recv_buf() always returns -ETIMEDOUT. But then in the second call to sock_udp_sendv(), the message is sent out and appears in wireshark.

Steps to reproduce the issue

• I use libcoap´s coap-server: coap-server -A fe80::3478:9157:9fd5:81c3%eth0 -d 1.
• I connect nucleo-f767zi over Ethernet with my notebook, where the server is running.
• I compile and flash tests/nanocoap_cli: CFLAGS+=-DCONFIG_GNRC_IPV6_NIB_ARSM=1 BOARD=miot-nucleo-f767zi make flash term.
• I open wireshark and repeat the nanocoap client put command: client put fe80::3478:9157:9fd5:81c3%5 5683 /somepath somedata and see the attached result.

Expected results

The nanocoap client should not immediately trigger a retransmission, but wait for [ACK_TIMEOUT, ACK_TIMEOUT * RANDOM_FACTOR], before it triggers the first retransmission.

Actual results

Most of the time, the retransmission happens immediately, if the server is not very fast with the ACK.
nanocoap_cli_put.pcapng.gz

Versions

Linux 5.18.3-arch1-1
(but that´s not relevant)