DNS not working with NET_OFFLOAD

[rerickson1]

Describe the bug
When using NET_OFFLOAD, dns_write does not work because it does not properly create the socket first. The first call in dns_write, net_context_recv fails because a socket has not been created and associated to net_ctx->offload_context.

To Reproduce
I have come across this during development of a new modem driver. TCP/UDP socket send/RX is working with my driver, so I don't believe it is an issue with my code.

You should be able to test using the WNCM14A2A modem driver and the NET_SHELL with DNS_RESOLVER turned on. I do not have any hardware I can use to test against the current zephyr master.

Expected behavior
DNS should be able to be used with NET_OFFLOAD.

Impact
Showstopper. Need DNS working with NET_OFFLOAD in order to complete my project.

Screenshots or console output
Stack trace showing that net_ctx->offload_context is NULL because it hasn't been created properly.

Environment (please complete the following information):

• OS: Windows
• Toolchain: GCC 7_2018-q2-update
• Commit SHA or Version used: 1eead93

[rerickson1]

I think I found the root cause of what is going on. In short, dns_resolver is getting inited before the offload interface.

The details:
In dns_resolve_init, net_context_get is called to setup the sockets for DNS. At this point, the offload interface is not initialized yet (offload_iface_init), so the socket creation does not happen properly.

Looking at net_core.c -> net_init() , l3_init() is called before init_rx_queues. dns_init_resolver() is called in l3_init() and net_if_init() in init_rx_queues().

I moved l3_init() after init_rx_queues() and now everything works great. Is this a valid solution?

[tbursztyka]

I moved l3_init() after init_rx_queues() and now everything works great. Is this a valid solution

Nope, though you got the root cause: I think dns_resolver_init() should be moved out of l3_init(), it's not exactly part of l3 in fact: it's a service on top of the net stack (as dhcpv4 for instance).

[tbursztyka]

@rerickson1 Please have a look at #15141