Bug 1443437 - Cannot send FQDN as DHCP client Host Name (Option 12)
Summary: Cannot send FQDN as DHCP client Host Name (Option 12)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.5-Alt
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-19 09:22 UTC by Renaud Métrich
Modified: 2017-08-01 09:27 UTC (History)
9 users (show)

Fixed In Version: NetworkManager-1.8.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:27:08 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2299 normal SHIPPED_LIVE Moderate: NetworkManager and libnl3 security, bug fix and enhancement update 2017-08-01 12:40:28 UTC

Description Renaud Métrich 2017-04-19 09:22:58 UTC
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.

Comment 3 Vladimir Benes 2017-04-19 09:31:16 UTC
What about setting ipv4.dhcp-fqdn instead?

Comment 4 Renaud Métrich 2017-04-19 11:33:33 UTC
ipv4.dhcp-fqdn and DHCP_HOSTNAME send the string using Option 81, not Option 12.
Seems like DHCP servers handle this differently.

Comment 5 Beniamino Galvani 2017-04-20 16:25:08 UTC
(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.

Comment 9 Beniamino Galvani 2017-04-27 16:24:24 UTC
> 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?

Comment 10 Renaud Métrich 2017-04-27 17:37:55 UTC
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.

Comment 11 Thomas Haller 2017-04-27 18:01:31 UTC
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.

Comment 12 Beniamino Galvani 2017-04-28 11:46:20 UTC
(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 ?

Comment 13 Thomas Haller 2017-04-28 16:44:20 UTC
(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

Comment 14 Francesco Giudici 2017-04-30 21:17:40 UTC
Sure, explicit DHCP_HOSTNAME should be transmitted untouched.
Branch lgtm.

Comment 17 errata-xmlrpc 2017-08-01 09:27:08 UTC
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


Note You need to log in before you can comment on or make changes to this bug.