Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

perkelix
Copy link
Contributor

@perkelix perkelix commented Feb 2, 2025

dhcpcd routinely fails to obtain an IP with a timeout if the DHCP server doesn't receive the "hostname" option. Let's uncomment it.

dhcpcd routinely fails to obtain an IP with a timeout if the DHCP server doesn't receive the "hostname" option. Let's uncomment it.
@ColinMcInnes
Copy link
Contributor

What software is on the server? Is this a bug with the server software?

@perkelix
Copy link
Contributor Author

perkelix commented Feb 3, 2025

It might be server-specific.

@ColinMcInnes
Copy link
Contributor

It might be server-specific.

Could also be config specific. It might be expecting a specific hostname to hand out an IP.

@perkelix
Copy link
Contributor Author

perkelix commented Feb 3, 2025

@ColinMcInnes
Copy link
Contributor

ColinMcInnes commented Feb 3, 2025

This only sets IPv4 and IPv6, no specific hostname:

https://salsa.debian.org/debian/dhcpcd/-/blob/debian/sid/debian/tests/timesyncd-ntp-servers-from-dhcp?ref_type=heads

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?

@perkelix
Copy link
Contributor Author

perkelix commented Feb 3, 2025

Look carefully. This sets up dnsmasq to be able to test that dhcpcd correctly receives IP addresses and NTP server info.

@perkelix
Copy link
Contributor Author

perkelix commented Feb 3, 2025

Here's an example of such a timeout:
https://ci.debian.net/packages/d/dhcpcd/testing/amd64/57448052/

@ColinMcInnes
Copy link
Contributor

ColinMcInnes commented Feb 3, 2025

Look carefully. This sets up dnsmasq to be able to test that dhcpcd correctly receives IP addresses and NTP server info.

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?

@perkelix
Copy link
Contributor Author

perkelix commented Feb 3, 2025

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.

@ColinMcInnes
Copy link
Contributor

The server config is generated within this script.

What is the server, what version?

We're working with a black box here.

Debian's release team considers this a CI issues since the test produces inconsistent results with the exact same config.

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?

@perkelix
Copy link
Contributor Author

perkelix commented Feb 3, 2025

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.

@ColinMcInnes
Copy link
Contributor

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?

@perkelix
Copy link
Contributor Author

perkelix commented Feb 3, 2025

DHCP service is provided by the dnsmasq configured in that CI testing script.

@ColinMcInnes
Copy link
Contributor

I guess a better question might be what is different between dhcpcd 10.1.0 and Debian dhcpcd 1:10.1.0-4?

@DanielG
Copy link
Contributor

DanielG commented Feb 3, 2025 via email

@ColinMcInnes
Copy link
Contributor

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 :-)

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.

@rsmarples
Copy link
Member

dhcpcd routinely fails to obtain an IP with a timeout if the DHCP server doesn't receive the "hostname" option. Let's uncomment it.

https://www.rfc-editor.org/rfc/rfc7844.html#section-3.7

When using the anonymity profile, DHCP clients SHOULD NOT send the Host Name option.

So as @ColinMcInnes said, this is a server side requirement that dhcpcd cannot know.
If your CI demands it, then dhcpcd should be configured on the CI to send it.
Neither situation is an out of the box config - I don't know of a single DHCP server that requires it out of the box.

@ColinMcInnes
Copy link
Contributor

@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?

@perkelix
Copy link
Contributor Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants