Coder Social home page Coder Social logo

libcoap's Introduction

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

Build Status: main Build Status: develop Static Analysis Fuzzing Status CIFuzz Status pre-commit

Copyright (C) 2010—2024 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 https://coap.space or CoAP Wiki.

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-NG, Espressif/ESP-IDF, LwIP and RIOT-OS hosted environments.

The following RFCs are supported

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]

  • wolfSSL (Minimum version 5.2.0) [PKI, PSK, RPK(5.6.4+) and DTLS1.3(5.4.0+)]

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

libcoap's People

Contributors

anyc avatar chrysn avatar cladmi avatar diego-santacruz avatar gocarlos avatar hasheddan avatar helmutg avatar hmalpani avatar jcmichelou avatar john-carter avatar jpcomtois avatar kb2ma avatar kkrentz avatar kurdymalloy avatar laukik-hase avatar lewixliu avatar malinengineer avatar markushx avatar mniestroj avatar mrdeep1 avatar nmeum avatar obgm avatar pawelwms avatar pulsastrix avatar rretanubun avatar sgso avatar thp-comnets avatar tijuca avatar vllungu avatar yr2004 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libcoap's Issues

About DTLS

Has libcoap provided the DTLS security for CoAP?

DTLS branch build errors

Hey Olaf,
I checked out your DTLS branch because I need a simple coap client that supports DTLS with PSK. When I try to build tinyDTLS I receive the following errors:

config.status: error: cannot find input file: `dtls_config.h.in'
...
dtls.c:20:22: fatal error: tinydtls.h: No such file or directory
#include "tinydtls.h"
^
compilation terminated.
: recipe for target 'dtls.o' failed
make: *** [dtls.o] Error 1

When I compare the file dir structure to the normal tinyDTLS I see that a couple of .h and .in files are missing. Do you think it would be possible for you to do a quick check on that?

Thanks in advance!

The "dtls" branch doesn't compile

Hello,

I've cloned the repository and tried to compile the dtls branch, but I get some linking errors:

Steps followed:

git clone --recursive https://github.com/obgm/libcoap.git
git checkout dtls
git submodule update --init --recursive
./autogen.sh
./configure
make

Error log:

[...]
libtool: link: gcc -shared  -fPIC -DPIC  src/.libs/libcoap_1_la-address.o src/.libs/libcoap_1_la-async.o src/.libs/libcoap_1_la-block.o src/.libs/libcoap_1_la-coap_dtls.o src/.libs/libcoap_1_la-coap_event.o src/.libs/libcoap_1_la-coap_keystore.o src/.libs/libcoap_1_la-coap_time.o src/.libs/libcoap_1_la-debug.o src/.libs/libcoap_1_la-encode.o src/.libs/libcoap_1_la-hashkey.o src/.libs/libcoap_1_la-mem.o src/.libs/libcoap_1_la-net.o src/.libs/libcoap_1_la-option.o src/.libs/libcoap_1_la-pdu.o src/.libs/libcoap_1_la-resource.o src/.libs/libcoap_1_la-str.o src/.libs/libcoap_1_la-subscribe.o src/.libs/libcoap_1_la-uri.o src/platform/posix/.libs/libcoap_1_la-coap_io.o src/platform/posix/.libs/libcoap_1_la-prng.o src/platform/posix/.libs/libcoap_1_la-run.o   -L./ext/tinydtls -ltinydtls  -O2 -Wl,--version-script=./libcoap-1.map   -Wl,-soname -Wl,libcoap-1.so.0 -o .libs/libcoap-1.so.0.0.0
/usr/bin/ld: ./ext/tinydtls/libtinydtls.a(dtls.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
./ext/tinydtls/libtinydtls.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libcoap-1.la] Error 1
make[2]: Leaving directory `/home/alinmicu/devel/windspring/libcoap2'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alinmicu/devel/windspring/libcoap2'
make: *** [all] Error 2

My understanding is that libcoap needs a tinydtls shared library, but it only has a static library available.

I'm not very familiar with autotools. Is there an easy way to either generate shared libraries for tinydtls or to make libcoap work with the tinydtls static libraries already generated? I would personally prefer the latter, as I'm planning to use the library on embedded systems and shared libraries aren't suitable for this.

In libcoap enabled tinydtls observer is not working properly

Hello, as mentioned above in coaps-server side resource was not resetting to dirty option so it was not sending the observer reply, now it is sending resource updates but it is not un-subscribing from observe option after timeout. It this related to select() write option as there it is mentioned as below.
if (FD_ISSET(fd, &wfds))
/* FIXME */;
Please help

Indirect inclusion of sys/types.h in lwippools.h causes conflicting types

This issue is valid if lwIP's socket interface is enabled (LWIP_SOCKET).

The files included by lwippools.h eventually includes the sys/types.h header file. In this header file some socket related definitions are defined, e.g. "fd_set". The same definitions are defined by lwIP's socket interface in sockets.h. This causes conflicted types error when compiling.

A more comprehensible example

Hi,

I'm trying to understand the server exemple but its 1200 lines and the lack of comments has discouraged me. Do you have simpler examples or at least function descriptions?

URI query parsing returns to long option sizes

I would like to parse the URI query parameters of GET requests. The important part of the code:

coap_opt_iterator_t opt_iter;
coap_opt_filter_t f = {};
coap_opt_t *q;
coap_option_filter_clear(f);
coap_option_setb(f, COAP_OPTION_URI_QUERY);
coap_option_iterator_init(request, &opt_iter, f);
while ((q = coap_option_next(&opt_iter)) != nullptr) {
    unsigned char *value = coap_opt_value(q);
    size_t size = coap_opt_size(q);
    ...
}

Parsing the type parameter is always correct but the name parameter causes problems:

Request: GET coap://127.0.0.1/call/name?name=testint&type=1
size: 13 (should be 12)
value truncated to size: name=testint�

Request: GET coap://127.0.0.1/call/name?name=testdouble&type=1
size: 17 (should be 15)
value truncated to size: name=testdouble�t

Now the funny part: if I switch the order of the parameters, everything is working fine.

EDIT: It's not working fine, only the name string is correctly determined in it's size, but the type int has an additional char at it's end.

Am I using the coap_option_* functions wrongly?

Used libcoap version: b425b15
Compiler definitions: -O0 -DWITH_POSIX
Used compiler: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) (I used g++)

Using coap_transaction_id() for build without WITH_POSIX and WITH_LWIP and WITH_CONTIKI

Hi there. We've agreed recently to remove coap_transaction_id() if neither WITH_POSIX, nor WITH_LWIP, nor WITH_CONTIKI is defined. Now I've noticed that coap_transaction_id() is used in places, where these WITH_* macros are not defined leading to build issues. What would you suggest to do in such cases? Cascade-remove all APIs using it, if neither of these macros is there?

Also, do you remember why we didn't want to use coap_transaction_id()? It still seems to be hashing the pdu->hrd->id without any of the macros. Is that not sufficient and that's why coap_transaction_id() shouldn't be used?

dtls branch has issue with ELF

Got this error when tried to compile in raspbian in RPi

cc -Wall -std=c99 -pedantic -g -DTEST_INCLUDE -DDTLSv12 -DWITH_SHA256   testecc.c ecc_test.o test_helper.o   -o testecc
/usr/bin/ld: ecc_test.o: Relocations in generic ELF (EM: 3)
/usr/bin/ld: ecc_test.o: Relocations in generic ELF (EM: 3)
/usr/bin/ld: ecc_test.o: Relocations in generic ELF (EM: 3)
/usr/bin/ld: ecc_test.o: Relocations in generic ELF (EM: 3)
/usr/bin/ld: ecc_test.o: Relocations in generic ELF (EM: 3)
/usr/bin/ld: ecc_test.o: Relocations in generic ELF (EM: 3)
ecc_test.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
<builtin>: recipe for target 'testecc' failed
make[3]: *** [testecc] Error 1

Please look at this issue

Missing COAP_TICKS_PER_SECOND factor in example/coap_server.c

In line 510 of the coap_server.c example a multiplication factor is missing. Instead

if ( nextpdu && nextpdu->t <= COAP_RESOURCE_CHECK_TIME )

it should be

if ( nextpdu && nextpdu->t <= COAP_RESOURCE_CHECK_TIME * COAP_TICKS_PER_SECOND )

nextpdu->t is in milliseconds and the check time is in seconds, so conversion is needed.

a2x error when trying to make libcoap

First of all, I'm sorry if this is on the wrong place.

After an apparently successful ./configure, I try to make and get the following ERROR:

(...)
Patching output file 1/1
lookup cache used 891/65536 hits=7471 misses=921
finished...
make[2]: Leaving directory `/home/bruno/riot_misc/libcoap/doc'
Making all in tests
make[2]: Entering directory `/home/bruno/riot_misc/libcoap/tests'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/bruno/riot_misc/libcoap/tests'
Making all in examples
make[2]: Entering directory `/home/bruno/riot_misc/libcoap/examples'
/usr/bin/a2x --doctype manpage --format manpage coap-client.txt
a2x: ERROR: "xmllint" --nonet --noout --valid "/home/bruno/riot_misc/libcoap/examples/coap-client.xml" returned non-zero exit status 127
make[2]: *** [coap-client.5] Error 1
make[2]: Leaving directory `/home/bruno/riot_misc/libcoap/examples'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bruno/riot_misc/libcoap'
make: *** [all] Error 2

Is there something I'm missing here?

Using libcoap in c++ code

From the coap main header file "coap.h" it looks like the code can be used by c++ applications.
when compiling with c++ compile a lot of errors pop up, mostly from "address.h" . Is it possible to use this implementation with c++ application ?

how to contribute to libcoap?

Hello libcoap admin

our team is interested in libcoap, and we add some new features for libcoap, how can we contribute our source code to libcoap? are there any process or standard to follow?

  1. can anyone contribute source code to libcoap?
  2. or our new Dev feature need to follow libcoap's technical roadmap ?

please give commnets, Thanks.

Does the develop branch of libcoap support lwIP

I tried to clone the source code, and follow the get started guide, but it seems the lwip example can't be compiled successfully. So I am wondering if the lwip support is still under development?

DTLS Contiki Makefile example

I'm trying to get the DTLS example compiled for Contiki but the process failes with:

gr3yh0und@debian:~/Downloads/libcoap/examples/contiki$ make
make -f Makefile.contiki V=1 CONTIKI=contiki TARGET=minimal-net NODE_ADDR=0x1000 server
make[1]: Entering directory '/home/gr3yh0und/Downloads/libcoap/examples/contiki'
make[1]: *** No rule to make target 'obj_minimal-net/coap_io.o', needed by 'contiki-minimal-net.a'.  Stop.
make[1]: Leaving directory '/home/gr3yh0und/Downloads/libcoap/examples/contiki'
Makefile:11: recipe for target 'server' failed
make: *** [server] Error 2

which probably happens due to the fact that coap_io.c is missing in src/platform/contiki. As src/platform/posix/coap_io.c is missing WITH_CONTIKI defs I've tried to copy the current version (dev branch) and build it which ends in:

gcc -Wl,--gc-sections,--undefined=_reset_vector__,--undefined=InterruptVectors,--undefined=_copy_data_init__,--undefined=_clear_bss_init__,--undefined=_end_of_init__ -Wl,-Map=contiki-minimal-net.map,-export-dynamic  server.co \
    contiki-minimal-net.a  -o server.minimal-net
contiki-minimal-net.a(net.o): In function `coap_new_context':
/home/gr3yh0und/Downloads/libcoap/examples/contiki/contiki/apps/libcoap/src/net.c:389: undefined reference to `coap_new_keystore'
/home/gr3yh0und/Downloads/libcoap/examples/contiki/contiki/apps/libcoap/src/net.c:390: undefined reference to `coap_dtls_new_context'
contiki-minimal-net.a(net.o): In function `coap_free_context':
/home/gr3yh0und/Downloads/libcoap/examples/contiki/contiki/apps/libcoap/src/net.c:459: undefined reference to `coap_dtls_free_context'
/home/gr3yh0und/Downloads/libcoap/examples/contiki/contiki/apps/libcoap/src/net.c:460: undefined reference to `coap_free_keystore'
contiki-minimal-net.a(net.o): In function `coap_send_impl':
/home/gr3yh0und/Downloads/libcoap/examples/contiki/contiki/apps/libcoap/src/net.c:613: undefined reference to `coap_dtls_get_session'
/home/gr3yh0und/Downloads/libcoap/examples/contiki/contiki/apps/libcoap/src/net.c:618: undefined reference to `coap_dtls_send'
contiki-minimal-net.a(net.o): In function `coap_read_endpoint':
/home/gr3yh0und/Downloads/libcoap/examples/contiki/contiki/apps/libcoap/src/net.c:909: undefined reference to `coap_dtls_handle_message'
collect2: error: ld returned 1 exit status
contiki/Makefile.include:280: recipe for target 'server.minimal-net' failed

The normal branch is compiling fine and I've also tried an older contiki version.

Background: I'm just starting to get a deeper look into that because I want to compare Contiki vs. RIOT. To make this comparison I need the same application on top. contiki/6lbr brings CoAP/tinyDTLS but is based on erbium as CoAP library. tinyDTLS and libcoap are available in Contiki and RIOT - but not combined - So I thought it could be possible to make the dtls branch work on both somehow.

LICENSE.BSD has only two clauses and is identical to the simplified BSD license

COPYING and README mention the revised BSD license which is a 3-clause BSD license but LICENSE.BSD has only two clauses and is identical to the simplified (2-clause) BSD license.

Thus, I think, the third clause is missing in LICENSE.BSD:
"Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."

Contiki, I think, has a 3-clause BSD license.

gettimeofday() path calculates time wrong

tmp = tv.tv_usec * Q(FRAC, (COAP_TICKS_PER_SECOND/1000000.0));
should be
tmp = SHR_FP(tv.tv_usec * Q(FRAC, (COAP_TICKS_PER_SECOND/1000000.0)), FRAC);

The code was fixed for linux but not for platforms that do not have clock_get_time

A commit to fix it is at franc0is@bde3052

can't get lwip example to build?

Hi,
this is probably just my brain being foggy, but... For some reason I can't get examples/lwip/ to build. When I run make as instructed on the default branch (develop), I get:

λ (/home/lotte/riot/libcoa/exampl/lwip) (develop)
$ make server CC=gcc
gcc -I. -I- -std=gnu99 -I../../include/coap -g3 -Wall -pedantic -Dopenbsd -DIPv4 -O0 -fpack-struct -Ilwip/src/include/ -Ilwip/src/include/ipv4/ -Ilwip-contrib/ports/unix/include/ -Ilwip-contrib/ports/unix/proj/minimal/   -c -o server.o server.c
cc1: note: obsolete option -I- used, please use -iquote instead
server.c:37:23: fatal error: lwip/init.h: No such file or directory
 #include <lwip/init.h>
                       ^
compilation terminated.
make: *** [server.o] Error 1

If I replace -I- with -iquote in the Makefile, I get:

λ (/home/lotte/riot/libcoa/exampl/lwip) (develop)
$ make
cc -I. -iquote -std=gnu99 -I../../include/coap -g3 -Wall -pedantic -Dopenbsd -DIPv4 -O0 -fpack-struct -Ilwip/src/include/ -Ilwip/src/include/ipv4/ -Ilwip-contrib/ports/unix/include/ -Ilwip-contrib/ports/unix/proj/minimal/   -c -o server.o server.c
server.c:37:23: fatal error: lwip/init.h: No such file or directory
 #include <lwip/init.h>
                       ^
compilation terminated.
make: *** [server.o] Error 1

When I switch to the master branch, I directly get to the second error message.
Am I missing something? Is this example still up to date? (All I’m looking for is a CoAP command line client, really)

Retransmission of confirmable messages are not working with LWIP

When coap_pdu is initialized, LWIP reserve space at the beginning of the pbuf to encode the data related to layers of the protocol stack that are under COAP (like UPD, IP, Ethernet) .

During transmission (udp_sendto), lwip encode the data of those layer and move the pbuf paylod pointer. However this pointer is not reset after the transmission.

Libcoap retries fail because LWIP has not enought space to encode the UDP/IP headers.

In my case, I'm using Libcoap with ipv6 and I get the following error message from LWIP: "ip6_output: not enough room for IPv6 header in pbuf"

To fix this issue, I propose to reset the pbuf payload position after each transmission:

In method coap_send_impl (net.c):

  udp_sendto(context->endpoint->pcb, pdu->pbuf,
			ip6_2_ip(&dst->addr), dst->port);

  //Reset lwip pbuf to the state it was before the call to udp_sendto
  pdu->pbuf->payload = pdu->hdr;

Note: I'm not using the latest version of libcoap and I'm still using LWIP 1.4.1 but I think the problem is also present in latest version of the code. (to be validated)

ipv4 multicast send error

coap server join to multicast 224.10.10.11, coap client send to server, it will occur error
***************************log
local 224.10.10.11
remote 192.168.1.110

Dec 13 15:45:44 CRIT coap_send_impl: Invalid argument
Dec 13 15:45:44 DEBG cannot send response for message 57659

modify IN_MULTICAST(a->addr.sin.sin_addr.s_addr) to IN_MULTICAST(htonl(a->addr.sin.sin_addr.s_addr))


bug is clear!!!! please check it!


static inline int
_coap_is_mcast_impl(const coap_address_t *a) {
if (!a)
return 0;

switch (a->addr.sa.sa_family) {
case AF_INET:
return IN_MULTICAST(a->addr.sin.sin_addr.s_addr);
case AF_INET6:
return IN6_IS_ADDR_MULTICAST(&a->addr.sin6.sin6_addr);
default: /* fall through and signal error */
;
}
return 0;
}


Converting IPv4 to IPv6 multicast not working

I've set up a sample CoAP client application that can send requests and parse out the responses; however, I need to convert it to an IPv6 multicast solution to accommodate other pieces of a project. However, I'm not seeing any outgoing traffic after these changes. I only changed a handful of lines to make it support IPv6 and the application is running with no errors but no traffic is actually going out across the network. I made the following changes:

source.addr.sin6.sin6_family = AF_INET;
to
source.addr.sin6.sin6_family = AF_INET6;

src_addr.addr.sin.sin_addr.s_addr = inet_addr("0.0.0.0");
to
inet_pton(AF_INET6, "::1", &(source.addr.sin6.sin6_addr));

dst.addr.sin6.sin6_family = AF_INET;
to
dst.addr.sin6.sin6_family = AF_INET6;

dst_addr.addr.sin.sin_addr.s_addr = inet("192.168.1.210")
to;
inet_pton(AF_INET6, "bbbb::1", &(dest.addr.sin6.sin6_addr));

I've tested a multicast CoaP method through node-coap and I'm seeing a successful response back through it so I'm not sure where it's failing. Any thoughts? Thanks!

autogen dosn't work with autoconf 2.63

error message:
[HINT] You can run 'autogen.sh --clean' to remove all generated files by the autotools.

Found 'autoconf'.
Found 'aclocal'.
Found 'libtool'.

---> Found all needed tools! That's fine.

Generating needed autotools files for libcoap by running autoreconf ...
autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force ${ACLOCAL_FLAGS} -I m4 configure.ac:27: warning: macroAM_PROG_AR' not found in library
configure.ac:116: error: Autoconf version 2.64 or higher is required
m4/ax_check_compile_flag.m4:60: AX_CHECK_COMPILE_FLAG is expanded from...
configure.ac:116: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: autom4te failed with exit status: 63
autoreconf: aclocal failed with exit status: 63

automake version:1.11.1 autoconf version:2.63

coap_add_attr() does not take ownership over passed data(name/val)

https://github.com/obgm/libcoap/blob/develop/src/resource.c#L333-L334

I understand that as of current it is user's responsibility to ensure that passed pointers are valid.
But i think it would be more rational for coap_attr_t struct to take ownership over passed values.
After all this strcture belongs to resource now and user should not change values inside of it without using a proper API. Though there is none for such needs as of current...

I didn't look into other places, but i would generally think that taking ownership of all resources would be right for library and its structures. Otherwise the line between library and application becomes dim.

UPD:
The same for uri in coap_resource_init

Headers contain non-prefixed/namespaced macros and declarations

coap/debug.h defines the macros info, warn, debug. This is bad practice and worse is that these are some pretty common words which may already be in use in other applications and libraries. Since they are preprocessor macros and not regular functions, they don't care about scope and will mess up headers from other libraries.

There are some more non-prefixed macros in include/coap:

  • debug.h - info, warn, debug macros
  • prng.h - prng, prng_init macros
  • options.h - options_next, PCHAR macros, options_start function
  • encode.h - Nn, HIBIT, EMASK, MMASK, MAX_VALUE, ENCODE_HEADER_SIZE macros
  • resource.h - RESOURCES_xxx macros

coap.h includes all of these files and therefore it's not easy to avoid them.

The specific collision that I received was when mixing Eigen 3.2 with libcoap. Eigen is a header-only library and declares some classes with methods named info(), which are messed up by the preprocessor because of the non-prefixed macros in debug.h.

A work around is to reorder the include lines in the application code, but it is difficult to realize for someone who is not familiar with the specific libraries involved or less experienced in C.

The best solution in my opinion would be to prefix all public macros with COAP or LIBCOAP and change them to uppercase, and rename options_start to coap_options_start.

lwIP port assumes features that might not be available

-sys/types.h and errno.h are included but not used
-ssize_t is not actually used (functions using the type are not called/not implemented)
-IP address definition changed in recent versions of lwIP, there are macros for address classification
-lwIP provides random numbers and debug output that might wrap rand()/srand()/printf() (or not)

I have hit those issues trying to run libcoap on an embedded target that doesn't provide certain features, unlike lwIP-on-Linux. The attached patches should take care of it, and should work on lwIP 1.4.0 or newer (that's 2011).

patches.zip

DTLS branch make fails

Hello guys,

Today I tried to compile the dtls branch with the follwing commands (debian jessie):

$ git clone https://github.com/obgm/libcoap
$ cd libcoap
$ git checkout dtls
$ ./autogen.sh
$ ./configure --disable-documentation

when the ./configure scripts finishes its execution I get the following output:

libcoap configuration summary:
      libcoap package version : "4.1.2"
      libcoap library version : "0.0.0"
      libcoap API version     : "1"
      host system             : "x86_64-unknown-linux-gnu"
      build documentation     : "no"
      build unit test binary  : "no"
      build examples          : "yes"
             -->  use a2x     : "no"
      build with DTLS support : "yes"

Then I ran the make command

$ make

when the make command finished I got the following output:

Makefile:688: src/platform/posix/.deps/libcoap_1_la-coap_io.Plo: File o directory non esistente
Makefile:689: src/platform/posix/.deps/libcoap_1_la-prng.Plo: File o directory non esistente
Makefile:690: src/platform/posix/.deps/libcoap_1_la-run.Plo: File o directory non esistente
make: ***  Nessuna regola per generare l'obiettivo "src/platform/posix/.deps/libcoap_1_la-run.Plo".  Arresto.

How can I fix these errors ?

Thank you.

F.

POSIX coap_packet_t defined in .c

Is there a reason why coap_packet_t is defined in a header file (coap_io.h) for contiki and lwip but it is defined in source (coap_io.c) for posix?
Copy-pasting it to the header file does not seem to break the build and enables other apps to peek into the packet.
Is it safe to move it to the header or is it going to come back and haunt me later?:)

Conflict with one letter pre-processor variable name in public header

Hi, and thank you for making libcoap.

the public header "include/coap/encode.h" defines the pre-processor variable "E" (currently line 20, branch "develop"). However, this may mess up with other headers, that would use such a variable name for other things.

For example this can happen when using libcoap with C++ and class templates, that often use one letter names in class prototypes (in my case it occurs when also including curlpp in my project).

I suggest renaming this variable (which defines, I believe, the size of the CoAP packet header), into something longer and more explicit, like "ENCODE_HEADER_SIZE".

For anyone who may have the same issue, a workaround is to undefine the pre-processor variable E after including the libcoap headers. Here is an example:

#include <coap.h>
#include <resource.h>

#undef E

Regards,
G. Le Gall

how to build it on stm32

I want to use libcoap on my stm32 board by keil, what steps should i follow? Is there any guide ?

Cross compilation issue

Hello guys,

Trying to cross compile the examples of the develop repository I got stucked with a rpl_malloc issue.

Basically I've done the following:

$ git clone https://github.com/raspberrypi/tools
$ cd libcoap
$./autogen.sh
$./configure --host=arm-linux-gnuabihf --disable-documentation
$ make

Then the command exit with this error
undefined reference to "rpl_malloc"

I found that setting the following env variable solved the problem:
$ export ac_cv_func_malloc_0_nonnull=yes

I don't know if that is an issue or not but it wasn't straightforward how to get it solved.

Thank you for your work.

FedBerg.

Retransmit is a protocol detail and should not be implemented in the client

All of the POSIX examples implement the re-transmit part of the standard in the application code, mostly to make up for the fact that it isn't implemented in the library itself.

E.g. in examples/client.c:

  [...]
  while ( !(ready && coap_can_exit(ctx)) ) {
    FD_ZERO(&readfds);
    FD_SET( ctx->sockfd, &readfds );

    nextpdu = coap_peek_next( ctx );

    coap_ticks(&now);
    while (nextpdu && nextpdu->t <= now - ctx->sendqueue_basetime) {
      coap_retransmit( ctx, coap_pop_next( ctx ));
      nextpdu = coap_peek_next( ctx );
    }
  [...]

This is unsanitary and breaks many of the abstractions in obvious ways. For example, the coap_context_t object when compiled with -DWITH_POSIX keeps a reference to the socket so that - and this is the only reason as far as I can tell - the client can use it in its re-transmit code.

The Contiki & lwIP ports implement re-transmit in the library, which makes the above fact even more puzzling.

esp-open-rtos compatibility

I am attempting to get this working in esp-open-rtos, but there seems to be a snag with the custom lwip memp allocation pool.

Using the custom memory pool is a great idea, but is it possible to use libcoap without it? The RTOS seems to disable it on purpose

coap_get_data() sets not exactly right pointer

The actual data is stored in position pdu->data++;
https://github.com/obgm/libcoap/blob/develop/src/pdu.c#L264

But the set value will be pdu->data which is COAP_PAYLOAD_START
So user must pay attention to that and increment data to get actual payload.

I would suggest to consider actually mentioning it in function description or change it return pointer to actual payload.

BTW: Also question is the same for received PDU?
From my experience it seems not to be so.

p.s. the problem is detected by valgrind when i trying to verify payload of created pdu

autogen doesn't work with automake 1.15

On a stock debian wheezy but with an upstream autoconf/automake (1.15), but stock libtool, I get a failure from autogen.sh. It's the mismatch that breaks things. Removing the 1.15 automake from /usr/local/bin, solves the problem.

I'm just writing this for others who might have this problem.

%automake --version
automake (GNU automake) 1.15

{{{
dooku-[projects/pandora/pi/libcoap] mcr 10063 %./autogen.sh

[HINT] You can run 'autogen.sh --clean' to remove all generated files by the autotools.

Found 'autoconf'.
Found 'aclocal'.
Found 'libtool'.

---> Found all needed tools! That's fine.

Generating needed autotools files for libcoap by running autoreconf ...
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force ${ACLOCAL_FLAGS} -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
Makefile.am:40: error: Libtool library used but 'LIBTOOL' is undefined
Makefile.am:40: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
Makefile.am:40: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
Makefile.am:40: If 'LT_INIT' is in 'configure.ac', make sure
Makefile.am:40: its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1
}}}

TCP support?

Hi,
Does it support transport over TCP?

Regards, Santos

coap_split_uri should operate on const str

The coap_split_uri function modifies the hostname to lowercase. While this is documented, it is impractical when dealing with URIs that come along as const char, be it from ROM or from network traffic.

Depending on the API guarantees currently in place, I'd prefer the function to just drop that behavior and take a const argument (*p and *q would become const too); if that's impossible, there should be a coap_split_uri_const or similar function that does provide said behavior.

I'd argue that lowercasing the hostname is a behavior that's pointless, because even when lowercased, there can still be different string representations of what is an equivalent network destination, be it before DNS resolution ("github.com" and "github.com." should be equivalent), or after (alias hostnames). Hashing the hostname only takes you so far, and if a system does encounter the same hostname in different capitalizations, it should be able to cope with it just as if they were denormalized in any other way. The systems' getaddrinfo and friends should all be able to cope with mixed-case names.

coap_pdu_t inconsistencies regarding data size

The coap_pdu_t struct currently has a size_t "max_size" field and an unsigned short "length" field, thus making it possible to use coap_add_data() and overflow "length". Also, coap_add_data() is using a unsigned int "len" argument to pass the amount of the new data.

It would be good to decide on one specific type and stick to it throughout the code.

.gitignore issue

I ran into an issue building libcoap on RHEL 7.3 (x86_64)

This only happened after the libcoap directory was checked back into a different git repo.
The configure step failed after a git pull.
The issue turned out to be the .gitignore file for the m4 directory

I changed the m4 text and this fixed the problem

-m4/
+m4/libtool.m4
+m4/ltoptions.m4
+m4/ltsugar.m4
+m4/ltversion.m4
+m4/lt~obsolete.m4

Note this text in .gitignore:

warn about specific macros in the m4 directory if they missing

!m4/ax_*

This text gets overridden by the m4/ line

These 2 files need to be present for RHEL7 to work:
m4/ax_check_compile_flag.m4
m4/ax_check_link_flag.m4

Documentation

Is it that hard to provide at least one example on how to compile a "hello world" program that uses libcoap?

More portability

Hi,

I think it's not easy to port libcoap to other platforms neither POSIX, Contiki, nor lwIP.
Is there any guide for it?
I don't want to add another #ifdef ~ #endif blocks into libcoap code.

Like coap_io.c that has CUSTOM_COAP_NETWORK_SEND and CUSTOM_COAP_NETWORK_READ, I think other codes (including net.c) also should have preprocessors for more portability.

Regards,
Jongsoo

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.