Right now AT+CIPSTART command is called with both "remote port" and "local
port" being set to the same number. This means that for outgoing UDP
traffic (e.g. when resolving DNS or when reaching out some application
server with CoAP over UDP) always the same outgoing port is used. Such
behavior is wrong, since by default a random outgoing port should be used.
Reusing the same port confuses server implementation that is reached out,
since especially in context of DTLS over UDP, outgoing port defines TLS
context/session to be used. Such servers often ignore TLS packets from new
sessions (e.g. after device reboot) and result in failed DTLS connection
attempts.
Commit dbf3d6e911 ("drivers: esp_at: implement bind() and recvfrom() for
UDP sockets") added support for "server-side listening" for incoming
traffic on UDP sockets, which introduced broken behavior of using the same
remote and local port.
In esp_bind() implementation assign newly intorduced 'src' member, instead
of reusing 'dst'. Don't call AT+CIPSTART yet at this stage, as in case of
connect() Zephyr syscall esp_bind() (via bind_default() helper function) is
called implicitly to assign random generated local port, so remote port is
yet to be assigned. Check in esp_recv() whether socket was already
connected (i.e. esp_connect() was called) and if not, invoke
AT+CIPSTART (via _sock_connect()) to start listening on "server-side" UDP
socket.
This patch fixes broken behavior of always reusing the same local port for
outgoing UDP traffic. Instead, randomly generated (by Zephyr net_context
subsys) local port is used. Additionally bind() and recvfrom()
implementation (to handle server-side UDP sockets) is improved, so that
binding to 0.0.0.0 (on any interface) is possible.
Fixes: dbf3d6e911 ("drivers: esp_at: implement bind() and recvfrom() for
UDP sockets")
Fixes: 424ea9f5e4 ("drivers: wifi: esp_at: do not connect socket on
bind(INADDR_ANY)")
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
c368c332c4