Apparent network context leak with offloading driver (u-blox Sara r4)

[gpaquet85]

Describe the bug
I have an issue when I try to make multiple MQTT connection/disconnection.
I focused on net_context management.
Indeed in net_context_get function, I saw that I reached CONFIG_NET_MAX_CONTEXTS (equal to 10 in my prj.conf).
For your information, I use UBLOX sara r4 driver (on zephyr 1.14.1) and I wonder if contexts are well managed in this revision (or new one?), especially when socket is closed ?

To Reproduce
Compiling https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/mqtt_publisher:

1. mkdir build; cd build
2. cmake -DBOARD=boards\nrf52840_pca10059 -DSHIELD=sparkfun_sara_r4 -DCONF_FILE="prj.conf overlay-wncm14a2a.conf" (I am not sure of this configuration because I did this with our own board)
3. make
4. See error

Expected behavior
After 10 (equal to CONFIG_NET_MAX_CONTEXTS) connection/disconnection in TCP, you should have this behavior:
[try_to_connect:233] mqtt_connect: -2 .

Impact
It is not possible to communicate anymore in MQTT (TCP) because it is not possible to connect to broker after CONFIG_NET_MAX_CONTEXTS attemps

Screenshots or console output

Environment (please complete the following information):

• OS: Linux
• Toolchain ARM-GCC
• Tag: v1.14.1

Additional context
I also saw an issue in UBLOX SARA R4 socket close management when URC +UUCLOSE happens.
I am not sure that this issue is linked to our issue. Moreover, maybe it is well managed in new revision

[pfalcon]

cc: @jukkar, @mike-scott

[pfalcon]

cmake -DBOARD=board_xyz

@gpaquet85: Are you sure such a board exists?

[gpaquet85]

cmake -DBOARD=board_xyz

@gpaquet85: Are you sure such a board exists?

Indeed I forgot to change board name in my description. Sorry about that. I correct it in bug description right now

[WilliamGFish]

Isn't the the +UUSOCL a remote close response? I think it is worth looking at the remote server connection.

You may need look your server to get some clues.

[gpaquet85]

Isn't the the +UUSOCL a remote close response? I think it is worth looking at the remote server connection.

You may need look your server to get some clues.

Yes this +UUSOCL come from remote server. However, I can't modify anything on this one because it is handled by Orange operator

[WilliamGFish]

Isn't the the +UUSOCL a remote close response? I think it is worth looking at the remote server connection.
You may need look your server to get some clues.

Yes this +UUSOCL come from remote server. However, I can't modify anything on this one because it is handled by Orange operator

I get that response if you send to many malformed messages. I use Google, afafruit and bluemix. I've got that result when the JSON message upsets the server.

It's worth checking...

[gpaquet85]

Isn't the the +UUSOCL a remote close response? I think it is worth looking at the remote server connection.
You may need look your server to get some clues.

Yes this +UUSOCL come from remote server. However, I can't modify anything on this one because it is handled by Orange operator

I get that response if you send to many malformed messages. I use Google, afafruit and bluemix. I've got that result when the JSON message upsets the server.

It's worth checking...

@WilliamGFish thanks for your feedback it looks interesting. I will have a look.

[mike-scott]

@gpaquet85 Can you see if this is fixed by #22149

[gpaquet85]

@mike-scott it is ok for me. This is clearly fixed by your PR. Thanks again.