Bug 1443437
| Summary: | Cannot send FQDN as DHCP client Host Name (Option 12) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> |
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.5-Alt | CC: | atragler, bgalvani, fgiudici, lrintel, rkhan, rmetrich, sukulkar, thaller, vbenes |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | NetworkManager-1.8.0-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 09:27:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
What about setting ipv4.dhcp-fqdn instead? ipv4.dhcp-fqdn and DHCP_HOSTNAME send the string using Option 81, not Option 12. Seems like DHCP servers handle this differently. (In reply to Renaud Métrich from comment #4) > ipv4.dhcp-fqdn and DHCP_HOSTNAME send the string using Option 81, not Option > 12. > Seems like DHCP servers handle this differently. The domain part was removed from the DHCP hostname option back in 2011 to fix bug 694758. Recently, in bug 1255507 we added support for the FQDN option to allow the full domain name to be sent. Even if this is a different option, I think that DHCP servers accept (and can update DDNS with) both. Did you try using the DHCP_FQDN variable with NM? We could modify NM to send the full domain in the hostname option, but that would be a big change in behavior with the potential of breaking many users; so before we start to look into adding new configuration options to NM, please confirm that setting the DHCP_FQDN variable does not work. > The default behaviour should not be changed, but if
> NetworkManager encounters a FQDN, it should send it as-is.
Yeah, if DHCP_HOSTNAME is not set, we should keep sending only the
host part of the system hostname, to maintain backwards compatibility.
Instead, when an explicit value is set probably we should send it as
is because the user knows better what to do. However this would be
change in behavior for those who have a DHCP_HOSTNAME=FQDN set in
ifcfg files.
Alternatively, we could introduce a prefix (for example '!') that,
when used before the hostname value, tells NM to use the full value
instead of truncating it.
Any opinions?
I think the DHCP_HOSTNAME should be compatible when using NetworkManager or legacy networking (ifup), hence transmit string as is. I don't think many users set FQDN as hostname and think only the hostname part will be sent. Whether users were aware of that is not really important. Important is that on upgrade the behavior will change. I think now we should fix behavior, because it seems to be just a bug. But clearly document it in the release-notes. (In reply to Thomas Haller from comment #11) > Whether users were aware of that is not really important. Important is that > on upgrade the behavior will change. > > I think now we should fix behavior, because it seems to be just a bug. But > clearly document it in the release-notes. I tend to agree. How about branch bg/dhcp-full-hostname-rh1443437 ? (In reply to Beniamino Galvani from comment #12) > (In reply to Thomas Haller from comment #11) > > Whether users were aware of that is not really important. Important is that > > on upgrade the behavior will change. > > > > I think now we should fix behavior, because it seems to be just a bug. But > > clearly document it in the release-notes. > > I tend to agree. How about branch bg/dhcp-full-hostname-rh1443437 ? lgtm Sure, explicit DHCP_HOSTNAME should be transmitted untouched. Branch lgtm. Merged to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=31e063fcb24cff2cda16dc95a69f990d98b5e285 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2299 |
Description of problem: When specifying a FQDN with the DHCP_HOSTNAME variable in ifcfg-xxx file or using nmcli (ipv4.dhcp-hostname), only the hostname part is sent as DHCP Option 12. Version-Release number of selected component (if applicable): NetworkManager-1.4.0-19.el7_3.x86_64 How reproducible: ALWAYS Steps to Reproduce: 1. Set DHCP_HOSTNAME="rhel73.example.com" in ifcfg-eth0 2. Capture DHCP traffic: "tcpdump -i eth0 port 67 -V -x" 3. Restart NetworkManager: "systemctl restart NetworkManager" Actual results: DHCP capture shows the following Option: (12) Host Name Length: 6 Host Name: rhel73 Expected results: Option: (12) Host Name Length: 18 Host Name: rhel73.example.com Additional info: BZ #1255507 enables to specify the FQDN using DHCP_FQDN, but this has not the same effect since this translates into Option 81 as shown below and not Option 12: Option: (81) Client Fully Qualified Domain Name Length: 23 Flags: 0x05 0000 .... = Reserved flags: 0x00 .... 0... = Server DDNS: Some server updates .... .1.. = Encoding: Binary encoding .... ..0. = Server overrides: No override .... ...1 = Server: Server A-RR result: 0 PTR-RR result: 0 Client name: rhel73.example.com RFC 2132 (https://tools.ietf.org/html/rfc2132#section-3.14) clearly states that "The name may or may not be qualified with the local domain name", so FQDN should be accepted.