Closed remenyo closed 2 years ago
I would have thought adding a new "connector" to libcoap would be more difficult than adding in a new netif. I assume that you have looked at the LwIP contribution for tapif.c which ends up doing raw input / output at the low level. I would have thought that this would not be too difficult to add into esp-idf.
Well, I think these two options are on the same level for me as I have to modify a library in the IDF itself. If I would do this, I would rather stay on UDP level and not bother with LwIP's raw data as UDP is supported by the modem. That's why I wanted to modify libcoap in the first place. Raw data is also is available through ESP NETIF custom I/O API, without touching LwIP/Libcoap FYI.
Until we can decide on the direction, we chose not to use CoAP, to be able to use UDP functionality of the modem.
Thank you for the fast response.
TLDR: I have to send coaps messages over an LTE modem (SIM7600 (E)) with an ESP32 running ESP-IDF. On what level can/should I intercept the communication, to route it to a custom network handler? Does this have to do with libcoap in your opinion? Or I should have posted this question on IDF's repo...
I read #838 According to that, I think i should make a new "connector" next to lwip and mbedtls (including them in my own codebase to utilize their features) to catch UDP requests and relay it to the modem. If I could get handles for the udp packet data, it would be easy to implement the relaying to the modem. (But if I see it right that would involve modifying the ESP-IDF repo (the libcoap repo in it.))
The other option I read about is to go a level lower and intercept messages with netif custom handlers. That's available in IDF, and does not need modifying libcoap but writing a custom netif connector for the LTE module is not the easiest thing.
I ask this question here in the hope that you heard about this problem/isssue with libcoap before, and you can recommend a way to implement the solution. Thank you for reading through.