BSD socket offload with IPv4 and IPv6 disabled breaks many client-based net samples

[mike-scott]

Is your feature request related to a problem? Please describe.
When using the socket offload API where IPv4 and IPv6 are disabled, all net samples are broken due to their dependence on NET_CONFIG_* settings.

Describe the solution you'd like
In a perfect world, samples would still work -- the main issue being where to get things like peer server address.

Describe alternatives you've considered
Just starting the discussion. I haven't explored alternatives yet.

Additional context
Devices like TI's SimpleLink Wifi and the upcoming modem context changes allow for them to be used without the majority of the Zephyr IP stack -- instead offloading the IP stack onto the NCP via the NET_SOCKETS_OFFLOAD config.

This saves quite a lot of flash and processing when combined with CONFIG_IPV4=n and CONFIG_IPV6=n, but means the user has to customize each networking sample.

[mike-scott]

@pfalcon @GAnthony starting the discussion

[mike-scott]

also adding @rlubos

[jukkar]

When using the socket offload API where IPv4 and IPv6 are disabled, all net samples are broken due to their dependence on NET_CONFIG_* settings.

Could you elaborate this a bit more? At least compilation seems to work just fine if I disable IPv4 and IPv6. What kind of issues there are in runtime (I do not have any offloaded devices that I could try myself)?.

What I did to test the compilation:

• Create samples/net/sockets/echo_server/overlay-offload.conf with this content

CONFIG_NET_IPV4=n
CONFIG_NET_IPV6=n
CONFIG_NET_OFFLOAD=y
CONFIG_NET_SOCKETS_OFFLOAD=y

$ cd samples/net/sockets/echo_server
$ cmake -B build -DBOARD=cc3220sf_launchxl -DOVERLAY_CONFIG=overlay-offload.conf .
$ make -C build

[mike-scott]

@jukkar You are correct. The server-based samples might work somewhat.

However, many of the client-based samples all use logic like this in echo_client/tcp.c::start_tcp():
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/sockets/echo_client/src/tcp.c#L175

All functions of tcp are wrapped with IS_ENABLED(CONFIG_NET_IPV*) checks.

Or the coap_client:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/sockets/coap_client/src/coap-client.c#L66

(Fixes title of the issue to be more specific)

[jukkar]

All functions of tcp are wrapped with IS_ENABLED(CONFIG_NET_IPV*) checks.

Indeed, that is unfortunate. One option could be to change the IS_ENABLED(CONFIG_NET_IPV*) to IS_ENABLED(USE_IPV*) and then have in the code something like this

#if defined(CONFIG_NET_IPV6) || defined(CONFIG_NET_OFFLOAD)
#define USE_IPV6
#endif 

Edit: hmm, just realized that offloading does not mean that IPv6 is enabled so the above check would need more tweaking.

[jukkar]

After some thinking, I think we need to leave the IS_ENABLED(CONFIG_NET_IPV*) as is in the samples as they depend on an IPv6 feature. Enabling IPv6 feature is a generic thing and has nothing to do with offloading.
We need to fix the other part of the system so that if the user enables offloading, then we disable core IPv6 & IPv4 stuff. In practice this probably means adding some new kconfig options and some voodoo magic in CMakeLists.txt file, or something like that. I try to come up with some patches for this.

[rlubos]

I've used NET_RAW_MODE for some time with nRF91, it did its job, yet it proved to be too strict and disabled too much. I'd also avoid disabling native TCP/IP stack solely on the offloading option, as it would prevent the use cases that #18106 will open (like running both native and offloaded stack).

I think that Jukka got the point here, that we'd need a new Kconfig (perhaps something like CONFIG_NATIVE_IP_STACK), that would control only the inclusion of the native stack, w/o messing with the app protocols or utils. The config should be enabled by default, and the offloaded engines (or samples) could decide whether they disable the native stack or not.

[jukkar]

I created a PR that allows user to disable native IP stack. It is only build tested as I do not have proper hw to test it.

[mike-scott]

NOTE TO BE INCLUDED IN THIS FIX
The LwM2M subsys makes use of several CONFIG_NET_IPv* checks which include 1 for DNS. When using offloaded APIs there is no requirement for IPv4/IPv6 to be enabled and this is currently being worked around by defaulting offload APIs to hint at using IPv4 DNS lookups.

A proper solution needs to be implemented: as in we might force offloaded drivers to define which IP versions they support. With the addition of NET_NATIVE this wouldn't add the internal stack-based code, but would allow subsystems to still use this information in an intelligent way.