Disable sys-net pings to fedoraproject.org

Was trying to figure out why my sys-net was calling home every 5 minutes…

How do I stop/disable NetworkManager connecting to fedoraproject.org every 5 minutes?

This connectivity check is done by NetworkManager and it is configure on /etc/NetworkManager/conf.d/20-connectivity-fedora.conf You
can edit this file and change the uri field if you like to set another
domain to verify you need to have a hotspot.txt file or a file that will
return “OK”. If you want to disable it you can set uri with no value that will disabled it.


The reason for this check is to validate that your network connection
works, for instance sometimes you join a wifi network but it does not
connect to the internet only to local network, you can see that when
your wifi icon is change to a question mark on Gnome3.

Interesting! What can we make out of this?

Isn’t this more a general Qubes bug report that should be posted on
https://github.com/QubesOS/qubes-issues/issues ?

Hmm… not sure it qualifies as a bug. Plus, the Fedora-wonks on the Qubes side probably already know about it.

Just wanted to mention it for the Anonymity-crowd over here. I’ll leave it to you to decide what to do if anything…

Advantage to leaving it enabled:

  1. No question mark in system tray.
  2. Reveals you are a Fedora user
  3. Shows that you are online even when you wouldn’t otherwise generate any network traffic.

It sends approx 950B. No idea what that contains.

EDIT: Disabling on a Wired connection has no visible effects. Have not tested Wireless.

Qubes developers are very receptive wrt to suggestions. For example, they also disabled tcp as well as icmp timestamps by default due to my request.

If it’s something unimportant, can be disabled, then likely they would disable it by default.

The package that controls the connectivity check is NetworkManager-config-connectivity-fedora.

Not installed on Fedora-24-minimal.

Installed by default on Fedora-24 but can not be removed because it is reverse dependency of fedora-release-workstation metapackage. May not be active since I am unable to find a configuration snippet containing uri= key. (Usually located in /etc/NetworkManager/conf.d/)

Also noticed more unsolicited traffic from Fedora template.


He got a two domains without any control of him and without updates enabled and controlled by NetworkManager , domains are :



Fedora uses a mirror list service. This service tells the Fedora updater where it can download updates. Please tell your friend that this is completely normal. In fact, it is required to keep his Fedora installation up to date and secure.

Doesn’t make sense. Why can’t some-gateway.fedoraproject.org direct traffic where it needs to go?


You can disable this by running the following command:

$ systemctl disable dnf-makecache.timer

Might be harmless but seems to be superfluous traffic at best. Certainly only required in TemplateVM. Question is how to disable? Should service be disabled in TemplateVM for all VMs and then use rc.local in TemplateVM to sudo systemctl start dnf-makecache.timer? Or is it even needed in TemplateVM?

If makecache is necessary, it can actually be run right before dnf upgrade. Command is dnf makecache. It might not be necessary. Just tried dnf clean all followed by dnf upgrade. No mention of makecache.

IIUC someone decided that it was a good idea for every Fedora machine in the world to connect to a Fedora server every hour, all day long… in order to prevent the end user from having to download 30 KB before downloading a 40,000 KB package list!!! What am I missing? :confused:

1 Like

Can you please repost this here?

I know that Debian explicitly disables this stupidity. Why not switch?

For some users using a Debian based sys-net and sys-firewall works. For some it doesn’t. I’ve been told by Qubes developers that Fedora has better out of the box network hardware support, that’s why Qubes by default has Fedora based sys-net and sys-firewall.

sudo systemctl disable dnf-makecache.timer works - but these kinds of things just make you wonder what else is out there. FWIW, dnf-makecache.timer was disabled by default in Fedora-23-minimal template - so either enabled upstream for Fedora-24 or oversight by Qubes.

I continue to use Fedora for everything non-Whonix because it seems that the Qubes team uses it exclusively. Not comfortable with the Debian template given where all their eyeballs are. I wouldn’t mind if they switched to Debian though. :wink:

WTF. They should change their name to FedoraSoft or Microdora.

Unfortunately there is no /etc/NetworkManager/conf.d/20-connectivity-fedora.conf in the Fedora24 template to kill the uri field.

Running entr0py’s suggestion instead. How are you confirming that unsolicited traffic with the Fedora mothership has actually been killed?

Agree that they should have Debian across the board, with the bonus of killing off this ridiculous updating schedule of every 6 months for templates.

These are two different issues:

  1. Connectivity check: Enabled by NetworkManager-config-connectivity-fedora and a configured uri=. Although package is installed by default in Fedora-24 template, I wasn’t able to find a configured uri and have not noticed any packets indicating that this feature is enabled. It was enabled in the Fedora-23-minimal template. (Makes an attempt every 5 minutes.)

  2. DNF metadata update: This can be / should be disabled by sudo systemctl disable dnf-makecache.timer in the Fedora template (both minimal and full). It is not necessary since dnf upgrade rebuilds the metadata cache if it’s expired anyway. Purely a convenience feature so you don’t have to wait when updating. (I noticed hourly checks although this ticket says it was extended to every 3 hrs: https://bugzilla.redhat.com/show_bug.cgi?id=892064)

The same way I noticed that it was happening - packet monitors and luck. Would be nice to have some automated check. Maybe need to look at some Intrusion Detection Systems. Scared the crap out of me to see this 443 traffic all of a sudden after so many months of quiet…

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]