You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using the library in an IPv6 environment. At some point, I have some router advertisements (RAs) that change the preferred prefix on the interface from where the requests are sent. The old IPv6 value that was set as the source for address for my requests is invalidated and at some point removed. The requests are continued to be sent with the old address since I'm trying to reuse it. The request is not succeeding, but coap_send is not returning COAP_INVALID_MID either. However, if I set an IPv4 as my source address for the requests, I see that coap_send returns COAP_INVALID_MID and there are also logs like these:
coap_socket_send: Network is unreachable
* 10.42.0.1:39516 <-> 10.42.0.1:5683 UDP : netif: failed to send 25 bytes (Network is unreachable) state 4
The behavior can be observed with both confirmable and non-confirmable requests.
Has anyone else encountered this?
Thank you!
The text was updated successfully, but these errors were encountered:
I have not specifically seen this. The libcoap client uses a connect() call (even though it is UDP) to make sure that for that particular socket that the 5-tuple is maintained. If the source address is defined, the libcoap client will bind() to this address before doing the connect() call, otherwise the OS kernel will choose what is appropriate for the source information.
If the underlying send() used by coap_socket_send() does not report an error when the source IPv6 address becomes stale and removed, then I am not sure what libcoap can do to handle the error.
Using CONfirmable requests, the transmission will eventually time out (by default after MAX_TIMEOUT (93 secs)) as there is no response, which can be picked up and handled in the NACK handler (COAP_NACK_TOO_MANY_RETRIES).
Hello,
I am using the library in an IPv6 environment. At some point, I have some router advertisements (RAs) that change the preferred prefix on the interface from where the requests are sent. The old IPv6 value that was set as the source for address for my requests is invalidated and at some point removed. The requests are continued to be sent with the old address since I'm trying to reuse it. The request is not succeeding, but
coap_send
is not returningCOAP_INVALID_MID
either. However, if I set an IPv4 as my source address for the requests, I see thatcoap_send
returnsCOAP_INVALID_MID
and there are also logs like these:The behavior can be observed with both confirmable and non-confirmable requests.
Has anyone else encountered this?
Thank you!
The text was updated successfully, but these errors were encountered: