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

[Feature Request] Support ntp-server option (or arbitrary options?) #109

Open
ScottESanDiego opened this issue Jul 12, 2020 · 3 comments
Open

Comments

@ScottESanDiego
Copy link

The current design seems like it necessitates a plugin for every potential DHCP option, which is interesting but ultimately inflexible.

My near-term need is to pass ntp-server to my DHCP clients, and it looks like the easiest path would be to take the dns plugin and make an ntp version of it, since both are trivial options providing IP addresses.

This RFE is intended to capture the lack of ntp-server option support, and raise the idea that a generic option name/number + arguments plugin would greatly extend the usability of CoreDHCP.

@Natolumin
Copy link
Member

Natolumin commented Jul 12, 2020

For DHCPv4, considering that most options share the same 4 or 5 different layouts (int, ip, ip list, strings, routes, ...) and we basically have support in the library already, a generic "arbitrary option" plugin would certainly be a good idea and save us some pain.
Implementation-wise in addition to what we have now we'd need to be able to load the same plugin multiple times, which shouldn't be too hard. Most of our plugins use global variables but refactoring them will not be difficult.

In the meantime, we'd of course accept a plugin for setting the ntp servers that is just a basic copy-paste of DNS. And we'll remove it when we make a generic option plugin for most of the known option layouts. Or we'll keep it since it's also nicer to use than having to specify option codes and types by hand

For DHCPv6 however, most option types have their own custom layout so it wouldn't be as easy.

@insomniacslk
Copy link
Member

What @Natolumin said, plus the fact that we should revisit the configuration syntax as discussed in another issue, which may make it easier to implement "generic" options at least for v4

@gaby
Copy link

gaby commented Oct 22, 2021

I'm also interested in this. My plan was to migrate to coredhcp until I noticed dhcp-options are not supported. In the meantime I'm going back to dnsmasq.

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

No branches or pull requests

4 participants