Upstream development for prpl Foundation (asynchronous DHCPv6 handling, ubus backend, statistics, reconfiguration, ...) #96
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When the DHCPv6 client sends a DHCPv6 Solicit with both IA_NA and IA_PD options, and if the server replies with a status code = NoAddrsAvailable in the IA_NA option, then currently the DHCPv6 client sends a new Solicit with only the IA_PD option despite the fact that a prefix was sent by the server in the previous Advertise. This behavior is described in https://datatracker.ietf.org/doc/html/rfc7550#section-4.2 The client must handle the case of a server that does not offer both valid IA_NA and IA_PD options when both are requested, according to RFC 7550. It should not send a new Solicit, but a Request. The client should however ignore the Advertise message if none of the IA_NA and IA_PD options are offered by the server. Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: odhcp6c doesn't support change of DSCP value. Solution: Adapt odhcp6c to set socket option to change the DSCP value for dhcpv6 packets. Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: there was no way to get access to the t1 and t2 that the dhcpv6 server send to the client Solution: add the timing in the Prefix and Address set on the env Signed-off-by: Nicolas BESNARD <[email protected]>
Problem:
The current implementation of the dhcp_request function handles both sending
and receiving messages within the same function. This makes the function blocking,
as it waits for a valid response before proceeding, causing potential delays
Solution:
The dhcp_request function will be refactored into two functions:
one for sending DHCP messages and another for receiving them.
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem:
The DHCPv6 socket is currently set to blocking mode, which causes the program to
pause execution whenever it attempts to read from the socket. This can lead to
delays and hinder the overall responsiveness of the application.
Solution:
Add the set_nonblocking() function, using fcntl() to set the O_NONBLOCK flag,
allowing the socket to operate in non-blocking mode.
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem:
The DHCPv6 states were previously handled synchronously, meaning that while waiting
for a response from the server, no other actions could be performed in odhcp6c.
The process would block inside a loop until a valid response was received,
limiting responsiveness and overall system performance
Solution:
The new approach involves sending the requests and then asynchronously monitoring
the DHCPv6 socket using poll(). By only reading a response when there is data available
on the socket, the system remains non-blocking.
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem:
odhcp6c is not connected to UBus making communication with other process more difficult.
Solution:
Connect odhcp6c to UBus backend when HAVE_UBUS build time configuration option is set.
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem:
Whenever the DHCPv6 state changes a custom shell script provided in argument on process start is called.
Solution:
In addition to the current script mechanism, emit UBus event whenever the DHCPv6 state changes.
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem:
odhcp6c states data are transmitted when the DHCPv6 state changes.
If a process subscribe after the start of odhcp6c, then it has to wait for the next update event.
Solution:
Add a new UBus method "get_state" to get the latest states data immediately.
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem:
odhcp6c does not provide any statistics.
Solution:
Count the number of packets transmitted or received by message type.
Add a UBus RPC method to get those informations.
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: To update DHCP parameters/options, the process needed to be restarted with the new arguments. It makes odhcp6c not really flexible, making for example impossible to keep track of the total packets statistics. Solution: Add a new ubus method to reconfigure DHCP without restarting the process. Signed-off-by: Nicolas BESNARD <[email protected]>
…est comes Problem: When reply to an information request is received, it does not update the server information. Solution: Add server information when information request is received. Signed-off-by: Nicolas BESNARD <[email protected]>
Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: odhcp6c call user defined script (or /usr/sbin/odhcp6c-update on default) on every state update. When using ubus event, this feature is not needed. Solution: add a new argument option to disable script call on state update Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: odhcp6c uses static retransmission parameters defined in RFC3315. Solution: Make retransmission parameters configurable via ubus and update the default value based on RFC8815. Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: Renew/Information-Request or Release messages are sent when odhcp6c receive signal SIGUSR1 or SIGUSR2. It should be possible to also trigger thoses messages via a ubus methods. Solution: Implement two new ubus methods : release() and renew(). Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: If Advertise with status 'noaddravail' is received while IA_NA is requested, a new Solicit is sent creating an infinite loop. Solution: Set IA_NA mode to none and send INFO-REQ message if no IA_NA or IA_PD are available. Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: odhcp6c doesn't support authentication protocol other than Reconfiguration Key Authentication Protocol (RKAP). Solution: implement Configuration Token protocol and add option to disable all authentication protocols (will discard all reconfigure messages received). Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: odhcp6c exits when no reply is received from the server after retransmission of Renew/Rebind messages Solution: restart the state machine instead of exiting on retransmission failure Signed-off-by: Nicolas BESNARD <[email protected]>
Problem: The -E option disables the state script and relies only on ubus to emit event on state changes. But if odhcp6c is compiled without ubus support (ENABLE_UBUS flag omitted), odhcp6c has now way to signal state changes. Solution: Return an error when -E flag is used and ubus support is disabled. Signed-off-by: Nicolas BESNARD <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The following features have been added :
ENABLE_UBUS