The netmask should be tied to the IPv4 address instead of being
global for the network interface.
If there is only one IPv4 address specified to the network interface,
nothing changes from user point of view. But if there are more than
one IPv4 address / network interface, the netmask must be specified
to each address separately.
This means that net_if_ipv4_get_netmask() and net_if_ipv4_set_netmask()
functions should not be used as they only work reliably if there is
only one IPv4 address in the network interface.
The new net_if_ipv4_get_netmask_by_addr() and
net_if_ipv4_set_netmask_by_addr() functions should be used as they make
sure that the netmask is tied to correct IPv4 address in the network
interface.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
As the common.h is only meant to be used by the network
shell files, rename it to be more descriptive in order to
avoid possible conflicts with any other common.h file.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Fix two issues with net tcp command:
* The `net tcp` commands are still based on net_context API. For TCP,
the API caller (net shell) should add one extra reference to the
allocated net context, to prevent premature context release in case of
connection teardown. Currently that was not the case, and the context
was released too early, resulting in missing final ACK from the Zephyr
side on connection close.
* The net context API should not be called from the registered connect
callback, as this creates a temporary deadlock situation. The
net_context_connect() function blocks until the connection is
established, or an error or timeout occurs. For that time the
net_context mutex is being locked. In case of connection error (for
example after receiving RST packet) the connect callback is called,
indicating an error. If we try to call net_context API from within, a
deadlock situation takes place, as the context mutex is still locked
by the net_context_connect() (called from the shell thread). This
blocks the further execution of the TCP stack and can result in an
unexpected behavior (like for example retransmitting the SYN packet,
which takes place from yet another thread, TCP work queue).
Fix this, by releasing the net context not from the callback directly,
but based on the return value from net_context_connect().
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
