Inconsistent net_context APIs

[ag00se]

Zephyr version: v4.1.0-4041-g6ee55e42117a

I found the following behaviour during my implementation of a TCP server using net_context_* APIs:

After socket creation, bind and listen I called net_context_accept providing this as user_data parameter:
net_context_accept(_tcpContext, Communicator::tcpAcceptCallback, K_NO_WAIT, this)

The documentation of this function in net_context.h states:
"param user_data Caller-supplied user data."

I expected that this parameter is provided as argument to the registered callback.
Because of problems obtaining the correct data in the parameter I found during debbuging that the callback is executetd
like this (net/ip/tcp.c:3016):

accept_cb(conn->context, &conn->context->remote,
      net_context_get_family(context) == AF_INET6 ?
      sizeof(struct sockaddr_in6) : sizeof(struct sockaddr_in),
      0, context);

Instead of the registered user_data, the context itself is provided as argument.
I can obtain the correct user_data from the context (context->user_data) but the naming of the parameter and
the behaviour of the stack is not as expected. Furthermore, I don't know if this implementation is a subject to change?

Is this intentional? It seems that either the parameter name user_data is wrong or the tcp subsystem provides the wrong argument.
Other callbacks provide the correct user_data (e.g. `net/ip/tcp.c:35551):

conn->connect_cb(conn->context, 0, conn->context->user_data);

I also posted this in the community discord, but maybe this is the correct place?
Thanks for any feedback and regards

[github-actions]

Hi @ag00se! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[rlubos]

This looks wrong, it works fine with the socket implementation, as the socket layer provides the parent context as user_data for net_context_accept(), but it shouldn't be hardcoded like this in the TCP implementation. I'll send a fix.

[rlubos]

It was a pretty straightforward fix: #90645, hopefully CI doesn't blow up, but from testing locally it shouldn't be the case.

[ag00se]

Thanks for the fast response and bugfix.