Make sure we cleanup only those DNS servers that belong to
certain network interface when the interface goes down.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Bind the network interface to the network interface we
have received the DNS servers from. This is now the default.
The previous behavior can be restored by disabling the
CONFIG_NET_DHCPV4_DNS_SERVER_VIA_INTERFACE option.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Use connection manager to deactivate and activate
net log backend.
This removes the warnings about dropped packages
completly.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Avoid early enabling of the syslog backend in
the the dhcpv4 options parser.
When CONFIG_NET_IPV4_ACD is enabled, the assigned ip address has
not been checked, when the other dhcpv4 options are parsed, this would
lead to the syslog backend being enabled before the src ip address
is valid, so we get lots of warnings about dropd packets, this fixes
it at least on start. We will still get the warnings, when the iface
goes down and then up later.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
According to RFC 2131, DHCP clients should use the same xid as
received in the Offer message when sending DHCP Requests. Therefore,
when generating DHCP Request message, the xid value should not be
incremented.
One vague topic is whether the xid value should be updated when
sending Requests from Renewing or Rebinding states, however RFC makes no
exception for those states, and other implementations (dhclient, lwip)
seem to reuse the same xid in such cases, so comply with this behavior.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Pad option (option code 0) can be present in between other options for
alignment. The option has a fixed 1-byte length (i. e. no length field),
therefore it did not fall under the common processing code for
unrecognized options (which include the length field at the second
byte). Therefore, not processing this option explicitly could disturb
other options processing, as the parser would wrongly interpret the next
option code as the length field. This commit adds Pad option handling to
fix the issue.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case the received DHCP message is malformed and contains invalid
message type, the code responsible for matching message type with a
string would assert. This shouldn't be the case that external conditions
(like receiving malformed packet) trigger asserts in the system.
Therefore modify that code, to return "invalid" string in such case
instead.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Currently we ignore the received domain name but make sure we
print it in order to avoid unknown option prints.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Currently we ignore the received host name but make sure we
print it in order to avoid unknown option prints.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Currently we ignore the broadcast address but make sure we
print it in order to avoid unknown option prints.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
There is a deadlock issue when calling stop using address conflict
detection. This is due to the fact that some net_mgmt events are fired
and trigger the dhcpv4_acd_event_handler() with lock held even if they
are of no interest for this callback.
Therefore, before acquiring the lock, make sure the event we received
is one we are expecting.
Also, do the same for dhcpv4_iface_event_handler().
Signed-off-by: Mathieu Anquetin <mathieu.anquetin@groupe-cahors.com>
There's nothing in RFC 2131 or RFC 8415 that would mandate the DHCP
server to reply with a source port set to the IANA assigned one, and
some servers seem to send responses with some arbitrary source port set.
Therefore, make Zephyr's DHCP client implementation more permissive,
accepting packets with a source port set to a different port than the
IANA assigned server port.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Check if NET_DHCPV4_SERVER_OPTION_DNS_ADDRESS is set before using it to
set the DNS option in DHCP responses. This avoids sending a client a DNS
server of 0.0.0.0.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add a Kconfig option to skip the router DHCP server option. This can be
useful to avoid having the client trying to forward all its traffic to
the embedded device.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The DHCPv4 options always assigns the DNS address if the router
provides one through the DHCP callback. There are times a developer
may not always want to assign the server from the router, but only
manually assign them. Adding a Kconfig option for assigning the DNS
address and defaulting to true to not interfere with previously
expected functionality.
Signed-off-by: Kris Wolff <kwolff@wavelynx.com>
Allocate one extra pointer for the DNS server list so that
DNS resolving code can detect the end of the list.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
remove k_work related code and change
the argument of the callback to `struct net_socket_service_event`.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Remove the `work_q` parameter from `NET_SOCKET_SERVICE_SYNC_DEFINE` and
`NET_SOCKET_SERVICE_SYNC_DEFINE_STATIC` as this feature was dropped
during review but the removal was not 100% complete.
Signed-off-by: Jordan Yates <jordan@embeint.com>
For code clarity, this commit adjusts the use of `return` statements
in functions with a void return type as follows:
- Transform `return foo();` into separate statements:
`foo();`
`return;`
- Remove unnecessary `return` statements when
they don't affect control flow.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
As the allocation is run in system workqueue context, it can
cause problems if waiting forever when allocating net_pkt.
Fixes#77935
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
dhcv4 server was not providing the dns server details to the
client because dns option was handled. Added the dns server
option to be send to the client as response form dhcpv4 server
Signed-off-by: Muhammad Haziq <muhammad.haziq@zintechnologies.com>
If we receive multiple DNS servers via DHCP only the first one is used,
regardless of CONFIG_DNS_RESOLVER_MAX_SERVERS constant.
Parse DHCP option and save addresses that fit
Signed-off-by: Andrey Dodonov <Andrey.Dodonov@endress.com>
When running dhcp, it was not assigning gateway/router
address to the client devices. It is fixed in this PR.
Signed-off-by: Muhammad Munir <muhammad.munir@zintechnologies.com>
Utilize a code spell-checking tool to scan for and correct spelling errors
in all files within the `subsys/net/lib` directory.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
For station and internal AP coexist case, station connected to
external AP, ping from station to external AP cause cpu hang.
Internal AP dhcpv4 server register handler echo_reply_handler
on icmp handler by net_icmp_init_ctx for dhcp server snoop
feature. Ping also register handler handle_ipv4_echo_reply on
icmp handler for ping cmd. If no external station connect to
internal AP, input parameter ‘user_data’ of function
echo_reply_handler is NULL. When we trigger ping process,
icmp_call_handlers fetch all handlers from icmp handler
if receive any ICMP packet, so echo_reply_handler be called,
but input parameter is NULL, cause CPU hang.
Add input parameters check to fix this issue.
Signed-off-by: Rex Chen <rex.chen_1@nxp.com>
In case no Renewal/Rebinding times have been provided the server via
DHCP options, we should reset their values on ACK, so that the client
can recalculate the defaults. This is important, as the lease time may
change, so we should recalculate default T1/T2 timeout based on the new
lease time value.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
DHCP Request retransmission in RENEW and REBIND states was not
compliant with RFC2131.
The retransmission interval should not be calculated as in REQUESTING
state in such case, but rather calculated based on the remaining T2
or lease time (depending on current state).
RFC doesn't also mention any retransmission count limit for those
states. The client should retransmit the REQUEST until T2 or lease
expiry time are reached.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case a conflict was detected on a DHCP-assigned address, send a
Decline message to the server and start over.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When the interface goes down, the safest thing to do is to return to
the INIT state, as there is no guarantee that any state is preserved
upon the interface coming back up again.
This is particularly the case with WiFi.
Signed-off-by: Jordan Yates <jordan@embeint.com>
errno values are positive, therefore they should be negated when
assigned as return values for net_dhcpv4_server_start().
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Zephyr's DHCPv4 server does not implement persistent storage of address
leases. In result, all leases are lost on reboot, which can cause
delays with clients starting in INIT-REBOOT state and thus sending
(potentially several) Requests before attempting full Discover-Request
procedure.
Add option to override RFC defined behavior, which states that if we
don't recognize the client sending the Request, the server shall remain
silent. Enabling that option allows the server to send NAK reply in case
client is not recognized, informing the client it should proceed with
full procedure.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
RFC6842 updated RFC2131 in terms of including client ID option in
responses sent from the server. According to that RFC, the server MUST
include the client ID option in Offer/Ack/Nak replies, if it was
provided by the client.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case ACK from the server was lost, we'd not reply Request
retransmissions, as the lease state is already in allocated state on the
server side. Therefore we also need to allow to reply with ACK in such
case.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
5 seconds turned out to be too short timeout in case retransmissions
kicked in at DHCP level, hence increase the timeout.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When we receive the subnet mask option from the server, we
cannot yet set the netmask to the network interface as the
mask is tied to the IP address we received from the server.
We need to delay the setting of netmask until we have added
the requested IP address to the interface.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
In certain scenarios, it may be necessary to get values of additional
options from the application layer. With this patch, this can be
accomplished by registering a callback with the DHCP client.
This change has been tested using the posix build in qemu.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
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>
Check the value of net_dhcpv4_add_option_callback()
and net_dhcpv4_remove_option_callback() explicitly.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Apply ranges to DHCPv4 server timeout Kconfig options, so that it cannot
be set to a negative value by mistake.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case conflict is detected (either due to receiving Decline message or
due to ICMP probe getting reply), the conflicting address becomes
blocked for further use.
Although the RFC is not specific about how long should the address be
blocked, it make sense to implement some fallback mechanisms to reuse
blocked addresses in the server, otherwise, after longer period of
operation, it may run out of usable address.
This commit adds a timeout for declined addresses, so that by default
the address is marked back as "free" after 24 hrs (default lease time).
It also implements a mechanism, which allows to re-use the oldest
declined entry in case the server runs out of fresh addresses to assign.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
