LTE and ethernet coexistence

RE: LTE and ethernet coexistence

berulo01 — Tue, 20 Feb 2024 12:29:31 GMT

Thanks GilDev !

RE: LTE and ethernet coexistence

GilDev — Tue, 20 Feb 2024 08:33:48 GMT

We are all kind of trying to achieve the same thing but I think we are on our own on this, Zephyr doesn’t fully support multiple interfaces (at least it seems not for every network feature, like getaddrinfo() that is called by the aws_iot lib at least and maybe the mqtt one), nor does Nordic.

I reply to your GitHub mention here too, feel free to DM if you need to. My need is only one connection or the other, so I implemented my global flag as explained here. It may help your issue but probably needs to be adapted to Azure and concurrent network interfaces.

On my end, the whole MBEDTLS lib took so much space (45 kB heap + 6 kB × 2 SSL content buffers + much more) even after optimizing everything that we told our client we couldn’t do an AWS connection through Ethernet directly for now, and might need a gateway that will be accessible on a private local network through HTTP that will act as a middleman. I really hope in the end I’ll be able to make everything fit and work reliably but there are so variables (buffer sizes and such) and complex configuration and secure concepts that I cannot easily estimate this…

RE: LTE and ethernet coexistence

berulo01 — Mon, 19 Feb 2024 20:47:30 GMT

UPDATE:

I was able to get my above scenario working by doing a setsockopt of SO_BINDTODEVICE in the mqtt lib (used by Azure lib). I just hard-coded this for now.

Is there already a nice way to pass in specific network interface names into network libs so I can bind sockets to specific network devices? If not, are there any plans to add something for this?

RE: LTE and ethernet coexistence

berulo01 — Mon, 19 Feb 2024 17:07:40 GMT

Michal GilDev I am wondering if one of you could help clarify something regarding Socket Offloading and the recent github fix. I have a scenario where I am using nRF9160 LTE to connect to Azure via TLS offloading (i.e., TLS handled in modem), and also an Ethernet device for a local network that is NOT using TLS connections.

I am able to establish socket connections individually in each case using CONFIG_NET_SOCKETS_OFFLOAD_DISPATCHER, but only the first socket connections works. IOW, if LTE connects via Azure first, the Ethernet socket connection doesn't connect, and if the Ethernet socket connection comes up first, the LTE socket connection doesn't connect. My application requires that both connections run simultaneously (coexist) vs just one at a time.

I am using SO_BINDTODEVICE for the Ethernet socket, but haven't yet made any changes to the socket connection for Azure (IoT Hub). For Azure, it appears that I need to make an update to the underlying mqtt or mqtt_helper lib to support this.

Here is where I need some advice...
The updates to the SLM app from this PR seems to indicate that I would only need to make an update to Azure sockets if I am using Native TLS (mbedtls) as TLS_NATIVE is only used in this case. Which made me wonder if my use case is even supported by the Sockets Offload Dispatcher.

More pointed questions...

Can I use CONFIG_NET_SOCKETS_OFFLOAD_DISPATCHER with a non-TLS socket + a TLS-offload socket? If so, what are the socket options for both?
If the answer to #1 is no, will it work if I change the TLS socket to Native (mbedtls)? In this case I am assuming I would just follow what in done in the SML app.
Why doesn't the update to the SLM use SO_BINDTODEVICE? The Zephyr readme for Sockets Offload Dispatcher shows using it for this case. I'm assuming this is the missing piece for me -- just add SO_BINDTODEVICE to Azure/mqtt?

RE: LTE and ethernet coexistence

Michal — Mon, 05 Feb 2024 12:12:28 GMT

This was indeed an oversight and is already being addressed in https://github.com/nrfconnect/sdk-nrf/pull/13834

Thank you for reporting it.

Best regards,

Michal

RE: LTE and ethernet coexistence

Michal — Wed, 31 Jan 2024 19:04:43 GMT

Thank you for the information, I will look into it with the developers.

Best regards,

Michal

RE: LTE and ethernet coexistence

peran — Tue, 30 Jan 2024 09:45:05 GMT

knutel thank you so much for your reply! This was very helpful.

Michal In my search I came across line 1120 in nrf91_sockets.c, where the the socket is registered. This is registered as a not offloaded socket. But the nrf91 should be offloaded, correct? Because it is not registered as offloaded, socket_dispatcher gets confused and forwards me to nrf91 socket stuff when I try access native socket stuff. I have not tested this extensively, but my initial tests indicate that socket dispatching and SO_BINDTODEVICE now works.

This is my diff:

diff --git a/lib/nrf_modem_lib/nrf91_sockets.c b/lib/nrf_modem_lib/nrf91_sockets.c
index 4ab896064..a07322ce5 100644
--- a/lib/nrf_modem_lib/nrf91_sockets.c
+++ b/lib/nrf_modem_lib/nrf91_sockets.c
@@ -1117,7 +1117,7 @@ static int nrf91_socket_create(int family, int type, int proto)
 
 #define NRF91_SOCKET_PRIORITY 40
 
-NET_SOCKET_REGISTER(nrf91_socket, NRF91_SOCKET_PRIORITY, AF_UNSPEC,
+NET_SOCKET_OFFLOAD_REGISTER(nrf91_socket, NRF91_SOCKET_PRIORITY, AF_UNSPEC,
                    nrf91_socket_is_supported, nrf91_socket_create);
 
 /* Create a network interface for nRF91 */

RE: LTE and ethernet coexistence

knutel — Thu, 25 Jan 2024 14:34:48 GMT

See RE: nRF9160 Ethernet and LTE both available but cannot open sockets under Ethernet for details about why this does not quite work.

RE: LTE and ethernet coexistence

Michal — Wed, 24 Jan 2024 14:04:24 GMT

Hello,

I am consulting my colleagues and I will get back to you.

Best regards,

Michal

RE: LTE and ethernet coexistence

GilDev — Tue, 23 Jan 2024 09:59:39 GMT

Also very interested in this, as I’m having the same questions/issues.