Clarify the reason perfdhcp -4 defaults to port 67.
#126
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
PROBLEM ======= I spent several hours trying to figure out why `perfdhcp -L 68` was resulting in a 100% rate of drops and strange Kea log messages. My configuration is probably pretty normal; perfdhcp running on the same server as kea-dhcp4. First perfdhcp would not run because it could not bind the socket to port 67 (which I thought it wouldn't need to anyway). Specifying `-L 68` gets over this hurdle, but then Kea logs messages about receiving DHCPOFFERs on its socket, and `perfdhcp` never recieves the responses. It turns out Kea is replying to port 67 because `giaddr` is set, and that winds up sending the response packet (DHCPOFFER) to itself. SOLUTION ======== I think a broader solution to this problem would be to add support for a v4 client. This is complicated by the strange mechanics of DHCPv4 client packets in INIT and INIT-REBOOT states; generally requiring raw sockets. That's a pretty heavy lift. A milder solution might be to simulate clients in RENEWING state by default, then at least normal BSD sockets may be used but the command line interface would require lease address(es). It still feels awkward to implement. For now I figure we can at least remove the `@todo` questioning this, provide a warning to users that specify any port other than 67 for `-4` mode, and update the manpage.
Also, I think the second comment is redundant.
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.
PROBLEM
I spent several hours trying to figure out why
perfdhcp -L 68was resulting in a 100% rate of drops and strange Kea log messages. My configuration is probably pretty normal; perfdhcp running on the same server as kea-dhcp4. First perfdhcp would not run because it could not bind the socket to port 67 (which I thought it wouldn't need to anyway). Specifying-L 68gets over this hurdle, but then Kea logs messages about receiving DHCPOFFERs on its socket, andperfdhcpnever recieves the responses.It turns out Kea is replying to port 67 because
giaddris set, and that winds up sending the response packet (DHCPOFFER) to itself.SOLUTION
I think a broader solution to this problem would be to add support for a v4 client. This is complicated by the strange mechanics of DHCPv4 client packets in INIT and INIT-REBOOT states; generally requiring raw sockets. That's a pretty heavy lift. A milder solution might be to simulate clients in RENEWING state by default, then at least normal BSD sockets may be used but the command line interface would require lease address(es). It still feels awkward to implement.
For now I figure we can at least remove the
@todoquestioning this, provide a warning to users that specify any port other than 67 for-4mode, and update the manpage.