Upgrade to Fedora 33 broke my internet; now videos are choppy

I’ve been using Fedora since Fedora 22, and for the most part it has been smooth sailing. I recently encountered one of my first snags: after I upgraded from Fedora 32 to Fedora 33, my internet became unbearably slow. I followed the advice in this Reddit post (Reddit - Dive into anything) and executed the suggested commands

sudo rm -f /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
sudo systemctl disable --now systemd-resolved.service
sudo systemctl mask systemd-resolved.service

That fixed the issue, except that now some videos on certain websites are choppy; the videos played fine on the same machine running Fedora 32. Strangely, YouTube and Netflix both seem to work fine. I feel confident the issue is not with my drivers, since the videos are still playing, just not as smoothly as I would like (I’m using the integrated graphics on an Intel i5 9600K, if anyone is curious). Also, I connected a Windows machine to the same network and everything worked fine; all videos across all site are playing smoothly, so it is clear that the issue is not my local network setup (router, ISP, etc).

I believe the issue is something to do with how the network settings are configured on my machine, perhaps related to the aforementioned Reddit post or this thread (awsumco/netdata).

Here is the output of ping www.yahoo.com:

64 bytes from media-router-fp73.prod.media.vip.ne1.yahoo.com (74.6.231.20): icmp_seq=5 ttl=48 time=74.2 ms

The ping seems a bit high to me (I’m in California, USA).

Here is the output of route:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 eno1
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 eno1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Here is the output of ifconfig:

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.6  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::d0d2:c358:a381:9b  prefixlen 64  scopeid 0x20<link>
        ether 0c:9d:92:c2:41:b5  txqueuelen 1000  (Ethernet)
        RX packets 2184094  bytes 2899703900 (2.7 GiB)
        RX errors 0  dropped 22  overruns 0  frame 0
        TX packets 1047960  bytes 145438424 (138.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xa1200000-a1220000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 889  bytes 73971 (72.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 889  bytes 73971 (72.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:51:5e:2b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Any pointers would be greatly appreciated! This is my first time using these forums, so I apologize if my question is not correctly formatted.

1 Like

I have seen problems with ip6 conflicting with ip4 if there is not a continuous ip6 route to the other end. Systems seem to prefer ip6 and there can be a stutter as you describe while waiting for the ip6 connection to fail before it switches to ip4.

Maybe you can try turning off ip6 on interface eno1 and see if there is a difference.

I recently updated my machine (sudo dnf update) after a few weeks of travel. I noticed the following lines in the DNF output:

Not setting net/ipv4/conf/default/rp_filter (explicit setting exists).
Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists).
Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists).
Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists).
Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists).

Makes me think @computersavvy might be onto something re IP4 and IP6. All I want is for my settings to be “default”, i.e. to match those on a fresh Fedora install.

Are you utilising openh264? ffmpeg is able to adequately quickly decode MP4, which is what is usually provided by most websites, but openh264 is not. However, http://youtube.com is usually able to provide compatible videography, whereas alternative websites are not, which may explain why http://youtube.com is operating correctly. Windows includes the necessary codecs.