Comments (31)
The example lwip-server code has coap_context_set_max_idle_sessions(main_coap_context, MEMP_NUM_COAPSESSION -1);
included to force idle sessions to be cleaned up in coap_endpoint_get_session()
, which leaves space for one new incoming session.
An idle session is defined as the reference count == 0
and there is nothing to be sent in the delay queue.
from libcoap.
As mentioned previously, 4.3.0 is somewhat old and things have moved on since then, including updates to LwIP. I would recommend you try the latest libcoap develop branch to see if there are in any issues there.
MEMP_MAX is defined in the LwIP source in src/include/lwip/memp.h.
For 4.3.0, the supported lwip branch is STABLE-2_0_3_RELEASE and the supported lwip-contrib branch is STABLE-2_0_1_RELEASE.
For the latest libcoap code, it is (lwip) STABLE-2_1_3_RELEASE and (lwip-contrib) STABLE-2_1_0_RELEASE.
With the correct lwip branches, the 4.3.0 and develop code build with no errors, but they use their own variant of lwipopts.h and lwippools.h.
from libcoap.
Ok, So I have updated to latest libcoap now. And I am trying to build with FreeRTOS with:
#define NO_SYS 0
#define SYS_FREERTOS 1
And I am getting following error:
/home/projects/playground1/build/debug/_deps/libcoap-src/src/coap_subscribe.c:60:3: warning: implicit declaration of function 'COAP_MUTEX_DEFINE' [-Wimplicit-function-declaration]
60 | COAP_MUTEX_DEFINE(e_static_mutex);
| ^~~~~~~~~~~~~~~~~
/home/projects/playground1/build/debug/_deps/libcoap-src/src/coap_subscribe.c:60:21: error: 'e_static_mutex' undeclared (first use in this function)
60 | COAP_MUTEX_DEFINE(e_static_mutex);
Seems like I need to define COAP_MUTEX_DEFINE, but not sure where ?
from libcoap.
well, I added the line:
#define COAP_MUTEX_DEFINE(_name) \
static sys_mutex_t _name
@coap_mutex_internal.h:63 and it is successful. But I have some other errors now.
But I think mutex is is missing on libcoap for now and you need to fix that.
from libcoap.
Thanks for your help troubleshooting here.
But I think mutex is is missing on libcoap for now and you need to fix that.
#1181 Raised for this.
error: 'coap_layer_func_t' has no member named 'lwip_write'
Looks like there is a #define write lwip_write
somewhere. I will go through and create a PR so that we do not get name clashes when using things like write
.
The conversion warnings need to be checked though, but are unlikely do be causing any issues.
from libcoap.
I will go through and create a PR so that we do not get name clashes when using things like write.
This should now be fixed in the latest version of the develop branch.
from libcoap.
#1181 Raised for this.
Is there a specific reason to use a variable name that starts with an underscore (_)? This is considered bad practice because this naming pattern is reserved for system-internal use.
from libcoap.
Good question. This was following how all of the other COAP_MUTEX_DEFINE() variants have been defined. Actual variable does not end up with a leading _, but all the usage of _name can be changed.
from libcoap.
Thanks for your help troubleshooting here.
But I think mutex is is missing on libcoap for now and you need to fix that.
#1181 Raised for this.
error: 'coap_layer_func_t' has no member named 'lwip_write'
Looks like there is a
#define write lwip_write
somewhere. I will go through and create a PR so that we do not get name clashes when using things likewrite
.The conversion warnings need to be checked though, but are unlikely do be causing any issues.
Yes, that was somewhere else in my project to have posix compatible calls. I fixed by disabling the option, however it can also be avoided like you mentioned. Thanks.
from libcoap.
Btw, is there any plan to have a release with all these lwip changes ? And is it possible to provide cmake support as well for lwip ?
from libcoap.
Btw, is there any plan to have a release with all these lwip changes ?
We are shortly going to be releasing 4.3.2 release candidate 1 (4.3.2rc1) which includes the LwIP changes.
And is it possible to provide cmake support as well for lwip ?
It just needs someone to create the appropriate cmake files for building LwIP with libcoap and submit a PR. I see that in LwIP STABLE-2_1_3_RELEASE is a CMakeLists.txt.
from libcoap.
I updated to the latest libcoap and lwip to 2.1.3. Still it is crashing on coap_net.c:473:
c = coap_malloc_type(COAP_CONTEXT, sizeof(coap_context_t));
I am trying to run it using FreeRTOS on embedded device.
I have set MEMP_USE_CUSTOM_POOL to 1 already. Do I need to implement anything for memory pool ? Any hints please ?
from libcoap.
Is it that c
is getting returned as NULL, or is it crashing somewhere in coap_malloc_type()
/ memp_malloc()
?
In examples/lwip/config/lwipopts.h
the libcoap example for LwIP has #define MEMP_USE_CUSTOM_POOLS 1
, and the (libcoap) memory pools are defined in examples/lwip/config/lwippools.h
. I guess you need to check which lwippools.h
is getting included.
from libcoap.
Index 19 is supposed to be for COAP_CONTEXT.
from libcoap.
Interesting - I would be expecting the addresses to be sequentially incrementing, so it looks like it is not picking up LWIP_MEMPOOL(COAP_CONTEXT, MEMP_NUM_COAPCONTEXT, sizeof(coap_context_t), "COAP_CONTEXT")
from your final lwippools.h.
I get (under linux) from the libcoap built client executable
(gdb) p memp_pools
$1 = {0x4412e0, 0x441320, 0x441360, 0x4413a0, 0x4413e0, 0x441420, 0x441460, 0x4414a0, 0x4414e0, 0x441520, 0x441560, 0x4415a0,
0x4415e0, 0x441620, 0x441660, 0x4416a0, 0x4416e0, 0x441720, 0x441760, 0x4417a0}
(gdb) p memp_COAP_CONTEXT
$5 = {desc = 0x441548 "COAP_CONTEXT", stats = 0x64e930, size = 1056, num = 1, base = 0x658e40 "", tab = 0x64e948}
(gdb) p/x &memp_PBUF
$1 = 0x4414e0
(gdb) p/x &memp_PBUF_POOL
$2 = 0x441520
(gdb) p/x &memp_COAP_CONTEXT
$7 = 0x441560
from libcoap.
Yes, may be I have some pool configuration issues. I will check this on my side. Thanks
from libcoap.
Ok, I checked on my code and I had an empty lwippools.h empty and I corrected it to use the one from libcoap. Now it is coming like:
However, as you can see the *tab is 0. and causing the allocation to fail. Am I missing anything further ? Could you please help here ?
from libcoap.
I think I am trying to initialize libcoap before lwip. Let me fix this first.
from libcoap.
Yes, lwip_init() should be called before coap_startup() before coap_new_context().
from libcoap.
Ok, I fixed it now. However I am not able to respond. I mean I can receive a GET request. But it does not respond anything. My implementation for libcoap 4.3.0 has not changed. It works with Linux though. Also I can only receive a request only twice and no request is received after that. I can ping the device, means it has not crashed. Any hints on this ?
Following is my response PDU formed:
from libcoap.
Update: If I comment lock and unlock in udp send as below, I can send out the responses:
I think this is a nested lock getting locked here which is already locked. I am analyzing the same.
But still I can only receive two messages ?
from libcoap.
It looks like LOCK_TCPIP_CORE() was invoked in coap_io_process(), which then timed out and called coap_io_process_timeout(), which then called coap_io_prepare_io(), which then tried to send out an unsolicited observe response, or async delayed response which called coap_socket_send().
This could have happened after 2 responses. The whole locking up of TCPIP_CORE needs to be reviewed.
from libcoap.
Interesting, because I am processing them in piggyback way and there should not be a delay in responding.
I tried to debug the 2 request reception issue, I found coap_io_lwip.c:245 line:
session = coap_endpoint_get_session(ep, packet, now);
returning NULL, we have coap sessions count as 2. Am I supposed to free the coap session anywhere or is it missing in libcoap anywhere ?
from libcoap.
Are you able to get this to work now?
from libcoap.
Yes, except the following two stuffs:
- I still have the local patch for LOCK_TCPIP_CORE()
- Device is not able to do a multicast response. It is getting delayed by libcoap as I could see by debugging, but no idea where it is going after that. I need to debug further to get into details.
from libcoap.
The multicast response is deliberately delayed as per RFC7252 Section 8.2 Request/Response Layer, which uses the async logic - hence the LOCK_TCPIP_CORE() fix you are doing in coap_socket_send().
I will have a look at this.
from libcoap.
After getting delayed, this response never comes out. I will debug further on this.
The Lock thing, yes, I am currently commented out the Lock/Unlock in the socket_send() call.
But, we can close this issue for now. If I find any issue in multicast send, I will create another issue. Makes sense ?
from libcoap.
I'm not sure how you are setting up multicast support in the server as the standard code does not have support for this for LWIP. It would be good to understand what changes you are making here,
from libcoap.
But the multicast sorting out should be on a separate Issue.
from libcoap.
yes
from libcoap.
For now we can close this issue as we are able to build and do basic communication. Thanks for your support.
from libcoap.
Related Issues (20)
- [Question] Proxy-scheme and proxy-uri example with coap-client and coap-server applications HOT 6
- Make coap_print_wellknown customizable HOT 6
- Wrong
- Access Token option addition to libcoap HOT 1
- Clarification on cancelling a block-wise request in the middle of transaction at client's end HOT 4
- Clarify required buffer size for coap_uri_into_options() and coap_split_uri() HOT 10
- coap_io_process does not return after ppp connection is closed HOT 10
- Name Service Switch interface integration of Coap-RD HOT 1
- Extra quotation mark for unix sockets in coap_print_addr HOT 2
- Specific api for setting the DTLS version HOT 5
- Unexpected token after long running block transfer HOT 9
- coap_send IPv6 HOT 1
- DTLS Connection id (CID) HOT 8
- coap-client gets stuck with large .well-known/core response HOT 3
- coap_new_context fails with "coap_init: no DTLS context available" error HOT 4
- setting coap_endpoint_set_default_mtu(x) causes messages to be resent when message size is bigger than x. HOT 13
- Provide defines for supported features and more feature availability check functions HOT 7
- Is there a plan to implement LAN broadcast functions HOT 1
- OSCORE response for CON request is always Non-piggybacked HOT 5
- IP_MULTICAST_LOOP / IPV6_MULTICAST_LOOP option configuration HOT 16
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libcoap.