tl;dr: Tails is affected by this issue, and for us it's a regression (compared to 0.9.10) that breaks an important feature of our operating system.


In NetworkManager 0.9.10.0 (Debian Jessie), in Tails we had:

[ipv4]
dhcp-send-hostname=false

in /etc/NetworkManager/conf.d/dhcp-hostname.conf.

This disabled ipv4.dhcp-send-hostname globally, which is exactly what we need. I don't know if this was meant as a feature or if it was just by chance, but it worked for us.


However, with NetworkManager 1.2.4 (Debian Stretch) I could find no way to achieve the same effect: we want to ensure that all connections (e.g. Wi-Fi ones that the user may configure themselves) will have dhcp-send-hostname disabled by default.


It seems that the right user interface, in current NetworkManager, would be to support:

[connection]
ipv4.dhcp-send-hostname=false

... in some global NetworkManager configuration file. Right?


May I assume that commit 10b22228 is a good source of inspiration wrt. adding support for a property in such [connection] global defaults?

(I would like to try and find someone at ease with C to fix this regression, so let's make sure we agree on the exact goal first.)

Of course, if the result we need can be achieved without modifying NetworkManager, I'm all ears :)

As you are probable aware, NM has a per-connection setting "ipv4.dhcp-send-hostname" to control this. You are now asking for a global configuration override/default.

This is currently not possible, but should be.




To elaborate on how default-values work:


For some properties, NetworkManager supports specifying global default values in NetworkManager.conf (see `man NetworkManager.conf`).
These global default values allow to overwrite an existing property of a connection. But that doesn't work for all properties because for some it doesn't make sense (obvious example: connection.id) or for older properties which predate this mechanism it wasn't implemented. See the manual which properties support this.

In order for a default-value to be used, the per-connection value must be set explicitly to a default/unspecified/unknown/NULL value that is documented to allow fallback to the default.
Optimally, a newly created connection is initialized by the UI to set those properties as default (by default).

As ipv4.dhcp-send-hostname predates this mechanism, it currently only has the values "yes|no". Thus it is cumbersome to extend this property with a new value "default" without changing existing configurations and without breaking existing behavior. It's doable though.



It this would be supported (which it currently is not), you would install a file like "/usr/lib/NetworkManager/conf.d/10-tails-dhcp-send-hostname.conf":

  [connection-tails-dhcp-send-hostname]
  ipv4.dhcp-send-hostname=0
  ipv6.dhcp-send-hostname=0

with recent NM, distributions should put their configuration snippets to "/usr/lib/NetworkManager/conf.d".
This allows the user to overwrite particular settings later, for example he could have a file "/usr/etc/NetworkManager/conf.d/99-my-overwrite-for-eth0.conf" with

  [connection-something-arbitrary-suffix]
  device-match=interface-name:eth0
  ipv4.dhcp-send-hostname=1

(In reply to intrigeri from comment #1)

> (I would like to try and find someone at ease with C to fix this regression,
> so let's make sure we agree on the exact goal first.)

why is this a regression? AFAIK, upstream never supported a global configuration option 
  [ipv4]
  dhcp-send-hostname=false
did it? Seems like a downstream modification to me. Do you have a link to those patches?

(In reply to Thomas Haller from comment #3)
> why is this a regression?

I think you're absolutely right: from an upstream developer's perspective, this is no regression since the previous behaviour was not intended and therefore not supported. I do want to acknowledge this: as I wrote earlier, "I don't know if this was meant as a feature or if it was just by chance, but it worked for us" :)

Now, please understand that from _my_ perspective, this behaviour change is definitely a regression: something that Tails needs (not sending hostname in DHCP requests) used to work just fine, and now the only way to get the desired behaviour back is to patch NetworkManager.

(FWIW I looked a bit closer, and none of the patches applied in Debian Jessie on top of NM 0.9.10.0 contain the word "hostname" nor "host-name", so I doubt that they would explain the previous behaviour we were relying on. My best guess is that the [ipv4]\ndhcp-send-hostname=false section was a no-op, and when using only the keyfile plugin the global default behaviour was to not send the hostname, and this default has effectively changed to sending the hostname. Note that when also enabling the ifupdown config, with 0.9.x the hostname was sent by default IIRC.)

(In reply to Thomas Haller from comment #2)
> As you are probable aware, NM has a per-connection setting
> "ipv4.dhcp-send-hostname" to control this. You are now asking for a global
> configuration override/default.
> 
> This is currently not possible, but should be.

Exactly! Thanks for the detailed explanation. I'll now ask my C-litterate colleagues and friends if they have some spare cycle to give it a try :)

Was just about to open a new bug ticket about this issue, since customizing the hostname appears to have been disabled.
https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html

Having the ability to block the hostname is critical for user privacy, thanks!

(In reply to Luke from comment #6)

Hi Luke

> Was just about to open a new bug ticket about this issue, since customizing
> the hostname appears to have been disabled.
> https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
> 
> Having the ability to block the hostname is critical for user privacy,
> thanks!

The old [keyfile] "hostname" option allowed to set a static hostname via NetworkManager.conf.
Please, note that you can still do that outside NM, for instance with:

hostnamectl set-hostname "your.hostname"

or with NetworkManager, via dbus or nmcli:

nmcli general hostname "your.hostname"

Once a static hostname is set, it will never be updated automatically by NetworkManager. So, you can still "block" the hostname as long as you set a 
static hostname.

Anyway, there is a branch in review allowing the customization of the way NetworkManager manages the *transient* hostname here:
https://bugzilla.redhat.com/show_bug.cgi?id=1405275

In particular, a new "hostname" option has been added (but in the [main] section) that will allow to completely disable transient hostname automatic updates in NM (hostname=none).
This will soon land on upstream.

Francesco

@Francesco: Assuming that this is hostname-mode, I don’t see how it can be used to not send hostname. The value of `none` does not achieve this goal, and neither do the other ones.

NM developers:

For end-users who care at all about privacy, this is a panful bug to have open for so long.  Most NM frontends in typical use (certainly in the case of plasma-nm in KDE) don't expose an option to forcibly turn off sending dhcp hostnames per-connection.  This adds insult to injury, as if one wishes to not leak the hostname, not only can one not actually configure a systemwide default, but the standard GUI method of connecting to a network should not be used either.

Also, the documentation is not at all not clear about this.  After reading the 
NetworkManager.conf and nm-settings manpages, I thought creating a [connection] stanza in a file in /etc/NetworkManager/conf.d/ file containing ipv4.dhcp-send-hostname=false and ipv6.dhcp.send-hostname=false would do what I (and apparently the other like-minded people on this bug thread) wanted.  I do not see any way to read those manpages and infer what has been said in this bug report about the behavior of those parameters.  After much frustrating testing, I finally found this bug report via the Arch wiki: https://wiki.archlinux.org/index.php/NetworkManager

Your kind efforts to resolve this would be greatly appreciated!

> I thought creating a [connection] stanza in a file in /etc/NetworkManager/conf.d/ file containing ipv4.dhcp-send-hostname=false and ipv6.dhcp.send-hostname=false would do what I (and apparently the other like-minded people on this bug thread) wanted.

`man NetworkManger.conf` says in the "CONNECTION SECTION":

   Supported Properties
       Not all properties can be overwritten, only the following properties are supported to have their default values configured (see nm-settings(5) for details).

In particular, "ipv4.dhcp-send-hostname" are not named as supported properties.



Btw, the ArchLinux wiki suggests to edit /etc/NetworkManager/system-connection/<connection>. Well, that works (provided you also reload the modification with `nmcli connection load` or `nmcli connection reload`). But it seems simpler to just use nmcli:

  $ nmcli connection modify "$PROFILE" ipv4.dhcp-send-hostname no ipv6.dhcp-send-hostname no

> but the standard GUI method of connecting to a network should not be used either.

Note that you can use the GUI to "connect to a network", you can even use the GUI to modify *other* properties of the profile (the GUI should leave the property which is not exposed in the GUI unchanged -- at least, nm-connection-editor does).
You only cannot use the GUI to configure this particular property.



Anyway, I am not questioning the validity of this bug. In particular for RFC 7844 (Anonymity Profiles for DHCP Clients) this needs improvement.

@(In reply to Thomas Haller from comment #10)
> > I thought creating a [connection] stanza in a file in /etc/NetworkManager/conf.d/ file containing ipv4.dhcp-send-hostname=false and ipv6.dhcp.send-hostname=false would do what I (and apparently the other like-minded people on this bug thread) wanted.
> 
> `man NetworkManger.conf` says in the "CONNECTION SECTION":
> 
>    Supported Properties
>        Not all properties can be overwritten, only the following properties
> are supported to have their default values configured (see nm-settings(5)
> for details).
> 
> In particular, "ipv4.dhcp-send-hostname" are not named as supported
> properties.

Yes, you are right.  I had thought this was just a documentation oversight since other "ipv4.dhcp-" family options are included in that list, but it turns out this is really wishful thinking.

> > but the standard GUI method of connecting to a network should not be used either.
> 
> Note that you can use the GUI to "connect to a network", you can even use
> the GUI to modify *other* properties of the profile (the GUI should leave
> the property which is not exposed in the GUI unchanged -- at least,
> nm-connection-editor does).
> You only cannot use the GUI to configure this particular property.

Poor word choice on my part.  A very common use case on a mobile device at a new location (e.g., airport, cafe, hotel, etc.) is to use these GUIs to look at the list of connections that the Wi-Fi scans find, and then select the desired network name from the list and hit "Connect".  The GUIs are specifically designed to make this the default workflow and to make things easy for this use case without having to speak nmcli.  If you do not want to send out dhcp client IDs when you connect, there is no way to just follow this common workflow.

> Anyway, I am not questioning the validity of this bug. In particular for RFC
> 7844 (Anonymity Profiles for DHCP Clients) this needs improvement.

Thank you.  RFC 7844 compliance would be fantastic.  Is there active work planned along these lines?

Are there any plans to make this reality this year? Could some dev outline what has to be done (e.g. pointing at the relevant files, how this should be realized)?

This particular issue seems fixed by "ipv4.dhcp-hostname-flags", introduced in 1.22. Isn't it?

To what value "dhcp-hostname-flags" needs to be set to prevent NetworkManager from sending the hostname?
The default seams to be 0x0 (contrary to what the NetworkManager.conf(5) man page says), but the hostname is still sent to the DHCP server.

You are right. "ipv4.dhcp-hostname-flags" doesn't work.

That is because that option only affects how the hostname is sent. The property is orthogonal to "ipv4.dhcp-send-hostname", which controls whether to send the hostname.


The only problem is that "ipv4.dhcp-send-hostname" cannot be set by default. And the reason that is hard to extend is because the property is a boolean value.


Properties that allow for their default value to be overwritten all require that they have a special value which allows for the fallback to the default value. The boolean property ipv4.dhcp-send-hostname doesn't have a value to allow for such a default value. The goal of this rule is that the per-profile value always takes precedence.


there are some solutions, all ugly:

a) make an exception for ipv4.dhcp-send-hostname. The per-profile value YES would mean: "lookup globally configured value, and if unspecified, use YES". That is ugly, because now the global default takes precedence.

b) deprecate ipv4.dhcp-send-hostname and add a new property that can encode 3 values. I think this is the way to go.



I think, ipv4.dhcp-send-hostname should be deprecated and replaced by new NM_DHCP_HOSTNAME_FLAG_*. Patch welcome :)

It was discussed here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/198#note_328579 but not done (yet).

For example, there could be two new flags:

- NM_DHCP_HOSTNAME_FLAG_SEND_HOSTNAME
- NM_DHCP_HOSTNAME_FLAG_NO_SEND_HOSTNAME

if any of these two flags is set, then ipv4.dhcp-send-hostname gets ignored. Also, `nm_connection_normalize()` should be extended to enforce that conflicting flags agree.

I set "dhcp-send-hostname=false" in both [ipv4] and [ipv6] sections of my wifi connection and checked at the modem, but it still showed the hostname. I made sure to restart network-manager and also tried together with mac-randomization to make sure the hostname is not remebered from before. The Fritzbox always showed my hostname.

Then I tried to workaround it in a different way: I set dhcp=dhclient in a [main] section in /etc/NetworkManager/conf.d and commented out the send host-name line and it still showed  my hostname.

So both ways failed, any ideas what I could try?

Forgot to mention: I commented out the send host-name line in /etc/dhcp/dhclient.conf

In case someone else needs a quick fix..

I added the following to /etc/rc.local:
#
# quick fix for NetworkManager to comply with RFC 7844.
#
if grep host-name /usr/sbin/dhclient &>/dev/null; then
    cp /usr/sbin/dhclient /usr/sbin/dhclient.orig
    sed -i 's/host-name/xxxx-name/g' /usr/sbin/dhclient
fi

Created /etc/NetworkManager/conf.d/custom-use-dhclient.conf:
[main]
dhcp=dhclient

This makes NM use dhclient, and renames the "set host-name" option to "set xxxx-name" so that dhclient in effect will ignore what NM tells it.

Looking forward to this bug being fixed.  Fingers crossed!  :-)

bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).