Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the reason perfdhcp -4 defaults to port 67. #126

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

davidhankins
Copy link

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.

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant