Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
NetworkManager
NetworkManager
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 143
    • Issues 143
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 10
    • Merge Requests 10
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • NetworkManager
  • NetworkManagerNetworkManager
  • Issues
  • #572

Closed
Open
Opened Nov 05, 2020 by Luca Bruno@lucab

dhcp: gracefully handle overlong host name values (option 12)

This is a bug report for a problematic hostname-from-DHCP scenario, and a RFE for implementing additional logic to gracefully handle it.

DHCP option 12 ("Host Name Option" defined in RFC 2132) allows a DHCP server to specify the name for a client, either as a local-label or a Fully Qualified Domain Name (FQDN). Both approaches have been encountered in the wild, e.g. with dnsmasq always passing a local-label and Google Cloud (GCP) infrastructure always passing the FQDN.

In the second case there is subset of scenarios which are currently causing NM logic to fail. The Linux kernel allows hostnames up to HOST_MAX_LEN (64 characters), but a FQDN received through DHCP can be longer than that. NM will try to pass the overlong name to lower levels, and it will be rejected by the kernel.

Taking this-is-a-really-long-63-chars-label-which-is-nonetheless-valid.example.com as a simplified example, this is how a recent NM fails (1.26.2 from F33, full service logs attached):

Nov 05 16:23:27 fedora NetworkManager[958]: <info>  [1604593407.9249] dhcp4 (ens2): activation: beginning transaction (timeout in 45 seconds)
[...]
Nov 05 16:23:30 fedora NetworkManager[958]: <info>  [1604593410.9377] dhcp4 (ens2): option host_name            => 'this-is-a-really-long-63-chars-label-which-is-nonetheless-valid.foo.example.com'
[...]
Nov 05 16:23:30 fedora NetworkManager[958]: <info>  [1604593410.9550] policy: set-hostname: set hostname to 'this-is-a-really-long-63-chars-label-which-is-nonetheless-valid.foo.example.com' (from DHCPv4)
[...]
Nov 05 16:23:30 fedora NetworkManager[958]: <warn>  [1604593410.9819] hostname: couldn't set the system hostname to 'this-is-a-really-long-63-chars-label-which-is-nonetheless-valid.foo.example.com' using hostnamed: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Invalid hostname 'this-is-a-really-long-63-chars-label-which-is-nonetheless-valid.foo.example.com'
Nov 05 16:23:30 fedora NetworkManager[958]: <warn>  [1604593410.9822] policy: set-hostname: couldn't set the system hostname to 'this-is-a-really-long-63-chars-label-which-is-nonetheless-valid.foo.example.com': (1) Operation not permitted
Nov 05 16:23:30 fedora NetworkManager[958]: <warn>  [1604593410.9823] policy: set-hostname: you should use hostnamed when systemd hardening is in effect!

As a NM user, it would be good to have logic in place to gracefully handle overlong hostnames received via DHCP option 12, so that NM stack can be reliably used on infrastructures where FQDN node names are used (e.g. Google cloud).

Thus, this is a gentle request to update NM logic to check if the hostname option received via DHCP is too long for Linux kernel limit, and in case shorten it. An overlong hostname should be truncated to the first dot or to HOST_MAX_LEN, whatever comes earlier.

For reference, when encountering a similar bug previously on systemd-networkd side, the same logic has been implemented at https://github.com/systemd/systemd/pull/7616 to gracefully handle those problematic cases.

NetworkManager.dhcp-opt12.log

Edited Nov 11, 2020 by Luca Bruno
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: NetworkManager/NetworkManager#572