DHCP: when CONFIG_NET_APP_MY_IPV4_ADDR is IP stack needs to rebind on DHCP aquire

[mike-scott]

When testing DHCP w/ LwM2M client sample which sets CONFIG_NET_APP_MY_IPV4_ADDR="192.0.2.1" to work with QEMU by default, it was noticed that bind was happening on 192.0.2.1 and incoming packets on the DHCP address were being ignored.

We need to rebind anytime IP changes to avoid this.

[mike-scott]

Reported by @therealprof as a part of debugging #7475

[jukkar]

I could not reproduce this, or then I misunderstood the description.
I did following to test this (several terminals are needed):

Setup the qemu_x86 terminal for SLIP/TAP:

cd net-tools
./loop-socat.sh
sudo ./loop-slip-tap.sh

Terminal for DHCP server:

cd net-tools
sudo ./dnsmasq.sh

Terminal for echo-server:

cd samples/net/echo_server
cp prj.conf prj.conf.dhcpv4
echo "CONFIG_NET_DHCPV4=y" >> prj.conf.dhcpv4
mkdir build && cd build
cmake .. -DBOARD=qemu_x86 -DCONF_FILE=prj.conf.dhcpv4
make run

The zephyr instance in qemu will first set the static IPv4 address and then after a while the address will be overridden by the DHCP address. Of course if there is a request before DHCP address is received, then wrong address (the static one) is used for a short period. One option to solve this would be to wait NET_EVENT_IPV4_ADDR_ADD event and continue only after NET_ADDR_DHCP address type is set.

[therealprof]

Of course if there is a request before DHCP address is received, then wrong address (the static one) is used for a short period.

The "short period" part is not correct. If an application binds to a port before the DHCP address arrives then all packets to the new address will be dropped (and an IGMP unreachable message generated), eternally.

One option to solve this would be to wait NET_EVENT_IPV4_ADDR_ADD event and continue only after NET_ADDR_DHCP address type is set.

That doesn't solve the problem. The IP addresses may change at any time and the system needs to be able to cope with that situation.

Typically systems support binding to IP and port or just port. The former is what seems to happen at the moment and the latter is what usually should happen.

[jukkar]

Typically systems support binding to IP and port or just port. The former is what seems to happen at the moment and the latter is what usually should happen.

That sounds like a application issue (or could be in net_app) where IP address is set instead of just the port when creating the connection listener.

[jukkar]

The "short period" part is not correct. If an application binds to a port before the DHCP address arrives then all packets to the new address will be dropped (and an IGMP unreachable message generated), eternally.

That is why applications should listen IP address add/del events and act accordingly.

[mike-scott]

@jukkar I have a feeling this is net_app specific. But, I'll look through the LwM2M client code to be sure.

[mike-scott]

Adding @pfalcon to this issue.

I've traced this issue into the IP stack where we change the IP address of an existing interface where the unicast addr_type is set to: NET_ADDR_OVERRIDABLE and the incoming address type is NET_ADDR_DHCP:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/ip/net_if.c#L1965

In this case, we may have called net_conn_register() on the existing IP address and it will need to be removed / updated.

[mike-scott]

A debug of FRDM-K64F connecting to public Leshan LwM2M server: https://hastebin.com/gogicuruwi.go

Highlights from the log:

[net/app] [INF] setup_ipv4: IPv4 address: 192.0.2.1
[net/ctx] [DBG] net_context_bind: (0x20003a58): Context 0x20001c94 binding to UDP 192.0.2.1:60843 iface 0x20008380
[net/conn] [DBG] net_conn_register: (0x20003a58): [1/2/17/0x33] remote 0x20001ca4/5.39.83.206/5683 local 0x20006930/192.0.2.1/60843 cb 0x000063d1 ud 0x20000000

Above we can see the original IP address is used to setup IPv4 and registers as part of the conns[] array in connection.c

[net/app] [INF] ipv4_addr_add_handler: IPv4 address: 192.168.69.145

Now, the DHCP request is answered and a new IP is assigned to the interface, replacing the existing one because of how the addr_types OVERRIDABLE and DHCP work.

[lib/lwm2m_rd_client] [DBG] sm_send_registration: registration sent [5.39.83.206]
[net/conn] [DBG] net_conn_input: (0x20001ef0): Check UDP listener for pkt 0x200046d0 src port 5683 dst port 60843 family 2 chksum 0xa78b len 46
[net/conn] [DBG] net_conn_input: (0x20001ef0): No match found.

The responding Leshan server is rejected because the old IP 192.0.2.1 is still in the conns[] array, not the new IP.

This is most definitely an event that should be handled in the IP stack and not by each sample.