Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

coap_send IPv6 #1467

Open
cristianpetrache7 opened this issue Jul 12, 2024 · 1 comment
Open

coap_send IPv6 #1467

cristianpetrache7 opened this issue Jul 12, 2024 · 1 comment

Comments

@cristianpetrache7
Copy link

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 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!

@mrdeep1
Copy link
Collaborator

mrdeep1 commented Jul 12, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants