A CoAP (RFC 7252) implementation in C

Related tags

Utilities libcoap
Overview

libcoap: A C implementation of the Constrained Application Protocol (RFC 7252)

Build Status: master Build Status: develop Static Analysis Fuzzing Status CMake

Copyright (C) 2010—2021 by Olaf Bergmann [email protected] and others

ABOUT LIBCOAP

libcoap is a C implementation of a lightweight application-protocol for devices that are constrained their resources such as computing power, RF range, memory, bandwidth, or network packet sizes. This protocol, CoAP, is standardized by the IETF as RFC 7252. For further information related to CoAP, see http://coap.technology.

You might want to check out libcoap-minimal for usage examples.

DOCUMENTATION

Documentation and further information can be found at https://libcoap.net.

PACKAGE CONTENTS

This package contains a protocol parser and basic networking functions for platforms with support for malloc() and BSD-style sockets. In addition, there is support for Contiki, LwIP and Espressif/ESP-IDF hosted environments.

The following RFCs are supported

  • RFC7252: The Constrained Application Protocol (CoAP)

  • RFC7641: Observing Resources in the Constrained Application Protocol (CoAP)

  • RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP)

  • RFC7967: Constrained Application Protocol (CoAP) Option for No Server Response

  • RFC8132: PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)

  • RFC8323: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets [No WebSockets support]

  • RFC8768: Constrained Application Protocol (CoAP) Hop-Limit Option

There is (D)TLS support for the following libraries

  • OpenSSL (Minimum version 1.1.0) [PKI, PSK and PKCS11]

  • GnuTLS (Minimum version 3.3.0) [PKI, PSK, RPK(3.6.6+) and PKCS11]

  • Mbed TLS (Minimum version 2.7.10) [PKI and PSK] [Currently only DTLS]

  • TinyDTLS [PSK and RPK] [DTLS Only]

The examples directory contain a CoAP client, CoAP Resource Directory server and a CoAP server to demonstrate the use of this library.

BUILDING

Further information can be found at https://libcoap.net/install.html and BUILDING.

LICENSE INFORMATION

This library is published as open-source software without any warranty of any kind. Use is permitted under the terms of the simplified BSD license. It includes public domain software. libcoap binaries may also include open-source software with their respective licensing terms. Please refer to LICENSE for further details.

Issues
  • Async GET for Observe resource causes core dump

    Async GET for Observe resource causes core dump

    Hi All,

    I modified the example client and server "Hello World" example to make the async GET resource"Observable". The initial GET works fine but then having set the resource as dirty and called coap_check_notify() it core dumps. It looks like the reason is that handler receives a NULL request pointer and the call to coap_register_async calls coap_transaction_id which ultimately derefences the NULL pointer.

    I have tried checking for NULL request and artificially creating a request PDU to send to the coap_register_async call. This prevents the core dump but the client then rejects it (I assume because the id is unknown to it). On the server I get the following message "ALRT got RST for message X" and no errors on the client. I have tried the following and none work

    1. storing the ID of the original request (i.e. request->hdr->id) and setting the ID of temp request PDU
    2. setting the ID of the temp request PDU to 0
    3. creating a new ID of for the temp request PDU Using this technique, the client receives the initial response then 12 updates and nothing else received.

    The async handler is (sorry not sure why the code won't render correctly)

    `static void async_handler(coap_context_t *ctx, struct coap_resource_t *resource, const coap_endpoint_t *local_interface, coap_address_t *peer, coap_pdu_t *request, str *token, coap_pdu_t *response) { if (request == NULL) { ESP_LOGI(TAG, "Request is NULL so creating one ID[%d]", nRequestID);

    	request = coap_new_pdu();
    	if (request)
    	{
    		uint8_t     get_method = 1;
    		request->hdr->type = COAP_MESSAGE_CON;
    		request->hdr->id   = nRequestID; //coap_new_message_id(ctx);
    		request->hdr->code = get_method;
    		unsigned char buf[3]; 
    		coap_add_option(request, COAP_OPTION_OBSERVE, coap_encode_var_bytes(buf, COAP_OBSERVE_ESTABLISH), buf); 
    
    		//coap_add_option(request, COAP_OPTION_URI_PATH, uri.path.length, uri.path.s);
    	}
    	else
    		return;
    }
    else
    	nRequestID = request->hdr->id;
    
    
    async = coap_register_async(ctx, peer, request, COAP_ASYNC_SEPARATE | COAP_ASYNC_CONFIRM, (void*)"no data");
    

    } `

    Is this a bug or am I doing something wrong?

    thanks

    Lee.

    question esp32 
    opened by leenowell 171
  • PKI: Make (D)TLS operation consistent across all TLS libraries

    PKI: Make (D)TLS operation consistent across all TLS libraries

    The use of the verify_peer_cert and require_peer_cert variables in the coap_dtls_pki_t structure was giving inconsistent results across all the TLS libraries. This primarily was down to the large numbers of options available to control the TLS handshakes in OpenSSL compared to the limited control available to mbedTLS port which followed later. require_peer_cert is not easy to control in mbedTLS as it is an implicit configuration based on how other, not always related, items were configured.

    require_peer_cert was used by the server to control whether the client could use anonymous certificates or not. This is now controlled by verify_peer_cert.

    require_peer_cert variable has been replaced with check_common_ca, so that the OpenSSL functionality can continue, but enable GnuTLS / mbedTLS to produce the same results. This allows peers to mutually authenticate (because the peer certs are signed by the same common CA) or not which was in effect controlled by verify_peer_cert previously.

    If check_common_ca is set, then allow_self_signed is ignored.

    If is_rpk_not_cert is set, then all certificate validation is ignored.

    In the examples, use of the -R option unsets check_common_ca, so disables mutual authentication support by having a common CA. This was needed as mbedTLS and GnuTLS only have a single trust store for CAs.

    configure.ac:

    Increase the number of mbed libraries to use when checking for mbedTLS.

    examples/client.c: examples/coap-rd.c: examples/coap-server.c:

    Add in -n (unset verify_peer_cert) option. In the case of coap-server and coap-rd, make -n refer to verify_peer_cert. Add in TLS library capabilites in usage().

    Update usage() documentation as appropriate, with some changes to fit everything into a 80 column output.

    include/coap2/coap_dtls.h: include/coap2/net.h:

    Update with variable changes, and make the coap_dtls_pki_t parameter const for the *_context_set_pki() functions.

    man/coap-client.txt.in: man/coap-rd.txt.in: man/coap-server.txt.in:

    Update documentation to reflect the examples option usage.

    man/coap_context.txt.in: man/coap_encryption.txt.in: man/coap_session.txt.in:

    Update with the new variable name and document as appropriate.

    src/coap_gnutls.c src/coap_mbedtls.c src/coap_notls.c src/coap_openssl.c coap_tinydtls.c

    Update to make variable usage consistent. Update logging from LOG_WARNING to LOG_INFO where there is an override of a PKI check failure by one of the coap_dtls_pki_t variables.

    Timing window closed for TLS where the peer does not like a certificate, sends fatal alert and closes connection. local then fails on writing the next handshake - but now also reads in alert and reports on it.

    src/coap_io.c:

    Update logging from LOG_WARNING to LOG_INFO for EPIPE or ECONNRESET errors in coap_socket_write().

    src/net.c:

    Handle the const coap_dtls_pki_t parameter in coap_context_set_pki() function.

    This replaces #557

    security 
    opened by mrdeep1 109
  • add cmake support to libcoap

    add cmake support to libcoap

    this MR adds cmake support for libcoap.

    • this allows to get rid of the msbuild project files as well as the windows header files. visual studio now supports cmake out of the box.
    • adopting cmake makes easier to integrate in cmake projects as well as packaging for conan and vcpkg
    • easier to integrate with Android NDK
    opened by gocarlos 51
  • test uri 18 fails on windows

    test uri 18 fails on windows

    When running testdriver on windows with a debug build, t_parse_uri18 fails. This is because coap_new_string() does not initialize the buffer it allocates. I think it should set the first byte to zero, so that if the string is not filled / zero-length like in this test case, it still is consistent. If that's ok I will submit a pull request.

    opened by jcmichelou 43
  • Add in MbedTLS support

    Add in MbedTLS support

    Add in MbedTLS support as an alternative (D)TLS encryption. Currently TLS is not supported.

    Patch 1

    Add in MbedTLS support

    Add in MbedTLS library support as another alternative TLS library

    Makefile.am:

    Include new src/coap_mbedtls.c file.

    configure.ac:

    Add in --with-mbedtls support which generates HAVE_MBEDTLS in coap_config.h.

    include/coap2/coap_dtls.h:

    Add in TLS Library type COAP_TLS_LIBRARY_MBEDTLS and make COAP_TLS_LIBRARY_* defines an enum. Add in PKI Key type COAP_PKI_KEY_PEM_BUF for passing in PEM information that is held in memory instead of in a file.

    src/coap_debug.c:

    Output MbedTLS information if appropriate.

    src/coap_mbedtls.c: (New)

    Contains the MbedTLS interface code.

    src/coap_notls.c:

    Do not use code if MbedTLS is being built.

    src/coap_session.c:

    Fix socket closure order in coap_free_endpoint() so the closure message correctly gets out.

    tests/test_tls.c:

    Include MbedTLS library checks.

    Patch 2

    Add support for COAP_PKI_KEY_PEM_BUF in coap_opensl.c and coap_gnutls.c

    Existing COAP_PKI_KEY_PEM key type reads the PEM file from disk. COAP_PKI_KEY_PEM_BUF key type has the same PEM content format, but provided in a memory buffer.

    src/coap_gnutls.c:

    Add in support for COAP_PKI_KEY_PEM_BUF

    src/coap_openssl.c:

    Add in support for COAP_PKI_KEY_PEM_BUF

    Patch 3

    Add in MbedTLS support documentation

    man/coap_attribute.txt.in: man/coap_context.txt.in: man/coap_encryption.txt.in: man/coap_handler.txt.in: man/coap_logging.txt.in: man/coap_observe.txt.in: man/coap_pdu_setup.txt.in: man/coap_recovery.txt.in: man/coap_resource.txt.in: man/coap_session.txt.in: man/coap_tls_library.txt.in:

    Add in reference to MbedTLS where appropriate.

    man/coap_encryption.txt.in:

    Add in PKI Key type COAP_PKI_KEY_PEM_BUF for passing in PEM information that is held in memory instead of in a file.

    opened by mrdeep1 34
  • Add in internal epoll support to expose a monitor-able file descriptor

    Add in internal epoll support to expose a monitor-able file descriptor

    If epoll is available, use it within libcoap to speed things up, as well as present to applications a file descriptor that can be used in a select() or returned as an event in a epoll_wait() call.

    Whenever coap_new_context() is called. set up a new epoll infrastructure with epoll_create() and destroy it with coap_free_context().

    For each new endpoint or session, add the socket fd to epoll. When the socket is closed, remove the socket fd from epoll.

    Whenever a socket wants a write, the appropriate epoll event gets EPOLLOUT added and when the write happens reset the event back to just EPOLLIN.

    As there may be a packet retry event sometime in the future, a timerfd is created and added to the epoll structure (done in coap_new_context) which gets freed off in coap_free_context. If coap_run_once() determines that there is a future retry, timerfd is informed of when the event is to occur. When timerfd times out, the application file descriptor will indicate a read is available.

    A new function coap_context_get_coap_fd(ctx) returns the application file descriptor. The only other API change is that if wait_ms is set to 1 for coap_run_once(ctx, wait_ms), there is no waiting for a new packet to arrive.

    coap_run_once() is called, whether epoll support is available or not, to process all the underlying required i/o.

    If there is no epoll support, coap_run_once() continues to use the old select() method, otherwise it will use epoll_wait(). If there is epoll support, a modified version of coap_read() (coap_io_do_events()) is used instead.

    Makefile.am:

    Do not expose coap_epoll_ctl_mod() and coap_io_do_events() to applications.

    configure.ac:

    Test for the presence of sys/epoll.h and sys/timerfd.h and if so setup COAP_EPOLL_SUPPORT to be used for #ifdef testing. Include new man page coap_io.txt.

    examples/coap-server.c:

    Include support for using this new exposed file descriptor.

    include/coap2/coap_io.h:

    Define COAP_MAX_EPOLL_EVENTS (to limit the number of events processed at once) and include coap_endpoint_t and coap_session_t in coap_socket_t. Include (internal) definition for coap_epoll_ctl_mod()

    include/coap2/net.h:

    Add epfd and eptimerfd to coap_context_t. Define coap_context_get_coap_fd() for applications to use. Include (internal) definition for coap_io_do_events().

    libcoap-2.map: libcoap-2.sym:

    Include coap_context_get_coap_fd.

    configure.ac: man/Makefile.am: man/coap.txt.in: man/coap_io.txt.in: (New)

    Include the new coap_in(3) man page that documents coap_run_once() and coap_context_get_coap_fd().

    src/coap_io.c: src/coap_openssl.c: src/coap_session.c: src/net.c:

    Add in the epoll support.

    src/net.c:

    Add in coap_context_get_coap_fd() function.

    opened by mrdeep1 30
  • coap-client always uses same transaction id

    coap-client always uses same transaction id

    When I try to send a CoAP message via coap-client it uses the same transaction id (tid) for every call. This leads to every n+1 messages being ignored by the server.

    bash-4.4# echo '{"some": "json"}' | coap-client -m put -b 1024 -v 9 coap://1.2.3.4:5683/2/1
    Jul 03 07:23:43 DEBG ***10.42.91.73:56136 <-> 1.2.3.4:5683 UDP : new outgoing session
    Jul 03 07:23:43 DEBG sending CoAP request:
    Jul 03 07:23:43 DEBG *  10.42.91.73:56136 <-> 1.2.3.4:5683 UDP : sent 14 bytes
    v:1 t:CON c:PUT i:b927 {} [ Uri-Port:4096, Uri-Path:2, Uri-Path:1, Block1:0/_/1024 ]
    Jul 03 07:23:43 DEBG ** 10.42.91.73:56136 <-> 1.2.3.4:5683 UDP : tid=47399 added to retransmit queue (2656ms)
    Jul 03 07:23:43 DEBG timeout is set to 90 seconds
    Jul 03 07:23:46 DEBG ** 10.42.91.73:56136 <-> 1.2.3.4:5683 UDP : tid=47399: retransmission #1
    Jul 03 07:23:46 DEBG *  10.42.91.73:56136 <-> 1.2.3.4:5683 UDP : sent 14 bytes
    v:1 t:CON c:PUT i:b927 {} [ Uri-Port:4096, Uri-Path:2, Uri-Path:1, Block1:0/_/1024 ]
    ^CJul 03 07:23:50 DEBG ***10.42.91.73:56136 <-> 1.2.3.4:5683 UDP : session closed
    
    
    bash-4.4# echo '{"some":{"other_json"}' | coap-client -m put -b 1024 -v 7 coap://1.2.3.4:5683/2/1
    Jul 03 07:46:02 DEBG ***10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : new outgoing session
    Jul 03 07:46:02 DEBG *  10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : sent 14 bytes
    v:1 t:CON c:PUT i:b927 {} [ Uri-Port:4096, Uri-Path:2, Uri-Path:1, Block1:0/_/1024 ]
    Jul 03 07:46:02 DEBG ** 10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : tid=47399 added to retransmit queue (2656ms)
    Jul 03 07:46:02 DEBG timeout is set to 90 seconds
    Jul 03 07:46:05 DEBG ** 10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : tid=47399: retransmission #1
    Jul 03 07:46:05 DEBG *  10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : sent 14 bytes
    v:1 t:CON c:PUT i:b927 {} [ Uri-Port:4096, Uri-Path:2, Uri-Path:1, Block1:0/_/1024 ]
    Jul 03 07:46:11 DEBG ** 10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : tid=47399: retransmission #2
    Jul 03 07:46:11 DEBG *  10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : sent 14 bytes
    v:1 t:CON c:PUT i:b927 {} [ Uri-Port:4096, Uri-Path:2, Uri-Path:1, Block1:0/_/1024 ]
    Jul 03 07:46:22 DEBG ** 10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : tid=47399: retransmission #3
    Jul 03 07:46:22 DEBG *  10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : sent 14 bytes
    v:1 t:CON c:PUT i:b927 {} [ Uri-Port:4096, Uri-Path:2, Uri-Path:1, Block1:0/_/1024 ]
    Jul 03 07:46:44 DEBG ** 10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : tid=47399: retransmission #4
    Jul 03 07:46:44 DEBG *  10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : sent 14 bytes
    v:1 t:CON c:PUT i:b927 {} [ Uri-Port:4096, Uri-Path:2, Uri-Path:1, Block1:0/_/1024 ]
    Jul 03 07:47:27 DEBG ** 10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : tid=47399: give up after 4 attempts
    Jul 03 07:47:32 INFO timeout
    Jul 03 07:47:32 DEBG ***10.42.91.73:52526 <-> 1.2.3.4:5683 UDP : session closed
    

    As you can see in this example it's using the same tid 47399 (0xb927) for two subsequent calls. If I understood well this should not happen. Any ideas on that?

    Context:

    • Using alpine linux 3.9.4
    • coap-client v4.2.0
    • TLS Library: OpenSSL - runtime 1.1.1b, libcoap built for 1.1.1b
    opened by BlueBeN82 29
  • Need code to check notify observers of unknown_resource and using uri_path instead of uri_query in observer'subscription

    Need code to check notify observers of unknown_resource and using uri_path instead of uri_query in observer'subscription

    Hi All

    1. Is there any problem if adding code to notify observers of unknown resource? I 'm thinking of something like this

    resource.c/ coap_check_notify() `void coap_check_notify(coap_context_t *context) {

    RESOURCES_ITER(context->resources, r) { coap_notify_observers(context, r); }

    // notify observers of unknown_resources if (context->unknown_resource) { coap_notify_observers(context, r); }

    }`

    or if that is inconvenient, an exposing for function "coap_notify_observers" (adding to function declaration into resource.h) so that it can be visible to higher application, is also enough.

    1. net.c / handle_request() https://github.com/obgm/libcoap/blob/develop/src/net.c#L1868 Is it reasonable if modifying it like this ? I need this because my client uses uri-path instead of query.

    if (h) { str *query = coap_get_query(pdu);

    // use uri-path in case query is null if (!query) { query = coap_get_uri_path(pdu); } ... }

    Thanks Hong

    opened by hongnguyen-tma 28
  • Add in man page support for the different exposed functions with examples

    Add in man page support for the different exposed functions with examples

    ./configure now supports --enable-manpages (on by default) where man pages are built and installed as appropriate.

    'man coap' provides an overview

    coap_attribute, coap_context, coap_handler, coap_recovery, coap_resource and coap_tls_library are in this update

    Potentially, coap_logging, coap_session and coap_io have still to be written, and possibly others.

    opened by mrdeep1 26
  • TCP Transport without Block Request

    TCP Transport without Block Request

    Hello,

    I am using libcoap 4.3.0 and I want to use CoAP TCP communication and saw that the messages are separated in blocks like in UDP transport. To enable TCP managed blocks, to increase the transport speed, I tried to set the MTU to UINT_MAX (coap_session_set_mtu(session, UINT_MAX);), which does work up to a 100000 bytes. With 120000 bytes, the transport fails and I could see a strange behaviour in wireshark. The CSM message is corrupted.

    Is that a memory allocation problem? Is that the correct way to disable block transport with TCP?

    With kind regards Chris grafik

    opened by ChrisCuts 23
  • incorrect source address of multicast response

    incorrect source address of multicast response

    When I send multicast message and I want to read address from who is the message, there is only broadcast address but no address of node who send response.

    I read address from session coap_address_t remote_addr.

    am I doing it right? or is there such an address somewhere else?

    opened by fero29 23
  • How to best log (D)TLS information

    How to best log (D)TLS information

    CoAP logging levels are determined by 2 functions - coap_set_log_level() and coap_dtls_set_log_level().

    The examples of coap-client and coap-server set the log level to the same value in both functions.

    The different TLS libraries are not consistent with how they handle coap_dtls_set_log_level() - some use COAP_LOG_CIPHERS(9) as a zero base for the different (internal to TLS) logging levels, others can log at higher (numerically less) levels than COAP_LOG_CIPHERSetc. Overall, the mechanisms here need to be consistent.

    Furthermore, the TLS libraries have different upper limits for the more verbose logging (i.e different ranges for logging levels).

    Should the logging level passed to coap_dtls_set_log_level() be the internal to TLS logging levels - i.e. start at 0 matching what the TLS library does when set to a logging level of 0 et.c. or should it be COAP_LOG_CIPHERS + TLS logging level?

    • starting at 0 will cause additional logging for old executables or unchanged application source using a later version of libcoap.
    • examples will need a different option to be able to define the TLS logging levels.

    Should coap_dtls_set_log_level() become a dummy function that is no longer used with everything keyed of the value of level passed into coap_set_log_level()?

    Should we be now calling COAP_LOG_CIPHERS COAP_LOG_TLS_BASEor COAP_LOG_TLS_L0for better code readability (but retain COAP_LOG_CIPHERSfor backwards source code compatibility)?

    In terms of coap_log(), should the level parameter be COAP_LOG_TLS_L0 + TLS_level, so that it is possible to determine from the logs what level a particular TLS log entry is for (e.g. TLS1or TLS7)?

    • Using ALRT, WARN, INFOetc. (with no bias added) do not map easily into the TLS library logging levels.
    • Users may still need to map TLS1 back to what logging level 1 means for that particular TLS library.

    Other thoughts?

    opened by mrdeep1 0
  • RFC: coap-server.c: Reload configuration on SIGUSR1

    RFC: coap-server.c: Reload configuration on SIGUSR1

    Long-running CoAP servers face the issue of certificate expiry (especially for the short-lived certificates from Let's Encrypt as the test server on libcoap.net). To update the configured certificate, a mechanism for controlled configuration reload is required. There are multiple options for this. As an example that should be portable at least on POSIX systems, I have used the USR1 signal as follows:

    A signal handler for SIGUSR1 is installed to flag configuration reload. In the main loop, fill_keystore() is called when this flag is set, normal processing continues.

    The handling of result < 0 after select is adjusted to continue processing after the configuration reload. To do so, the main loop is left only if result < 0 and quit is not zero.

    opened by obgm 2
  • Client and server behavior at the same time

    Client and server behavior at the same time

    Environment

    • libcoap version: v4.3.0
    • Build System: Platformio
    • Operating System: Windows
    • Operating System Version: 10
    • Hosted Environment: ESP-IDF

    Problem Description

    I need my system to have a coap server and a client working at the same time. I took code from both examples (from the ESP-IDF clientand server) without any sec layer.

    Basically I created 2 tasks where each example is running, so the libcoap lib is working on two different libcoap contexts. So I have 2 coap_io_process calls (on different pbjects of course). The client demo is sending a message each second, while the server is waiting for remote requests. Each server and client uses a different port.

    I am having an issue where everything goes ok, but after a random running time (in general after 5 or 10 minutes) the coap_io_process function starts returning EBUSY. I went deep into coap_io_process and it seems that EBUSY comes from lwip_select function and I think is related to some mutual exclusion mechanism, but I don't really understand why it is happening this.

    Not so sure if that is a bug or it's me doing things wrong.

    If you have some idea of what could be happening to me, or something that you want me to try, I will appreciate.

    opened by fbucafusco 15
  • Adding compiler options for enabling/disabling network layer

    Adding compiler options for enabling/disabling network layer

    Is your feature request related to a problem? Please describe.

    Coap is a transport layer protocol. It should be fully functional without assumptions of underlying security and network layer.

    Libcoap has options to compile without TLS libraries; however it always includes networking layer code, i.e. coap_io.c and address.c, etc.

    Describe the solution you'd like

    Libcoap will improve its reusability and modulization if there are compiler options which can enable/disable the network layer code.

    E.g. a project whose TLS and networking layer are handled by some other libraries, can integrate libcoap without including coap_io.c, address.c and the system networking libraries: socket, tcp, etc.

    opened by jqiaobln 1
  • Question: Two subscriptions to a single server showing some strange behavior

    Question: Two subscriptions to a single server showing some strange behavior

    Environment

    • libcoap version (run git describe --tags to find it): 4.3.0

    • Build System: [CMake]

    • Operating System: [Linux]

    • Operating System Version: [ ]

    • Hosted Environment: [None]

    Problem Description

    I am trying to observe 1 resources twice(just for test purpose). I am creating two diferent coap sessions for the two observe requests. Here I am using OSCORE messages, so these are just two CoAP messages for libcoap and internal observe mechanism of libcoap does not play a role here.

    How I do it:

    I send an observe message, keep the session alive to receive the incoming events from server till the observe lifetime. After lifetime expires, I kill the session, create another session with the same token and send another observe message, and this process repeats.

    I am facing the following problem:

    With a single observe request this works and I can see the new observe messages coming out cleanly from the Client application at an interval of lifetime value. I can also see the notification messages from server to client.

    When I do a second observe request, after a certain time, I see some retries/repeating messages from libcoap for the second observe request. These messages have invalid sequence number, which eventually result in "Unauthorised" responses.

    These messages can be seen in wireshark logs 2 and 3.

    My Question:

    What are these repeating messages and how can I stop them. Am I doing something wrong here ?

    I am using libcoap version 4.3.0.

    Expected Behavior

    // Describe what you are expecting.

    Actual Behavior

    // Describe what you are seeing.

    Steps to reproduce

    Debug Logs

    Wireshark [log](wireshark-1 wireshark-2 wireshark-3

    The two subscription logs are highlighted below from the main log:

    Subscription ONE

    Enter URI to subscribe(e.g. /p/rts/temproom): /p/rts/temproom
    
     Executing Sync Subscribe: /p/rts/temproomJan 03 15:11:20.929 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : new outgoing session
    Jan 03 15:11:20.929 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session max_retransmit set to 4
    Jan 03 15:11:20.929 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session ack_random_factor set to 1.500
    Jan 03 15:11:20.929 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session max_retransmit set to 4
    Jan 03 15:11:20.929 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session ack_timeout set to 20.000
    Jan 03 15:11:20.929 DEBG *  [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : sent 54 bytes
    v:1 t:CON c:POST i:4463 {b1cd3c04c579400c} [ 9:\x09\x00\x07\x09 ] :: binary data length 36
    <<11c631039f7737846c0af482f1d3e83130f253346e74948a33349a0f11be52a6f2bb4be6>>
    <<. . 1 . . w 7 . l . . . . . . 1 0 . S 4 n t . . 3 4 . . . . R . . . K . >>
    Jan 03 15:11:20.929 DEBG ** [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : mid=0x4463: added to retransmit queue (23438ms)
    Jan 03 15:11:20.931 DEBG *  [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : received 36 bytes
    v:1 t:ACK c:2.05 i:4463 {b1cd3c04c579400c} [ 9: ] :: ''\xB7\xB2\xF5"2=\xF9\x14\x1E\xE15\xF5S\xA8C\xA1\x90\xFEc\xD9l'
    Jan 03 15:11:20.931 DEBG ** [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : mid=0x4463: removed1
    
     SubscriptionsManager: Save Subscription Id : 1
    
     >> Notification status = Ok, ID = 1, max-age = 1, VAL = 28.7500 
    
    
     Subscription API status: Ok
     Subscription State: 0
     >> Subscription status = Ok, ID = 1, state = 0, TID = 0 
    
    

    Subscription TWO:

    Enter URI to subscribe(e.g. /p/rts/temproom): Jan 03 15:11:24.935 DEBG *  [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : received 41 bytes
    v:1 t:ACK c:2.05 i:f5c0 {b1cd3c04c579400c} [ 9:\x09\x04\x07\x09 ] :: binary data length 23
    <<e3f32a49fdd71adf09c02be5e08029af44a74841c35369>>
    <<. . * I . . . . . . + . . . ) . D . H A . S i >>
    
     >> Notification status = Ok, ID = 1, max-age = 1, VAL = 28.7500 
    
    /p/rts/temproomJan 03 15:11:25.936 DEBG *  [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : received 41 bytes
    v:1 t:ACK c:2.05 i:f5c2 {b1cd3c04c579400c} [ 9:\x09\x05\x07\x09 ] :: binary data length 23
    <<8e85f6635d4844f3aa5a1891c64736850c1f899671ff9f>>
    <<. . . c ] H D . . Z . . . G 6 . . . . . q . . >>
    
     >> Notification status = Ok, ID = 1, max-age = 1, VAL = 28.7500 
    
    
    
     Executing Sync Subscribe: /p/rts/temproomJan 03 15:11:26.139 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : new outgoing session
    Jan 03 15:11:26.139 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session max_retransmit set to 4
    Jan 03 15:11:26.139 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session ack_random_factor set to 1.500
    Jan 03 15:11:26.139 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session max_retransmit set to 4
    Jan 03 15:11:26.139 DEBG ***[fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : session ack_timeout set to 20.000
    Jan 03 15:11:26.139 DEBG *  [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : sent 54 bytes
    v:1 t:CON c:POST i:3e64 {f3695b086d327502} [ 9:\x09\x01\x07\x09 ] :: '!\x93M\xF7\xD6z8\xF0\xE4\\xB4\xAA\x11>\xF6\xD0\x87\xC2\xCB\xA5\xBA0e!f\xAD\x0D\xBF"_\x90\xCA\xEF\x0D\xB3}'
    Jan 03 15:11:26.139 DEBG ** [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : mid=0x3e64: added to retransmit queue (25625ms)
    Jan 03 15:11:26.140 DEBG *  [fe80::250:56ff:fe00:0]:14555 <-> [fe80::250:56ff:fe00:0]:5683 UDP : received 37 bytes
    v:1 t:ACK c:2.05 i:f5c3 {f3695b086d327502} [ 9: ] :: binary data length 23
    <<fbc15f5adc3eb6ab8e79078020c0eb5be470fd7b3a3fda>>
    <<. . _ Z . > . . . y . .   . . [ . p . { : ? . >>
    
     SubscriptionsManager: Save Subscription Id : 4
    
     >> Notification status = Ok, ID = 4, max-age = 1, VAL = 28.7500 
    
    
     Subscription API status: Ok
     Subscription State: 0
     >> Subscription status = Ok, ID = 4, state = 0, TID = 0 
    
    

    Other items if possible

    • [ ] Does what you are trying to do work under any configuration. Detail what works.
    • [ ] Network configuration that is not straightforward. Detail any networking that may have NAT or firewalls that might affect what is going on.
    opened by fun-works 25
  • Add TF-M support

    Add TF-M support

    Is your feature request related to a problem? Please describe.

    In IoT, PSA is the standard to ensure IoT device security. I followed TF-M as it is PSA certified and widely adopted by the industry. One of the key ideas is that the runtime of a device is divided into Secure Processing Environment (SPE) and Non Secure Processing Environment (NSPE). All keys are stored in SPE and never leave SPE, nor accessed directly by NSPE. NSPE can only call APIs from SPE as security services.

    Currently in libcoap, the PSK is being passed around, e.g. calling setup_psk before creating a session using coap_new_client_session_psk2. This is against TF-M's principle and makes device less secure.

    Describe the solution you'd like

    libcoap should provide "opaque" apis, like Mbedtls' mbedtls_pk_setup_opaque vs mbedtls_pk_parse_key. This way the keys are no more passing around and will be stored in SPE safely.

    Refer to Mbedtls' PSA-enabled primitives here: Mbedtls

    enhancement security 
    opened by jqiaobln 1
Juice the carrots from ウマ娘プリティーダービー (Umamusume Pretty Derby) - Android implementation

Riru-CarrotJuicer Hooks the decryption function in libnative.so of ウマ娘プリティーダービー (Umamusume Pretty Derby), to allow inspecting the packets. For Windows

Huang Yue 25 Jun 27, 2022
This is a simple C++ implementation of plant-like structures defined with bracketed OLsystems.

Tree Hundred This is a simple C++ implementation of plant-like structures defined with bracketed OLsystems, as described in the book The Algorithmic B

null 22 Apr 22, 2022
An implementation of yacc for the janet programming language.

janet-yacc An implementation of yacc for the janet programming language. The implementation is based heavily on https://c9x.me/yacc/. Example from ./e

null 11 Nov 22, 2021
libddwaf is Datadog's implementation of a WAF engine

Datadog's WAF libddwaf is Datadog's implementation of a WAF engine, with a goal of low performance and memory overhead, and embeddability in a wide va

Datadog, Inc. 8 Jun 23, 2022
Small implementation of c++ entity component system inspired by Unity

EntityComponentSystem About This is small implementation of entity component system with C++. The API is heavily inspired by Unity ECS framework, but

Lukas Chodosevičius 2 Oct 13, 2021
Crown (formerly Crowncoin) reference implementation

Crown Core integration/staging tree https://crownplatform.com What is Crown? Crown is an experimental digital currency that enables instant payments t

Crown Platform 4 May 31, 2022
An open source re-implementation of LEGO Rock Raiders 🪨⛏

OpenLRR An open source re-implementation of LEGO Rock Raiders (PC). This is created by slowly implementing and replacing game functionality, while rel

Robert Jordan 34 Jun 17, 2022
GNU project's implementation of the standard C library(with Xuantie RISC-V CPU support).

GNU project's implementation of the standard C library(with Xuantie RISC-V CPU support).

T-Head Semiconductor Co., Ltd. 5 Mar 17, 2022
A basic A* implementation showing how to use C++20 modules alongside UWP and C++/WinRT.

Introduction This is a port from an old application that was original written in a mix of C++14, Java and C++/CX. Originaly the goal was to use a simp

null 9 Mar 2, 2022
C implementation of C++ Utility functions Integer Comparison Macros

C implementation of C++ Utility functions Integer Comparison Macros

Robert C. Seacord 15 May 27, 2022
Lightweight URL & URI parser (RFC 1738, RFC 3986)

Lightweight URL & URI parser (RFC 1738, RFC 3986) (C) Sergey Kosarevsky, 2015-2020 @corporateshark [email protected] http://www.linderdaum.com http://

Sergey Kosarevsky 81 Jun 21, 2022
:hocho: Strictly RFC 3986 compliant URI parsing and handling library written in C89; moved from SourceForge to GitHub

uriparser uriparser is a strictly RFC 3986 compliant URI parsing and handling library written in C89 ("ANSI C"). uriparser is cross-platform, fast, su

uriparser 243 Jun 26, 2022
Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockford's base32. MIT licensed with consistent, flexible API.

cppcodec Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockf

Topology 458 Jun 23, 2022
Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockford's base32. MIT licensed with consistent, flexible API.

cppcodec Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockf

Topology 458 Jun 23, 2022
Scripts to help create QUIC version test vectors in RFC 9001 format.

quic-test-vector Scripts to help create QUIC version test vectors in RFC 9001 format. Just type 'make all' to build everything. There are two tools he

null 2 Jan 21, 2022
In DFS-BFS Implementation In One Program Using Switch Case I am Using an Simple And Efficient Code of DFS-BFS Implementation.

DFS-BFS Implementation-In-One-Program-Using-Switch-Case-in-C Keywords : Depth First Search(DFS), Breadth First Search(BFS) In Depth First Search(DFS),

Rudra_deep 1 Nov 17, 2021
EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

EA Standard Template Library EASTL stands for Electronic Arts Standard Template Library. It is a C++ template library of containers, algorithms, and i

Electronic Arts 6.5k Jun 29, 2022
An Open Source Implementation of the Actor Model in C++

CAF: C++ Actor Framework CAF is an open source implementation of the actor model for C++ featuring lightweight & fast actor implementations, pattern m

CAF: C++ Actor Framework 2.7k Jun 19, 2022
an efficient feature complete C++ bittorrent implementation

libtorrent is an open source C++ library implementing the BitTorrent protocol, along with most popular extensions, making it suitable for real world d

Arvid Norberg 4k Jun 24, 2022
Concurrency Kit 2.1k Jun 18, 2022
An implementation of Actor, Publish-Subscribe, and CSP models in one rather small C++ framework. With performance, quality, and stability proved by years in the production.

What is SObjectizer? What distinguishes SObjectizer? SObjectizer is not like TBB, taskflow or HPX Show me the code! HelloWorld example Ping-Pong examp

Stiffstream 287 Jun 17, 2022
C++ implementation of a fast hash map and hash set using hopscotch hashing

A C++ implementation of a fast hash map and hash set using hopscotch hashing The hopscotch-map library is a C++ implementation of a fast hash map and

Thibaut Goetghebuer-Planchon 551 Jun 17, 2022
C++ implementation of a fast hash map and hash set using robin hood hashing

A C++ implementation of a fast hash map and hash set using robin hood hashing The robin-map library is a C++ implementation of a fast hash map and has

Thibaut Goetghebuer-Planchon 771 Jun 24, 2022
s2n : an implementation of the TLS/SSL protocols

s2n is a C99 implementation of the TLS/SSL protocols that is designed to be simple, small, fast, and with security as a priority. It is released and l

Amazon Web Services 4.1k Jun 20, 2022
A simple C++ 03/11/etc timer class for ~microsecond-precision cross-platform benchmarking. The implementation is as limited and as simple as possible to create the lowest amount of overhead.

plf_nanotimer A simple C++ 03/11/etc timer class for ~microsecond-precision cross-platform benchmarking. The implementation is as limited and simple a

Matt Bentley 88 Jun 20, 2022
C++ implementation of the Google logging module

Google Logging Library The Google Logging Library (glog) implements application-level logging. The library provides logging APIs based on C++-style st

Google 5.4k Jun 21, 2022
jemalloc websitejemalloc - General purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support. [BSD] website

jemalloc is a general purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support. jemalloc first came

jemalloc memory allocator 7.1k Jun 27, 2022
Single C file TLS 1.2/1.3 implementation, using tomcrypt as crypto library

TLSe Single C file TLS 1.3, 1.2, 1.1 and 1.0(without the weak ciphers) implementation, using libtomcrypt as crypto library. It also supports DTLS 1.2

Eduard Suica 442 Jun 22, 2022