Realtek 2.5Gbe RTL8125 NDIS Reset Problem

I am also using a CAT6 cable, but upgrading to the latest driver solved the issue for me.

I am also running this Realtek NIC with a B550 Steel Legend, constant disconnects on every driver version since I built this PC about 4-5 months ago. Have tried everything from disabling all the energy efficient options, new cables, reverting to the original windows driver etc and still random disconnects.

I am thinking of just getting an Intel PCIE NIC as this is driving me crazy.

I have an Asus TUF Gaming B550-Plus motherboard with the same Reltek network card. I built the machine in September, and I?™ve struggled with the problem ever since. I found the solution 1 week ago: I hope you have a torrent client on your machine guys? Because the problem is caused by μTP (Micro Transport Protocol). I use qBittorrent and since I switched the peer connection protocol to TCP only, the problem has disappeared, it has never been produced since, so I dare say that this was the problem.

Hey guys!

Just created an account to show my support, i built 2 pc's in october with b550 steel legend mobos and both of them seem to have this problem, its driving me insane, tried switching the cat cables, a ton of different drivers and nothing seems to work. I also use qbittorrent and i have noticed that i do dc less when i dont have it open (still dc tho).
Sometimes i dc for 4-8 seconds and then automatically reconnect but lately its been that i have to manually replug the cable to regain connection.

Sent an email to asrock support and i suggest all of you do the same to bring this issue to their attention.

Currently disabled the settings in advanced tab and waiting to see if they helped.

One of the developers of libtorrent (a library used in qBittorrent) just stated that reported issue of Realtek 2.5GbE controllers (such as RTL8125) resetting (Event ID 10400, source NDIS) is likely caused by the Realtek hardware/drivers:

https://github.com/arvidn/libtorrent/issues/5761

I suspect the hardware or driver isn't well tested under heavy UDP load, and fails. I don't really see anything actionable on libtorrent's part, other than recommending that users with the failing hardware either disable uTP or replace the hardware.
libtorrent doesn't talk directly to the driver, it uses the operating system's API. The API guarantees that hardware is not supposed to reset by its use, similar to operating systems (normally) guaranteeing they won't kernel-panic because of system calls.