2

I did a vanilla installation of 20.04.1 LTS on a PC using a wired connection (no on board WiFi) to a Netgear Gigabit switch for LAN access using an RJ45 Cat6 data cable (checked for correct integrity) which in turn is connected to a 4G router for internet access. This is the only operating system on this PC.

I also have a Synology NAS connected to the same switch mounted in fstab which works perfectly fine. The NAS share (GnV_Common) is shown on the desktop using GNOME Extension Desktop Icons NG (DING).

enter image description here

This arrangement has worked fine and without issue in Ubuntu 18.04.5 LTS (the only difference being that the appearance of the NAS Share on the desktop is handled differently in 18.04)

I mention the NAS arrangement because, curiously, when the internet drops out, the NAS share disappears from the desktop too (Network Manager related perhaps).

There is no apparent trigger for this behaviour I can establish.

On a few occasions, I have noticed that there is no internet access on the 20.04.1 box but yet the Network Manager indicates that it is connected (image from last incident), and the Network Manager icon on the System Tray remains constant:

enter image description here

The issue was not repeated on the 18.04.5 box which continued to access the network and the internet.

My research has taken me (through many questions only related to WiFi issues) to this answer to a similar question

https://askubuntu.com/a/2905/307670

In this regard, the managed=false flag is set. For comparison purposes, I also checked NetworkManager.conf file in the 18.04.5 LTS box and it is set the same way so I'm not convinced the issues are the same.

The only way I have found to restore things to normality is to restart, after which the PC performs correctly and the network share is restored and persists until the next incident. I have not found any possible trigger for this issue; it sometimes happens overnight when the PC is not in use and the latest incident was after the PC had not been used for a couple of hours but had performed well up to that point. There is no occasion I have found where this occurs during a period of use.

I'm reluctant to change the managed=false flag unnecessarily since there is no firm evidence yet that this is the issue. It does not occur on 18.04 LTS with the same setting and I am not confident this is the issue causing this phenomenon.

If the issue was more widespread, I would have expected it to have been flagged by now like the WiFi dropping issue so, is this just something unanswered in isolation on this PC, has the issue already been addressed elsewhere which I have missed or could the GNOME extension adding the share to the desktop be involved some way?

I'd be grateful for any pointers as to what possibly could be causing this unusual issue.

EDIT:

Yes, using CAT6 cable.

contents of sudo lshw -C network

*-network                 
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:05:00.0
       logical name: enp5s0
       version: 15
       serial: 00:e0:4a:68:33:44
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=5.8.0-38-generic duplex=full firmware=rtl8168h-2_0.0.2 02/26/15 ip=192.168.1.169 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       resources: irq:19 ioport:d000(size=256) memory:fbc04000-fbc04fff memory:fbc00000-fbc03fff
8
  • Edit your question and show me sudo lshw -C network. Also, are you using a cat5e or cat6 cable?
    – heynnema
    Jan 18, 2021 at 14:56
  • Try installing dkms and r8168-dkms and see if that helps. If it does, I'll put that into a formal answer.
    – heynnema
    Jan 18, 2021 at 15:49
  • When you lose Internet access, does the network icon change to a ... or ?
    – heynnema
    Jan 18, 2021 at 15:51
  • Let me know if the r8168-dkms driver helps.
    – heynnema
    Jan 18, 2021 at 16:08
  • @heynnema I've installed both. I guess I won't know until either a reboot becomes necessary (r8168-dkms) when the installation process says to restore the old version or the wired connection drops again but feel free to add that as an answer by all means in the meantime.
    – graham
    Jan 18, 2021 at 16:17

2 Answers 2

1

From the comments...

The Internet disappears, however the NetworkManager icon in the System Tray still shows its normal icon. (So it doesn't appear to be a MSI interrupt problem).

The user is using a CAT6 ethernet cable, and does show a 1G connection when viewed with lshw -C network.

The current configuration is using the stock r8169 driver, which is known to have the same problem as in the question.

We replace the r8169 driver by installing dkms and r8168-dkms and rebooting. We then observe to see if the problem is fixed.

Update #1:

On the chance that this IS a MSI/MSI-X problem, try this script...

#!/bin/sh

# https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779817

# filename: r8169_disable_msi

# Drop it in /etc/initramfs-tools/scripts/init-top and chmod a+x it. Add 'r8169_disable_msi'
# to your kernel command line (/etc/default/grub, GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
# usually.) 

# Remember to update-initramfs and update-grub as necessary.

# sudo update-initramfs -c -k $(uname -r)
# sudo update-grub
# reboot

# For the moment it disables MSI on everything with the ID 0x10ec:0x8168, as there seems to
# be no way to get the MAC version from userspace - and certainly not before the driver is
# loaded. Other PCI IDs may need adding..

PREREQ=""
prereqs()
{
    echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
    prereqs
    exit 0
    ;;
esac

disable_msi () {
    for i in /sys/bus/pci/devices/*; do 
        if [ $(cat $i/vendor) = "0x10ec" -a $(cat $i/device) = "0x8168" ]; then
            echo 0 >$i/msi_bus
        fi
    done
}

for x in $(cat /proc/cmdline); do
        case ${x} in
        r8169_disable_msi)
        disable_msi
        break
                ;;
        esac
done
8
  • That hasn't worked. The wired connection has just dropped again just less than a week since replacing r8169 as identified in your answer - so the problem still exists and required a restart. Difference is that the NAS share didn't disappear this time.
    – graham
    Jan 24, 2021 at 16:44
  • @24601 Please describe your ethernet cabling all the way from the back of the computer all the way to the modem/router. And confirm... that the network icon does NOT change during the outage.
    – heynnema
    Jan 24, 2021 at 16:52
  • 2m CAT6 RJ45 cable commercially made ends in plastic trunking to gigabit router connected to 4G router also CAT6 (.5m) commercially made ends. The network icon does not change. The Internet continues to operate with other devices both wired and WiFi to the same Gigabit router/4G combo including another wired 18.04 LTS PC.
    – graham
    Jan 24, 2021 at 16:59
  • @24601 Try Update #1 in my answer.
    – heynnema
    Jan 24, 2021 at 17:10
  • whooops - how do I implement that. Sorry, never been there before.
    – graham
    Jan 24, 2021 at 17:37
0

This works for me.

sudo gedit /etc/network/interfaces

Edit/comment out anything that starts with auto. For me:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo

Change it to:

auto xxx
   iface enp5s0 inet dhcp

where xxx is the logical name (You can see the logical name using this command lshw -C network

Then restart networking components. sudo /etc/init.d/networking restart

1
  • in the network interface I think lo stands for loopback, can you ping 127.0.0.1 with this change to config ?
    – Yvain
    Oct 6, 2021 at 13:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .