Posting for others searching for this problem. I recently installed Debian Buster on a new setup with an MCI motherboard, which has an onboard Realtek RTL8111/8168/8411 Ethernet Controller (use "lspci" to check that the controller is recognized).

During install, Debian installed an Ethernet driver called r8169, which is very unstable (use "lsmod" to see which driver is loaded). r8169 works for a while, then completely stops working after a few minutes.

The solution is to download the "official" driver (called r8168) from the Realtek site, then untar it and run an included script to build/install it. Here is an outline:

https://www.unixblogger.com/how-to-g...updated-guide/

Note that the download link on the page above is broken - you'll need to search through the Realtek site for the driver download page. Also, if you're on a new install, you'll need to install the kernel headers and programs necessary to build the driver, like the "build-essential" package on Debian.

WOW, I started investigating this before I noticed that you marked this solved. (my bad)

You were able to take a closed source driver that was written by a vendor over 7 years ago and get it working? If so I am impressed. Has the vendor been updating the driver? What kernel are you using and how many years old is the timestamp of the file(s) you downloaded from Realtek?

The driver on Realtek's site has an update date of 2018/08/17:

https://www.realtek.com/en/component...press-software

Getting it working was no problem - the tar includes a script that ran without issue. Using kernel 4.18.0-2.

The tricky part was figuring out that the problem was the driver. Debian installed the r8169 driver during install without any errors or warnings, so I just assumed it was OK - but actually it's horribly unstable. It cuts out a few minutes after booting every time, so it was a long process of booting/search/reboot/etc.

1 members found this post helpful.

You could check the logs, by default another driver was installed (r8168 or something "almost" similar), because the right one was not available (and the nearest replacement was used).

I'm sure you're right that there's some indication in the logs, but I didn't think to investigate that (and I don't know that the logs would've helped even if they did say an alternate was installed) - since I assumed Debian wouldn't install a non-functional driver, and it failed without any error messages, I was all over the place thinking it was a hardware problem or maybe something within network config or udev or systemd, etc., etc.