----- Original Message -----
On 31 Oct 2016, at 11:41, Richard Hughes hughsient@gmail.com wrote:
On 30 October 2016 at 01:26, Adam Williamson adamwill@fedoraproject.org wrote:
- Both dnf and GNOME Software / PackageKit default to performing
fairly data-hungry transactions in the background, out of the box, without telling you about it. GNOME's is particularly bad, as it will happily download available updates in the background, which can be gigabytes worth of data.
If you're on an "unmetered" connection type...
How does a connection become "unmetered"? It can't just be on interface type, as I have metered connections on all interface types, so presumably you use some form of web service to distinguish "metered" from "unmetered" based on a list of known IP blocks?
Or do you simply assume that all connections are metered until the user says otherwise?
They're metered unless you either tag them as unmetered, or hints are provided to NetworkManager by what you're connected to. For example, Android tethering is automatically tagged as metered as Android provides a hint in its DHCP configuration.
On Mon, 2016-10-31 at 08:18 -0400, Bastien Nocera wrote:
How does a connection become "unmetered"? It can't just be on interface type, as I have metered connections on all interface types, so presumably you use some form of web service to distinguish "metered" from "unmetered" based on a list of known IP blocks?
Or do you simply assume that all connections are metered until the user says otherwise?
They're metered unless you either tag them as unmetered, or hints are provided to NetworkManager by what you're connected to. For example, Android tethering is automatically tagged as metered as Android provides a hint in its DHCP configuration.
Does NetworkManager 'hint' that wired connections are unmetered? Otherwise your description doesn't seem to square with the fact that most everyone sees background update downloads OOTB.
Even still, in fact, kparal mentioned them happening on hotel wifi, so why would that be the case if the default is 'metered'?
On Mon, 2016-10-31 at 09:13 -0700, Adam Williamson wrote:
On Mon, 2016-10-31 at 08:18 -0400, Bastien Nocera wrote:
How does a connection become "unmetered"? It can't just be on interface type, as I have metered connections on all interface types, so presumably you use some form of web service to distinguish "metered" from "unmetered" based on a list of known IP blocks?
Or do you simply assume that all connections are metered until the user says otherwise?
They're metered unless you either tag them as unmetered, or hints are provided to NetworkManager by what you're connected to. For example, Android tethering is automatically tagged as metered as Android provides a hint in its DHCP configuration.
Does NetworkManager 'hint' that wired connections are unmetered? Otherwise your description doesn't seem to square with the fact that most everyone sees background update downloads OOTB.
Even still, in fact, kparal mentioned them happening on hotel wifi, so why would that be the case if the default is 'metered'?
For that matter, I'm fairly sure I've seen background update downloading happen when I was using an Android wifi tether connection. I'm pretty sure I remember it blowing my data cap one month when I was using my laptop on the bus.
On Mon, Oct 31, 2016 at 09:23:06AM -0700, Adam Williamson wrote:
For that matter, I'm fairly sure I've seen background update downloading happen when I was using an Android wifi tether connection. I'm pretty sure I remember it blowing my data cap one month when I was using my laptop on the bus.
As far as I can see, the default is "unknown". You can set "CONNECTION_METERED=yes" in the /etc/sysconfig/network-scripts/ifcfg-[whatever] file to change it on a per-device basis.
The man page for NetworkManager.conf doesn't document this as one of the properties which can have its default overridden (and says that anything not documented can't be overridden). I took that at its word; possibly worth testing anyway. :)
On Mon, 2016-10-31 at 12:31 -0400, Matthew Miller wrote:
On Mon, Oct 31, 2016 at 09:23:06AM -0700, Adam Williamson wrote:
For that matter, I'm fairly sure I've seen background update downloading happen when I was using an Android wifi tether connection. I'm pretty sure I remember it blowing my data cap one month when I was using my laptop on the bus.
As far as I can see, the default is "unknown". You can set "CONNECTION_METERED=yes" in the /etc/sysconfig/network-scripts/ifcfg-[whatever] file to change it on a per-device basis.
The man page for NetworkManager.conf doesn't document this as one of the properties which can have its default overridden (and says that anything not documented can't be overridden). I took that at its word; possibly worth testing anyway. :)
Hi,
In NetworkManager this works as follows:
(1) There is the per-connection property "connection.metered" [1]. It can be "yes", "no", "unknown". "unknown" is the default and prompts NM to do some basic heuristics.
$ nmcli -f connection.metered connection show $NAME $ nmcli connection update $NAME connection.metered yes
(2) Then there is the Device's metered property in the D-Bus API [2]. If you activate a connection that has "connection.metered" explicitly set to "yes" or "no", that's it. Otherwise, NM will set the device property to "guess-yes" or "guess- no". For example, - WWAN connections are "guess-yes" - if there is a DHCP option ANDROID_METERED, it is "guess-yes". See [4].
$ nmcli -f GENERAL.METERED device show $DEVICE
(3) Finally, there is the Manager's metered property [3]. This combines the metered property of multiple devices into one. PackageKit would only care about this
$ busctl get-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Metered
best, Thomas
[1] https://developer.gnome.org/NetworkManager/stable/nm-settings.html#nm-settin... [2] https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.Netw... [3] https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.Netw... [4] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/...
----- Original Message -----
On Mon, 2016-10-31 at 08:18 -0400, Bastien Nocera wrote:
How does a connection become "unmetered"? It can't just be on interface type, as I have metered connections on all interface types, so presumably you use some form of web service to distinguish "metered" from "unmetered" based on a list of known IP blocks?
Or do you simply assume that all connections are metered until the user says otherwise?
They're metered unless you either tag them as unmetered, or hints are provided to NetworkManager by what you're connected to. For example, Android tethering is automatically tagged as metered as Android provides a hint in its DHCP configuration.
Does NetworkManager 'hint' that wired connections are unmetered?
It doesn't say "definitely metered" or "definitely unmetered". We usually take that to mean it's unmetered.
Otherwise your description doesn't seem to square with the fact that most everyone sees background update downloads OOTB.
Even still, in fact, kparal mentioned them happening on hotel wifi, so why would that be the case if the default is 'metered'?
Looks like I switched metered and unmetered around in my description ;)
They're unmetered unless you either tag them as metered, or something (like a DHCP server) tells NM they're metered.
Sorry about that.
On Mon, 2016-10-31 at 12:25 -0400, Bastien Nocera wrote:
Otherwise your description doesn't seem to square with the fact that
most everyone sees background update downloads OOTB.
Even still, in fact, kparal mentioned them happening on hotel wifi, so why would that be the case if the default is 'metered'?
Looks like I switched metered and unmetered around in my description ;)
They're unmetered unless you either tag them as metered, or something (like a DHCP server) tells NM they're metered.
Sorry about that.
Ah, indeed, that lines up better with the observed data =) Still, it's interesting that the DHCP metered indication thing doesn't seem to be working, per my recall and kparal's nmcli output?
desktop@lists.fedoraproject.org