libcoap-developers Mailing List for libcoap: C-Implementation of CoAP
Status: Beta
Brought to you by:
obgm
You can subscribe to this list here.
2015 |
Jan
(12) |
Feb
(36) |
Mar
(65) |
Apr
(33) |
May
(27) |
Jun
(35) |
Jul
(21) |
Aug
(3) |
Sep
(50) |
Oct
(17) |
Nov
(4) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2016 |
Jan
(11) |
Feb
(10) |
Mar
(9) |
Apr
(23) |
May
(4) |
Jun
(14) |
Jul
(40) |
Aug
(3) |
Sep
(5) |
Oct
(6) |
Nov
(17) |
Dec
(7) |
2017 |
Jan
(8) |
Feb
(13) |
Mar
(11) |
Apr
(7) |
May
(29) |
Jun
(61) |
Jul
(6) |
Aug
(7) |
Sep
(12) |
Oct
(7) |
Nov
(30) |
Dec
(10) |
2018 |
Jan
(9) |
Feb
(10) |
Mar
(20) |
Apr
(6) |
May
(52) |
Jun
(21) |
Jul
(1) |
Aug
(1) |
Sep
(40) |
Oct
(64) |
Nov
(17) |
Dec
(10) |
2019 |
Jan
(2) |
Feb
(14) |
Mar
(9) |
Apr
(3) |
May
(15) |
Jun
(28) |
Jul
(8) |
Aug
|
Sep
(7) |
Oct
(4) |
Nov
(11) |
Dec
|
2020 |
Jan
(4) |
Feb
(6) |
Mar
(8) |
Apr
(18) |
May
(3) |
Jun
(4) |
Jul
(2) |
Aug
(2) |
Sep
(14) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(12) |
Apr
(18) |
May
|
Jun
(4) |
Jul
|
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
(2) |
2023 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
(5) |
Dec
|
2024 |
Jan
(2) |
Feb
(5) |
Mar
(19) |
Apr
(5) |
May
(10) |
Jun
(11) |
Jul
(2) |
Aug
(2) |
Sep
(12) |
Oct
|
Nov
(2) |
Dec
|
2025 |
Jan
(10) |
Feb
(13) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Olaf B. <ber...@tz...> - 2025-02-26 09:35:39
|
Hi Ashish, On 2025-02-26, ashish macwan <ash...@gm...> wrote: > I am working on product development using Mbed OS, and my > toolchain is IAR. I would like to know if it is possible to use > the libcoap library with the IAR toolchain. libcoap has been designed to be very portable with a lot of different toolchains. There are adaptation layers for OS-specific parts that you might need to make work with Mbed OS. My advice is to give it a try and see where problems might arise. Feel free to ask anytime in this ML or the issue tracker at Github if problems arise. And of course: Contributions in form of PRs are always welcome if you make any progress. Grüße Olaf |
From: ashish m. <ash...@gm...> - 2025-02-26 06:02:43
|
*Hi,* I am working on product development using Mbed OS, and my toolchain is IAR. I would like to know if it is possible to use the libcoap library with the IAR toolchain. -- Regards, Ashish Macwan |
From: Jon S. <sup...@jp...> - 2025-02-18 21:28:12
|
Hi Randy, Yes, there is a global lock for when executing within the libcoap library. No recursive or priority inheritance locking. However this is unlocked in the following (not exhaustive, but the main areas) Whenever a request handler is called and the thread is executing / waiting within that handler. When the thread (in the EPOLL case) is blocked on epoll_wait(). So, yes, thread exhaustion could occur if all the request handlers are taking time of consequence to process the information and there is no spare thread to handle the next incoming request. However, there is nothing stopping a request handler sending back a empty response and then when the response is created / acquired it can be sent back as a Separate (as opposed to a Piggyback) response. For example, this is done when forwarding on a Proxy request to an upstream server. Regards Jon From: Turner, Randy < Ran...@la...> Sent: 18 February 2025 20:58 To: Turner, Randy <Ran...@la...>; sup...@jp... <sup...@jp...>; lib...@li... Subject: RE: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads By long-lived I think the only issue might be exhaustion of a thread pool, but if that happens I guess we configure the size of the thread pool based on anticipated load From: Turner, Randy via libcoap-developers <lib...@li... <mailto:lib...@li...> > Sent: Tuesday, February 18, 2025 3:47 PM To: sup...@jp... <mailto:sup...@jp...> ; lib...@li... <mailto:lib...@li...> Subject: Re: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads It looked like you guys implemented coarse locking (just a big lock around the library.is this correct?) so there could there could be some issues with "long-lived" threads executing requests that take a long time to complete ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd It looked like you guys implemented coarse locking (just a big lock around the library.is this correct?) so there could there could be some issues with "long-lived" threads executing requests that take a long time to complete - I haven't looked at 4.3.5 code much..for Posix threading, did you guys use "recursive" locks or locks that can employ priority inheritance? I'm not even sure if this is supported by Linux since Linux (I don't believe) uses pure thread priority scheduling or not Thanks! Randy From: sup...@jp... <mailto:sup...@jp...> <sup...@jp... <mailto:sup...@jp...> > Sent: Tuesday, February 18, 2025 4:47 AM To: Turner, Randy <Ran...@la... <mailto:Ran...@la...> >; lib...@li... <mailto:lib...@li...> Subject: RE: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads Hi Randy, You simply need to spawn off N threads. All each thread needs to do is to loop on a coap_io_process() as per static void * thread_start(void *arg) { coap_context_t *ctx = (coap_context_t *)arg; while (!quit) { int result = coap_io_process(ctx, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Randy, You simply need to spawn off N threads. All each thread needs to do is to loop on a coap_io_process() as per static void * thread_start(void *arg) { coap_context_t *ctx = (coap_context_t *)arg; while (!quit) { int result = coap_io_process(ctx, COAP_IO_WAIT); if (result < 0) break; } coap_log_debug("Thread %lx exit\n", pthread_self()); return 0; } Then a waiting thread will pick up the next incoming packet. Note, I would leave the original while loop in main() to still call coap_io_process(). As multiple threads are then trying to read the socket to get in the next packet, it is possible to get an EAGAIN error. So, this patch needs to be applied to remove an unwanted warning message diff --git a/src/coap_netif.c b/src/coap_netif.c index 3c53c4b6..1d24bbf6 100644 --- a/src/coap_netif.c +++ b/src/coap_netif.c @@ -105,10 +105,12 @@ coap_netif_dgrm_read_ep(coap_endpoint_t *endpoint, coap_packet_t *packet) { bytes_read = coap_socket_recv(&endpoint->sock, packet); keep_errno = errno; if (bytes_read == -1) { - coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", - coap_endpoint_str(endpoint), packet->length, - coap_socket_strerror()); - errno = keep_errno; + if (errno != EAGAIN) { + coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", + coap_endpoint_str(endpoint), packet->length, + coap_socket_strerror()); + errno = keep_errno; + } } else if (bytes_read > 0) { /* Let the caller do the logging as session available by then */ } It is possible that heavy thread interaction may throw up other things - I can only think of coap_log*() that may split information. Regards Jon From: Turner, Randy via libcoap-developers <lib...@li... <mailto:lib...@li...> > Sent: 17 February 2025 15:24 To: lib...@li... <mailto:lib...@li...> Subject: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads Hi Guys, At the moment, my libcoap DTLS server handles inbound requests in a while() loop calling coap_io_process() Coap_io_process() sits in an epoll() waiting for inbound requests and then processes / dispatches the requests and then returns to the while() loop I would like to intervene in the request dispatch process by having a different thread potentially performing some requests, or optionally to have the "same" thread handle each received request, depending on what type of request was received. Requests that might take a long time to process get their own thread - responses that can be handled quickly by the server would just use the thread that called coap_io_process() - since release 4.3.5 supports multithreading, I was hoping to modify our server in this way Is this type of request handling possible ? Randy |
From: Turner, R. <Ran...@la...> - 2025-02-18 20:58:07
|
By long-lived I think the only issue might be exhaustion of a thread pool, but if that happens I guess we configure the size of the thread pool based on anticipated load From: Turner, Randy via libcoap-developers <lib...@li...> Sent: Tuesday, February 18, 2025 3:47 PM To: sup...@jp...; lib...@li... Subject: Re: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads It looked like you guys implemented coarse locking (just a big lock around the library...is this correct?) so there could there could be some issues with "long-lived" threads executing requests that take a long time to complete ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd It looked like you guys implemented coarse locking (just a big lock around the library...is this correct?) so there could there could be some issues with "long-lived" threads executing requests that take a long time to complete - I haven't looked at 4.3.5 code much....for Posix threading, did you guys use "recursive" locks or locks that can employ priority inheritance? I'm not even sure if this is supported by Linux since Linux (I don't believe) uses pure thread priority scheduling or not Thanks! Randy From: sup...@jp...<mailto:sup...@jp...> <sup...@jp...<mailto:sup...@jp...>> Sent: Tuesday, February 18, 2025 4:47 AM To: Turner, Randy <Ran...@la...<mailto:Ran...@la...>>; lib...@li...<mailto:lib...@li...> Subject: RE: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads Hi Randy, You simply need to spawn off N threads. All each thread needs to do is to loop on a coap_io_process() as per static void * thread_start(void *arg) { coap_context_t *ctx = (coap_context_t *)arg; while (!quit) { int result = coap_io_process(ctx, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Randy, You simply need to spawn off N threads. All each thread needs to do is to loop on a coap_io_process() as per static void * thread_start(void *arg) { coap_context_t *ctx = (coap_context_t *)arg; while (!quit) { int result = coap_io_process(ctx, COAP_IO_WAIT); if (result < 0) break; } coap_log_debug("Thread %lx exit\n", pthread_self()); return 0; } Then a waiting thread will pick up the next incoming packet. Note, I would leave the original while loop in main() to still call coap_io_process(). As multiple threads are then trying to read the socket to get in the next packet, it is possible to get an EAGAIN error. So, this patch needs to be applied to remove an unwanted warning message diff --git a/src/coap_netif.c b/src/coap_netif.c index 3c53c4b6..1d24bbf6 100644 --- a/src/coap_netif.c +++ b/src/coap_netif.c @@ -105,10 +105,12 @@ coap_netif_dgrm_read_ep(coap_endpoint_t *endpoint, coap_packet_t *packet) { bytes_read = coap_socket_recv(&endpoint->sock, packet); keep_errno = errno; if (bytes_read == -1) { - coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", - coap_endpoint_str(endpoint), packet->length, - coap_socket_strerror()); - errno = keep_errno; + if (errno != EAGAIN) { + coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", + coap_endpoint_str(endpoint), packet->length, + coap_socket_strerror()); + errno = keep_errno; + } } else if (bytes_read > 0) { /* Let the caller do the logging as session available by then */ } It is possible that heavy thread interaction may throw up other things - I can only think of coap_log*() that may split information. Regards Jon From: Turner, Randy via libcoap-developers <lib...@li...<mailto:lib...@li...>> Sent: 17 February 2025 15:24 To: lib...@li...<mailto:lib...@li...> Subject: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads Hi Guys, At the moment, my libcoap DTLS server handles inbound requests in a while() loop calling coap_io_process() Coap_io_process() sits in an epoll() waiting for inbound requests and then processes / dispatches the requests and then returns to the while() loop I would like to intervene in the request dispatch process by having a different thread potentially performing some requests, or optionally to have the "same" thread handle each received request, depending on what type of request was received. Requests that might take a long time to process get their own thread - responses that can be handled quickly by the server would just use the thread that called coap_io_process() - since release 4.3.5 supports multithreading, I was hoping to modify our server in this way Is this type of request handling possible ? Randy |
From: Turner, R. <Ran...@la...> - 2025-02-18 20:47:02
|
It looked like you guys implemented coarse locking (just a big lock around the library...is this correct?) so there could there could be some issues with "long-lived" threads executing requests that take a long time to complete - I haven't looked at 4.3.5 code much....for Posix threading, did you guys use "recursive" locks or locks that can employ priority inheritance? I'm not even sure if this is supported by Linux since Linux (I don't believe) uses pure thread priority scheduling or not Thanks! Randy From: sup...@jp... <sup...@jp...> Sent: Tuesday, February 18, 2025 4:47 AM To: Turner, Randy <Ran...@la...>; lib...@li... Subject: RE: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads Hi Randy, You simply need to spawn off N threads. All each thread needs to do is to loop on a coap_io_process() as per static void * thread_start(void *arg) { coap_context_t *ctx = (coap_context_t *)arg; while (!quit) { int result = coap_io_process(ctx, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Randy, You simply need to spawn off N threads. All each thread needs to do is to loop on a coap_io_process() as per static void * thread_start(void *arg) { coap_context_t *ctx = (coap_context_t *)arg; while (!quit) { int result = coap_io_process(ctx, COAP_IO_WAIT); if (result < 0) break; } coap_log_debug("Thread %lx exit\n", pthread_self()); return 0; } Then a waiting thread will pick up the next incoming packet. Note, I would leave the original while loop in main() to still call coap_io_process(). As multiple threads are then trying to read the socket to get in the next packet, it is possible to get an EAGAIN error. So, this patch needs to be applied to remove an unwanted warning message diff --git a/src/coap_netif.c b/src/coap_netif.c index 3c53c4b6..1d24bbf6 100644 --- a/src/coap_netif.c +++ b/src/coap_netif.c @@ -105,10 +105,12 @@ coap_netif_dgrm_read_ep(coap_endpoint_t *endpoint, coap_packet_t *packet) { bytes_read = coap_socket_recv(&endpoint->sock, packet); keep_errno = errno; if (bytes_read == -1) { - coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", - coap_endpoint_str(endpoint), packet->length, - coap_socket_strerror()); - errno = keep_errno; + if (errno != EAGAIN) { + coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", + coap_endpoint_str(endpoint), packet->length, + coap_socket_strerror()); + errno = keep_errno; + } } else if (bytes_read > 0) { /* Let the caller do the logging as session available by then */ } It is possible that heavy thread interaction may throw up other things - I can only think of coap_log*() that may split information. Regards Jon From: Turner, Randy via libcoap-developers <lib...@li...<mailto:lib...@li...>> Sent: 17 February 2025 15:24 To: lib...@li...<mailto:lib...@li...> Subject: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads Hi Guys, At the moment, my libcoap DTLS server handles inbound requests in a while() loop calling coap_io_process() Coap_io_process() sits in an epoll() waiting for inbound requests and then processes / dispatches the requests and then returns to the while() loop I would like to intervene in the request dispatch process by having a different thread potentially performing some requests, or optionally to have the "same" thread handle each received request, depending on what type of request was received. Requests that might take a long time to process get their own thread - responses that can be handled quickly by the server would just use the thread that called coap_io_process() - since release 4.3.5 supports multithreading, I was hoping to modify our server in this way Is this type of request handling possible ? Randy |
From: Jon S. <sup...@jp...> - 2025-02-18 09:46:55
|
Hi Randy, You simply need to spawn off N threads. All each thread needs to do is to loop on a coap_io_process() as per static void * thread_start(void *arg) { coap_context_t *ctx = (coap_context_t *)arg; while (!quit) { int result = coap_io_process(ctx, COAP_IO_WAIT); if (result < 0) break; } coap_log_debug("Thread %lx exit\n", pthread_self()); return 0; } Then a waiting thread will pick up the next incoming packet. Note, I would leave the original while loop in main() to still call coap_io_process(). As multiple threads are then trying to read the socket to get in the next packet, it is possible to get an EAGAIN error. So, this patch needs to be applied to remove an unwanted warning message diff --git a/src/coap_netif.c b/src/coap_netif.c index 3c53c4b6..1d24bbf6 100644 --- a/src/coap_netif.c +++ b/src/coap_netif.c @@ -105,10 +105,12 @@ coap_netif_dgrm_read_ep(coap_endpoint_t *endpoint, coap_packet_t *packet) { bytes_read = coap_socket_recv(&endpoint->sock, packet); keep_errno = errno; if (bytes_read == -1) { - coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", - coap_endpoint_str(endpoint), packet->length, - coap_socket_strerror()); - errno = keep_errno; + if (errno != EAGAIN) { + coap_log_debug("* %s: netif: failed to read %zd bytes (%s)\n", + coap_endpoint_str(endpoint), packet->length, + coap_socket_strerror()); + errno = keep_errno; + } } else if (bytes_read > 0) { /* Let the caller do the logging as session available by then */ } It is possible that heavy thread interaction may throw up other things - I can only think of coap_log*() that may split information. Regards Jon From: Turner, Randy via libcoap-developers <lib...@li...> Sent: 17 February 2025 15:24 To: lib...@li... Subject: [libcoap-developers] coap_io_process() and dispatching of request handling to multiple threads Hi Guys, At the moment, my libcoap DTLS server handles inbound requests in a while() loop calling coap_io_process() Coap_io_process() sits in an epoll() waiting for inbound requests and then processes / dispatches the requests and then returns to the while() loop I would like to intervene in the request dispatch process by having a different thread potentially performing some requests, or optionally to have the "same" thread handle each received request, depending on what type of request was received. Requests that might take a long time to process get their own thread - responses that can be handled quickly by the server would just use the thread that called coap_io_process() - since release 4.3.5 supports multithreading, I was hoping to modify our server in this way Is this type of request handling possible ? Randy |
From: Turner, R. <Ran...@la...> - 2025-02-17 15:23:49
|
Hi Guys, At the moment, my libcoap DTLS server handles inbound requests in a while() loop calling coap_io_process() Coap_io_process() sits in an epoll() waiting for inbound requests and then processes / dispatches the requests and then returns to the while() loop I would like to intervene in the request dispatch process by having a different thread potentially performing some requests, or optionally to have the "same" thread handle each received request, depending on what type of request was received. Requests that might take a long time to process get their own thread - responses that can be handled quickly by the server would just use the thread that called coap_io_process() - since release 4.3.5 supports multithreading, I was hoping to modify our server in this way Is this type of request handling possible ? Randy |
From: Turner, R. <Ran...@la...> - 2025-02-17 14:34:13
|
Yes, I understand – I’m hoping just coap-rd.c will be the only file changed – if our coap-rd.c changes turn out to be useful for others, we will let you know R. From: sup...@jp... <sup...@jp...> Sent: Monday, February 17, 2025 5:28 AM To: Turner, Randy <Ran...@la...>; lib...@li... Subject: RE: [libcoap-developers] coap-rd Hi Randy, There should not need to be any changes in the libcoap library code, just that coap-rd. c needs to be updated. I’m happy to consider / review any generic updates that are not specific to your environment for possible inclusion ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Randy, There should not need to be any changes in the libcoap library code, just that coap-rd.c needs to be updated. I’m happy to consider / review any generic updates that are not specific to your environment for possible inclusion into the code base. Regards Jon From: Turner, Randy <Ran...@la...<mailto:Ran...@la...>> Sent: 14 February 2025 15:58 To: sup...@jp...<mailto:sup...@jp...> < sup...@jp...<mailto:sup...@jp...>>; lib...@li...<mailto:lib...@li...> Subject: RE: [libcoap-developers] coap-rd Thanks Jon, I guess we can build on the source code that coap-rd provides, to add the RFC 9176 feature set R. |
From: Jon S. <sup...@jp...> - 2025-02-17 10:28:39
|
Hi Randy, There should not need to be any changes in the libcoap library code, just that coap-rd.c needs to be updated. I'm happy to consider / review any generic updates that are not specific to your environment for possible inclusion into the code base. Regards Jon From: Turner, Randy <Ran...@la...> Sent: 14 February 2025 15:58 To: sup...@jp... < sup...@jp...>; lib...@li... Subject: RE: [libcoap-developers] coap-rd Thanks Jon, I guess we can build on the source code that coap-rd provides, to add the RFC 9176 feature set R. |
From: Rocco S. <ro...@fa...> - 2025-02-14 16:44:24
|
-- Regards, Rocco Scavetta FaultRed, LLC www.faultred.com /Detecting, Locating, and Managing Faults on Electric Utility Systems/ ********************************************************************************************************************** IMPORTANT NOTICE: The information in this email (and any attachments hereto) is confidential. If you are not the intended recipient, you must not use or disseminate the information. If you have received this email in error, please immediately notify me by the "Reply" command and permanently delete the original and any copies or printouts thereof. Although this email and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by FaultRed, LLC or its subsidiaries or affiliates either jointly or severally, for any loss or damage arising in any way from its use. |
From: Turner, R. <Ran...@la...> - 2025-02-14 15:58:04
|
Thanks Jon, I guess we can build on the source code that coap-rd provides, to add the RFC 9176 feature set R. From: sup...@jp... <sup...@jp...> Sent: Friday, February 14, 2025 10:04 AM To: Turner, Randy <Ran...@la...>; lib...@li... Subject: RE: [libcoap-developers] coap-rd Hi Randy, Coap-rd only implements an early draft of RFC 9176 (draft-ietf-core-resource-directory) and is missing a lot of the functionality outlined in RFC 9176. As such it is a test / example of what can be done. Regards Jon From: Turner, Randy ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Randy, Coap-rd only implements an early draft of RFC 9176 (draft-ietf-core-resource-directory) and is missing a lot of the functionality outlined in RFC 9176. As such it is a test / example of what can be done. Regards Jon From: Turner, Randy via libcoap-developers < lib...@li...<mailto:lib...@li...>> Sent: 14 February 2025 14:38 To: lib...@li...<mailto:lib...@li...> Subject: [libcoap-developers] coap-rd Hi All, Is the coap-rd application that is built by a libcoap build sufficient to be used in a production environment? Or is it strictly a test or example RD implementation ? Thanks! Randy |
From: Jon S. <sup...@jp...> - 2025-02-14 15:04:07
|
Hi Randy, Coap-rd only implements an early draft of RFC 9176 (draft-ietf-core-resource-directory) and is missing a lot of the functionality outlined in RFC 9176. As such it is a test / example of what can be done. Regards Jon From: Turner, Randy via libcoap-developers < lib...@li...> Sent: 14 February 2025 14:38 To: lib...@li... Subject: [libcoap-developers] coap-rd Hi All, Is the coap-rd application that is built by a libcoap build sufficient to be used in a production environment? Or is it strictly a test or example RD implementation ? Thanks! Randy |
From: Turner, R. <Ran...@la...> - 2025-02-14 14:37:59
|
Hi All, Is the coap-rd application that is built by a libcoap build sufficient to be used in a production environment? Or is it strictly a test or example RD implementation ? Thanks! Randy |
From: Jon S. <sup...@jp...> - 2025-01-31 19:32:44
|
Hi Leonie, Fabian and Markus, It is good that you are trying to implement a DoC Client using libcoap. Some initial comments I would recommend using released version 4.3.5 or later as 4.3.4 is now over a year old and there have been some changes that may help you, or make it easier for us to add in additional functionality if needed. I do not recognize "Sending empty ACK: Response took too long to prepare" as a libcoap debug message. It looks like it is something you have added while troubleshooting, or it comes from a server that your client is attempting to talk to that is trying to talk to a backend DNS server. The client should send the request, should never follow the request with an empty ACK (other than an empty ACK if the response is sent using a CON message), so I am puzzled by what you are seeing here. coap_io_process() has a timeout parameter. With the delays that you are seeing when using a Github action, it is worth trying to increase the value here to see if that helps. I'm not sure that using coap_io_pending() will help you here, as it does not detect there is a CON request that has not yet had an ACK response. coap_can_exit() may work for you here (only is the requests are of type CON, not NON). In the develop branch (post 4.3.5) there is a new function coap_send_recv() which will give the caller a copy of the response PDU that has been received within the specified timeout. This may be what you need here. It would be good to know what server you are trying to use for the client to talk to. It is possible that the github Action is not able to communicate with this server. It would help to see debug logs of the CoAP traffic from/to the client help you troubleshoot further. However, it would be good to post the information by raising this question as an issue at https://github.com/obgm/libcoap/issues where log files etc. can easily be attached as well as providing more details about your environment. Regards Jon From: Leonie Seelisch <leo...@ma...> Sent: 31 January 2025 17:08 To: lib...@li... Cc: Markus Ziehe <mar...@ma...>; Fabian Krusch <fab...@ma...> Subject: [libcoap-developers] Question about coap_io_process Dear all, we are a group of students from Dresden University of Technology. In the context of a group project, we are using libcoap 4.3.4 to implement a DNS over CoAP (DoC) client. Currently, we are using libcoap as described in the following: We are doing the startup, register our response handler, create a PDU, add the needed data (the DNS packet) to the PDU, send it with coap_send, and then we wait for a response with coap_io_process. If we are running this on our local machine, everything works fine and the first call of coap_io_process calls our response handler with the expected response. But when we are running this as a GitHub action, there seems to be more latency and the first call to coap_io_process results in the debug output "Sending empty ACK: Response took too long to prepare". With that, the coap_io_process just sends an empty ACK to the server and returns without calling our response handler. If then calling coap_io_process a second time, the expected answer from the server is received and our response handler is called. In general, after calling coap_io_process, our program is supposed to terminate if our response handler was called, i.e. if we already got a response, or to wait for the response, i.e. call coap_io_process a second time, if there was no response yet. Our problem is, when coap_io_process returns, we can't distinguish between these 2 cases (no response & sending ack, response & calling handler). So we can't distinguish if our program can terminate or if we still wait for a response, i.e. need to call coap_io_process a second time. The current solution is a global variable that is set to true when our response handler is called and every time the coap_io_process returns, the variable is checked and if it is true, the program can terminate and if it is still false, coap_io_process is called again. While this is a temporary working solution, we want to ask if there is a more convenient way to check if just an empty ACK was sent during coap_io_process or if we received a response. We couldn't really find any functions that we can call e.g. on our coap_pdu_t or on our coap_session_t that could tell us, if there was an answer or if an empty ACK was sent or something like that. Maybe you can tell us, if libcoap is supposed to be used differently than we do or if there is a function for that which we just didn't find. We hope, you can help us with that. Kind regards, Fabian Krusch, Leonie Seelisch, Markus Ziehe Dresden University of Technology |
From: Leonie S. <leo...@ma...> - 2025-01-31 17:27:22
|
Dear all, we are a group of students from Dresden University of Technology. In the context of a group project, we are using libcoap 4.3.4 to implement a DNS over CoAP (DoC) client. Currently, we are using libcoap as described in the following: We are doing the startup, register our response handler, create a PDU, add the needed data (the DNS packet) to the PDU, send it with coap_send, and then we wait for a response with coap_io_process. If we are running this on our local machine, everything works fine and the first call of coap_io_process calls our response handler with the expected response. But when we are running this as a GitHub action, there seems to be more latency and the first call to coap_io_process results in the debug output "Sending empty ACK: Response took too long to prepare". With that, the coap_io_process just sends an empty ACK to the server and returns without calling our response handler. If then calling coap_io_process a second time, the expected answer from the server is received and our response handler is called. In general, after calling coap_io_process, our program is supposed to terminate if our response handler was called, i.e. if we already got a response, or to wait for the response, i.e. call coap_io_process a second time, if there was no response yet. Our problem is, when coap_io_process returns, we can't distinguish between these 2 cases (no response & sending ack, response & calling handler). So we can't distinguish if our program can terminate or if we still wait for a response, i.e. need to call coap_io_process a second time. The current solution is a global variable that is set to true when our response handler is called and every time the coap_io_process returns, the variable is checked and if it is true, the program can terminate and if it is still false, coap_io_process is called again. While this is a temporary working solution, we want to ask if there is a more convenient way to check if just an empty ACK was sent during coap_io_process or if we received a response. We couldn't really find any functions that we can call e.g. on our coap_pdu_t or on our coap_session_t that could tell us, if there was an answer or if an empty ACK was sent or something like that. Maybe you can tell us, if libcoap is supposed to be used differently than we do or if there is a function for that which we just didn't find. We hope, you can help us with that. Kind regards, Fabian Krusch, Leonie Seelisch, Markus Ziehe Dresden University of Technology |
From: Turner, R. <Ran...@la...> - 2025-01-31 13:38:46
|
Ok thanks again Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: sup...@jp... <sup...@jp...> on behalf of Jon Shallow <sup...@jp...> Sent: Friday, January 31, 2025 5:40:32 AM To: Turner, Randy <Ran...@la...>; lib...@li... <lib...@li...> Subject: RE: [libcoap-developers] SNI callback for COAPS server Hi Randy, Yes, whatever is pointed to by the char* pointer needs to be around for the lifetime of the coap context. As a note, if the pointer points to a file name, every new(D)TLS session that is started will read the contents of that file. ZjQcmQRYFpfptBannerStart Report Phishing Email looks strange? → let Landis+Gyr’s Security Team check it for you ZjQcmQRYFpfptBannerEnd Hi Randy, Yes, whatever is pointed to by the char* pointer needs to be around for the lifetime of the coap context. As a note, if the pointer points to a file name, every new(D)TLS session that is started will read the contents of that file. So, if the contents of the file are updated (e.g. certificate updated), the new (D)TLS session will use the new file credentials with no other refresh of the server or client needed. Regards Jon From: Turner, Randy <Ran...@la...> Sent: 30 January 2025 22:49 To: sup...@jp...<mailto:sup...@jp...>; lib...@li... Subject: RE: [libcoap-developers] SNI callback for COAPS server Hi Jon, Thanks for the clarification….so anything pointed to by the char* pointers in the structure should be have a lifetime at least as long as the life of the coap context for which the DTLS_PKI structure is used… Randy |
From: Jon S. <sup...@jp...> - 2025-01-31 10:40:40
|
Hi Randy, Yes, whatever is pointed to by the char* pointer needs to be around for the lifetime of the coap context. As a note, if the pointer points to a file name, every new(D)TLS session that is started will read the contents of that file. So, if the contents of the file are updated (e.g. certificate updated), the new (D)TLS session will use the new file credentials with no other refresh of the server or client needed. Regards Jon From: Turner, Randy <Ran...@la...> Sent: 30 January 2025 22:49 To: sup...@jp... <mailto:sup...@jp...> ; lib...@li... Subject: RE: [libcoap-developers] SNI callback for COAPS server Hi Jon, Thanks for the clarification..so anything pointed to by the char* pointers in the structure should be have a lifetime at least as long as the life of the coap context for which the DTLS_PKI structure is used. Randy |
From: Turner, R. <Ran...@la...> - 2025-01-30 22:49:19
|
Hi Jon, Thanks for the clarification….so anything pointed to by the char* pointers in the structure should be have a lifetime at least as long as the life of the coap context for which the DTLS_PKI structure is used… Randy From: sup...@jp... <sup...@jp...> Sent: Wednesday, January 15, 2025 5:29 AM To: lib...@li...; Turner, Randy <Ran...@la...> Subject: RE: [libcoap-developers] SNI callback for COAPS server Hi Randy, I have realized that the key information structure returned by the SNI callback will contain a list of pointers (for example for certificate files - see coap_pki_key_pem_t for an example). Any information pointed to will not ZjQcmQRYFpfptBannerStart Report Phishing Email looks strange? → let Landis+Gyr’s Security Team check it for you ZjQcmQRYFpfptBannerEnd Hi Randy, I have realized that the key information structure returned by the SNI callback will contain a list of pointers (for example for certificate files - see coap_pki_key_pem_t for an example). Any information pointed to will not get saved into the SNI cache held by libcoap, only the pointers are cached. Regards Jon From: Jon Shallow <sup...@jp...<mailto:sup...@jp...>> Sent: 14 January 2025 19:44 To: 'Turner, Randy' <Ran...@la...<mailto:Ran...@la...>>; lib...@li...<mailto:lib...@li...> Subject: Re: [libcoap-developers] SNI callback for COAPS server Hi Randy, Whatever is passed back by the sni_callback handler is then used for the appropriate PSK/PKI (D)TLS session set up in libcoap, which then (for some of the TLS libraries) caches the information for when a new session starts up and is using the same SNI. In general, I think the provided key information is copied into the SNI cache, but it would need testing to be certain a TLS library does nothing strange when it stores information. If NULL is returned, then the presented SNI is treated as invalid and so the (D)TLS session set up will fail (there is no notion in libcoap of a default provided set of keys - that has to be provided by the application). Regards Jon From: Turner, Randy via libcoap-developers < lib...@li...<mailto:lib...@li...>> Sent: 14 January 2025 17:46 To: lib...@li...<mailto:lib...@li...> Subject: [libcoap-developers] SNI callback for COAPS server Hi Guys, hope everyone had a good holiday I was reviewing the SNI callback for libcoap DTLS servers and there is sample code in the 4.3.5 doc set… /* * Subject Name Identifier (SNI) callback verifier */ static coap_dtls_key_t * verify_pki_sni_callback(const char *sni, void *arg) { valid_snis_t *valid_sni_list = (valid_snis_t *)arg; size_t i; /* Check that the SNI is valid */ for (i = 0; i < valid_sni_list->count; i++) { if (!strcasecmp(sni, valid_sni_list->sni_list[i].sni)) { return &valid_sni_list->sni_list[i].key; } } return NULL; } Is there an expectation from the library that the “key” structure returned by this callback will allocated in “static” storage? Or, does it use the returned pointer and copy the information from this storage into the associated libcoap ctx? Also, I noticed in the sample, that NULL can be returned from the SNI callback….what does library do when a NULL is returned? Thanks All! Happy New Year! Randy |
From: Olaf B. <ber...@tz...> - 2025-01-29 12:12:18
|
On 2025-01-29, Olaf Bergmann <ber...@tz...> wrote: > Due to a power outage, libcoap.net is currently down. Back again. Grüße Olaf |
From: Olaf B. <ber...@tz...> - 2025-01-29 11:32:35
|
Hi all, Due to a power outage, libcoap.net is currently down. Grüße Olaf |
From: Jon S. <sup...@jp...> - 2025-01-15 10:28:57
|
Hi Randy, I have realized that the key information structure returned by the SNI callback will contain a list of pointers (for example for certificate files - see coap_pki_key_pem_t for an example). Any information pointed to will not get saved into the SNI cache held by libcoap, only the pointers are cached. Regards Jon From: Jon Shallow <sup...@jp...> Sent: 14 January 2025 19:44 To: 'Turner, Randy' <Ran...@la...>; lib...@li... Subject: Re: [libcoap-developers] SNI callback for COAPS server Hi Randy, Whatever is passed back by the sni_callback handler is then used for the appropriate PSK/PKI (D)TLS session set up in libcoap, which then (for some of the TLS libraries) caches the information for when a new session starts up and is using the same SNI. In general, I think the provided key information is copied into the SNI cache, but it would need testing to be certain a TLS library does nothing strange when it stores information. If NULL is returned, then the presented SNI is treated as invalid and so the (D)TLS session set up will fail (there is no notion in libcoap of a default provided set of keys - that has to be provided by the application). Regards Jon From: Turner, Randy via libcoap-developers < lib...@li... <mailto:lib...@li...> > Sent: 14 January 2025 17:46 To: lib...@li... <mailto:lib...@li...> Subject: [libcoap-developers] SNI callback for COAPS server Hi Guys, hope everyone had a good holiday I was reviewing the SNI callback for libcoap DTLS servers and there is sample code in the 4.3.5 doc set. /* * Subject Name Identifier (SNI) callback verifier */ static coap_dtls_key_t * verify_pki_sni_callback(const char *sni, void *arg) { valid_snis_t *valid_sni_list = (valid_snis_t *)arg; size_t i; /* Check that the SNI is valid */ for (i = 0; i < valid_sni_list->count; i++) { if (!strcasecmp(sni, valid_sni_list->sni_list[i].sni)) { return &valid_sni_list->sni_list[i].key; } } return NULL; } Is there an expectation from the library that the "key" structure returned by this callback will allocated in "static" storage? Or, does it use the returned pointer and copy the information from this storage into the associated libcoap ctx? Also, I noticed in the sample, that NULL can be returned from the SNI callback..what does library do when a NULL is returned? Thanks All! Happy New Year! Randy |
From: Jon S. <sup...@jp...> - 2025-01-14 20:12:46
|
Hi Randy, Whatever is passed back by the sni_callback handler is then used for the appropriate PSK/PKI (D)TLS session set up in libcoap, which then (for some of the TLS libraries) caches the information for when a new session starts up and is using the same SNI. In general, I think the provided key information is copied into the SNI cache, but it would need testing to be certain a TLS library does nothing strange when it stores information. If NULL is returned, then the presented SNI is treated as invalid and so the (D)TLS session set up will fail (there is no notion in libcoap of a default provided set of keys - that has to be provided by the application). Regards Jon From: Turner, Randy via libcoap-developers < lib...@li...> Sent: 14 January 2025 17:46 To: lib...@li... Subject: [libcoap-developers] SNI callback for COAPS server Hi Guys, hope everyone had a good holiday I was reviewing the SNI callback for libcoap DTLS servers and there is sample code in the 4.3.5 doc set. /* * Subject Name Identifier (SNI) callback verifier */ static coap_dtls_key_t * verify_pki_sni_callback(const char *sni, void *arg) { valid_snis_t *valid_sni_list = (valid_snis_t *)arg; size_t i; /* Check that the SNI is valid */ for (i = 0; i < valid_sni_list->count; i++) { if (!strcasecmp(sni, valid_sni_list->sni_list[i].sni)) { return &valid_sni_list->sni_list[i].key; } } return NULL; } Is there an expectation from the library that the "key" structure returned by this callback will allocated in "static" storage? Or, does it use the returned pointer and copy the information from this storage into the associated libcoap ctx? Also, I noticed in the sample, that NULL can be returned from the SNI callback..what does library do when a NULL is returned? Thanks All! Happy New Year! Randy |
From: Turner, R. <Ran...@la...> - 2025-01-14 18:25:57
|
Hi Guys, hope everyone had a good holiday I was reviewing the SNI callback for libcoap DTLS servers and there is sample code in the 4.3.5 doc set... /* * Subject Name Identifier (SNI) callback verifier */ static coap_dtls_key_t * verify_pki_sni_callback(const char *sni, void *arg) { valid_snis_t *valid_sni_list = (valid_snis_t *)arg; size_t i; /* Check that the SNI is valid */ for (i = 0; i < valid_sni_list->count; i++) { if (!strcasecmp(sni, valid_sni_list->sni_list[i].sni)) { return &valid_sni_list->sni_list[i].key; } } return NULL; } Is there an expectation from the library that the "key" structure returned by this callback will allocated in "static" storage? Or, does it use the returned pointer and copy the information from this storage into the associated libcoap ctx? Also, I noticed in the sample, that NULL can be returned from the SNI callback....what does library do when a NULL is returned? Thanks All! Happy New Year! Randy |
From: Jon S. <sup...@jp...> - 2024-11-19 13:31:19
|
Hi Randy, Connection Identifier (RFC 9146 for DTLS 1.2, RFC9147 for DTLS 1.3) support allows for session resumption. This is available for libcoap 4.3.5 clients. For MbedTLS clients and servers, MBEDTLS_SSL_DTLS_CONNECTION_ID needs to be enabled in the MbedTLS library for DTLS1.2. For TinyDTLS clients, there is a patch available to provide support for DTLS1.2. For WolfSSL clients and servers, the wolfSSL library needs to be built with $ ./configure --enable-dtls13 --enable-dtlscid CFLAGS="-DDTLS_CID_MAX_SIZE=8" which provides support for DTLS1.3 (not DTLS1.2). While in general the underlying (D)TLS libraries support RFC5077, libcoap does not (currently) have a mechanism for storing negotiated Session Tickets. Regards Jon From: Turner, Randy via libcoap-developers <lib...@li...> Sent: 18 November 2024 20:30 To: lib...@li... Subject: [libcoap-developers] DTLS 1.2 session resumption Hi All, If we have a libcoap 4.3.4 or 4.3.5 client, using DTLS to communicate with a remote DTLS server, can this client take advantage of DTLS "Session Resumption" some how ? Thanks! Randy |
From: Turner, R. <Ran...@la...> - 2024-11-18 21:10:02
|
Hi All, If we have a libcoap 4.3.4 or 4.3.5 client, using DTLS to communicate with a remote DTLS server, can this client take advantage of DTLS "Session Resumption" some how ? Thanks! Randy |