-
Notifications
You must be signed in to change notification settings - Fork 129
Uncomment 'hostname' in dhcpcd.conf #451
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
base: master
Are you sure you want to change the base?
Conversation
dhcpcd routinely fails to obtain an IP with a timeout if the DHCP server doesn't receive the "hostname" option. Let's uncomment it.
What software is on the server? Is this a bug with the server software? |
It might be server-specific. |
Could also be config specific. It might be expecting a specific hostname to hand out an IP. |
This only sets IPv4 and IPv6, no specific hostname: |
Unless I've missed something, that looks like a script that crafts a dhcpcd config. I don't see the dhcp server config or logs. What does the dhcpd config look like? Are there dhcpd logs available? |
Look carefully. This sets up dnsmasq to be able to test that dhcpcd correctly receives IP addresses and NTP server info. |
Here's an example of such a timeout: |
A response is not the server config though. We know what is being sent, and what is coming back, but we do not know what the server is configured to send back. What is the server, what version, and what config is it using? That might be important. There is nothing in the DHCP RFCs that indicated the hostname should be required, so I'm unclear why the dhcp server is caring. I note that the tests passed a few weeks ago. What changes have gone in to Debian release since then? |
The server config is generated within this script. Everything else uses dnsmasq defaults. The test randomly fails with a timeout at the exact spot shown there, every now and then. Debian's release team considers this a CI issues since the test produces inconsistent results with the exact same config. The issue was first noticed at Ubuntu, which has a lot stricted CI testing. |
What is the server, what version? We're working with a black box here.
I agree it's a CI issue, I'm just not clear which end of the system is at fault here. Is dhcpcd causing the server to hiccup, or is the server hiccuping when dhcpcd does not ask for hostname? According to the RFCs, dhcpcd should be right, hostname has nothing to do with a lease. So what is the disconnect here? What is the server expecting that dhcpcd is breaking within the rules of DHCP? What version of dhcp server is Debian testing against, with what dhcp server config? |
Both dhcpcd and dnsmasq versions keep on evolving since CI takes place against Testing and Unstable releases. I've asked the dnsmasq maintainers (one of which happens to be upstream) for advice. I have yet to get an answer. |
dnsmasq is a client service... what is the dhcp server the CI test is using? |
DHCP service is provided by the dnsmasq configured in that CI testing script. |
I guess a better question might be what is different between dhcpcd 10.1.0 and Debian dhcpcd 1:10.1.0-4? |
On Sun, Feb 02, 2025 at 11:23:45PM -0800, Colin McInnes wrote:
dnsmasq is a client service... what is the dhcp server the CI test is using?
Colin, dnsmasq is a widely deployed fully integrated DHCP server and DNS
resolver (among other things). Popular for example on embedded devices
(CPEs) and in hypervisors such as libvirt, lxc, incus. See also `apt-cache
rdepends dnsmasq-base` and https://thekelleys.org.uk/dnsmasq/doc.html for
more reading material.
You may be thinking of the NetworkManager client integration with dnsmasq
where, indeed, it's used only for it's resolver function. That's not all it
can do :-)
…--Daniel
|
TIL, thank you for the explanation. Still, my question stands, why does dnsmasq require hostname, and how long has this been a thing? Did dhcpcd stop working with dnsmasq recently? Hopefully dnsmasq maintainers can explain why it worked before but didn't now, and why they're requiring a non-required field to be populated. I can see them really wanting it, since it's needed for DDNS, but it's not part of the DHCPv4 or v6 spec to require it. So they ideally should be responding to the Discovery with an error message of some kind, same as when there are no IP addresses available in a pool. |
https://www.rfc-editor.org/rfc/rfc7844.html#section-3.7
So as @ColinMcInnes said, this is a server side requirement that dhcpcd cannot know. |
@perkelix Have you heard anything back from dnsmasq maintainers? Is this something they could recommend be added in a dhcpcd.conf specific to their CI test, since they're asking for something that is not requried by the DHCP specification? |
I haven't heard back. Anyhow, as Debian seems adamant on this being uncommented, I build the package with a simple patch that removes the hash in front of the option. It's a minimal enough change to the stock config that I can live with that. |
dhcpcd routinely fails to obtain an IP with a timeout if the DHCP server doesn't receive the "hostname" option. Let's uncomment it.