net: Bind IP and get IP via DHCP: is the altered behavior intended or not?

[Aluleichtbau]

Hey net experts!

@jukkar, @sasataku

I was about to create an issue with a merged pull request, but I solved it in the application, but I am still not sure:

Is the altered behavior intended or not?

The issue would have looked like this:

Title: net: client with bound source port and DHCP assigned IP cannot receive packages

Describe the bug
Since #70021 is merged, a CoAP client does not receive responses on that socket if the conditions are met:

• DHCP client is enabled
• IP is configured statically (may be overridden, if a DHCP server sets it)
• IP is aquired by DHCP
• source port is bound

The symptoms:

• Request is transmitted correctly -> ok

• Response is transmitted to client

• Client issues ICMP Type 3 (Destination unreachable)

• Application Receive-callbacks are not triggered

• What target platform are you using?

  • Target is a STM32H730VB MCU, Zephyr SDK 0.16.5-1.

• What have you tried to diagnose or workaround this issue?

  • Tried with a static IP which works, tried without binding the port which also works
  • debugged with versions before and after the merge:
    • In later versions, in connection.c function net_conn_input incoming udp packages are not associated with the conn because conn->local_addr contains the statically configured IP and that is not equal to the DHCP assigned IP in the ip_hdr
    • In former versions, conn->local_addr holds the DHCP assigned IP
    • In former versions, the context->local address and port has been transfered to the newly registered conn_handler (net_context.c function recv_udp), new version does not change conn->local_addr
    • The conn->local_addr seems to be untouched by the DHCP assignment.
    • I suspect, DHCP changes the IP inside of the net_if which is associated to the connection by the net_context. After the change the conn->local_addr is not updated when getting an IP address via DHCP.
    • When not binding the IP is not set. So the check is not done.
      -------> SOLUTION: instead of passing CONFIG_NET_CONFIG_MY_IPV4_ADDR:54321 to bind the port only just pass 0.0.0.0:54321

• Is this a regression? If yes, have you been able to "git bisect" it to a
  specific commit?

  • 4f802e1

To Reproduce
(This is not tested, but I hope the idea will be more clear.)

Setup something like this:

# Networking config
CONFIG_NETWORKING=y
CONFIG_NET_IPV6=n
CONFIG_NET_IPV4=y
CONFIG_NET_UDP=y
CONFIG_NET_TCP=n
CONFIG_NET_ARP=y
CONFIG_NET_DHCPV4=y

CONFIG_NET_CONFIG_SETTINGS=y
CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.168.1.2"
CONFIG_NET_CONFIG_PEER_IPV4_ADDR="192.168.1.3"
CONFIG_NET_CONFIG_MY_IPV4_NETMASK="255.255.255.0"
CONFIG_NET_CONFIG_MY_IPV4_GW=""

code:

sock_fd = zsock_socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

struct sockaddr_in src_addr, dst_addr;

src_addr.sin_family = AF_INET;
src_addr.port = 54321;

dst_addr.sin_family = AF_INET;
dst_addr.port = 54322;
dst_addr.in_addr.s4_addr[0] = 192;
dst_addr.in_addr.s4_addr[1] = 168;
dst_addr.in_addr.s4_addr[2] = 1;
dst_addr.in_addr.s4_addr[3] = 2;

zsock_bind(sock_fd, &src_addr, sizeof(struct sockaddr_in));
zsock_connect(sock_fd, &dst_addr, sizeof(struct sockaddr_in))

Give the client another IP address with DHCP server.

Try to exchange messages with e.g. echo server.

Responses do not trigger the associated callbacks in the client, because the incoming response is not matched with the connection.

Expected behavior
Responses do trigger the associated callbacks in the client.

Impact
In UDP CoAP servers identify observing clients by endpoint (IP, SRC_PORT) and token when clients refresh their registration as an observer of a resource. For this feature it is convenient to bind the source port. If clients are managed with an DHCP server within the network, the communication won't work with the current state of the repo.

Logs and console output
N/A

Environment (please complete the following information):

• OS: Linux Ubuntu 22.04 LTS
• Zephyr SDK
• 4f802e1 or later

Additional context
The connection is via USB CDC ECM in my case.

[jukkar]

• When not binding the IP is not set. So the check is not done.
  -------> SOLUTION: instead of passing CONFIG_NET_CONFIG_MY_IPV4_ADDR:54321 to bind the port only just pass 0.0.0.0:54321

This is the culprit, when binding, you need to decide whether to bind to any address or to one specific address. If the IP address changes, and you are binding to specific address, then the packets cannot be delivered to proper socket.
So depending on use case, you should usually always bind using any address (INADDR_ANY) instead of a specific IP address.

[Aluleichtbau]

Ok, so it is indeed expected like that.

I saw the comment in net_context_bind in net_context.c stating that rebinding is not supported. Was the unregister-register sequence the workaround to that?

Maybe it was intended to do the rebinding there (if required).

[jukkar]

Don't recall anymore the reason for the unreg-reg, and it was recently removed anyway by commit 4f802e1